MCP explained for developers

Before any standard existed, connecting an AI assistant to your systems meant writing an integration per assistant. Your ticketing system needed one adapter for one product, a different one for the next, and each was thrown away when you switched.

The Model Context Protocol inverts that. You describe your system once, as a server speaking a documented protocol, and any client that speaks it can use your tools. It is the same bargain as any protocol: accept some ceremony now in exchange for not rewriting the integration later.

The analogy that fits is the language server protocol for editors. Before it, every editor needed bespoke support for every language; after it, one server served them all. The value came from the multiplication, not from the protocol being elegant.

An MCP server exposes capabilities in a small number of shapes. Getting these right is most of the design work, because the client decides what to call based only on the descriptions you provide.

The distinction that trips people up is between tools and resources. A tool does something and may have side effects. A resource is something to read. Modelling a read as a tool works, but it gives the client less to reason about.

Prompts are the least used and the most misunderstood. They are templates a person deliberately selects, not instructions the model discovers — which makes them useful for codifying a workflow your team repeats rather than for steering behaviour generally.

• Tools — actions the model can invoke, with typed inputs and a described effect
• Resources — readable content the client can pull in as context
• Prompts — reusable templates a user can select deliberately

Function calling is a model capability: the model emits a structured request and your code runs it. MCP is a transport and discovery layer sitting above that. The model still ultimately calls functions; MCP standardises how those functions are advertised, described and reached across process boundaries.

The practical difference is who owns the integration. With function calling, the application owns every tool definition in its own codebase. With MCP, the tool lives in a separate server that any compliant application can discover at runtime, including ones you did not write.

If your tools are only ever used by your own single application, function calling is simpler and you should use it. MCP earns its overhead when the same capability needs to be reachable from several clients, or when someone else will consume it.

The most common failure in a first MCP server is exposing your internal API surface directly. Thirty granular endpoints that made sense for a REST client become thirty confusable options for a model that picks by reading a one-line description.

Design for the caller you actually have. Fewer, task-shaped tools outperform many primitive ones. A tool named search_orders_by_customer with a clear description beats three tools that must be chained in an order the model has to guess.

Descriptions carry more weight than anything else you write. They are the entire basis on which a tool is chosen, and a vague one produces a model that either avoids the tool or calls it wrongly — both of which look like model failures and are documentation failures.

• Name tools after the task, not the endpoint
• Write descriptions for a reader with no other documentation
• Return errors as readable text explaining what to do differently
• Keep responses small — raw payload dumps crowd out the question
• Make destructive actions explicit and hard to invoke by accident

An MCP server is an execution surface reachable by a system that takes instructions from text. If a model can be talked into calling your delete tool, the boundary that matters is the one in your server, not the one in the prompt.

Treat tool inputs as untrusted, because content retrieved from elsewhere can influence what gets called. Scope credentials to the narrowest workable permission, log invocations with enough detail to reconstruct a sequence, and require confirmation for anything irreversible.

Once the server is published you also lose control of the caller. You no longer choose which model connects, what other servers it has attached, or what its user asked for — so every tool has to authorise independently rather than trusting that the agent behaved sensibly.

• No tool that executes arbitrary code or queries
• Credentials scoped per server, never a shared admin token
• Authorisation decided in the tool, not assumed from the caller
• Untrusted content returned in clearly delimited, labelled fields
• Irreversible actions gated behind an explicit confirmation

The mechanical part is small. An SDK exists for the common languages, a minimal server is a few dozen lines, and running it locally against a client takes an afternoon. The protocol is not where the difficulty lives.

The real work is the same work as any good API design, with a less forgiving consumer. You will iterate on tool granularity, discover that a description you thought was obvious is not, and find that returning too much data degrades everything downstream.

Expect to rewrite your tool surface at least once after watching a model use it. That observation — seeing which tool it reaches for and which it ignores — is worth more than any amount of upfront design.

For developers working on internal AI tooling, yes — the concepts transfer even if a different standard eventually wins. Thinking about tool granularity, description quality and permission scoping is durable regardless of the wire format.

For everyone else it is worth one weekend. Build a server over something you already run, connect it to a client, and notice what the model gets wrong. That exercise teaches more about why AI integrations fail than a month of reading will.

It is also becoming a reasonable thing to have on a CV. Teams building agent systems increasingly ask whether a candidate has designed a tool surface for a model rather than for a developer, and very few have.