There was a time when every device came with its own charger, and none of them fitted anything else. A drawer full of cables, each useless for all but one thing. Then a standard plug arrived, and the drawer emptied.
MCP — the Model Context Protocol — is that standard plug for AI assistants. It is an open specification for how an assistant connects to the tools and data outside it: your files, a database, a calendar, an internal service. Write the connection once, in the agreed shape, and any assistant that speaks the protocol can use it.
In short
- What
- An open standard for connecting AI assistants to outside tools and data. A server offers capabilities; a client — the app the model runs in — connects and makes them available.
- Why
- Without a standard, every assistant needs custom wiring for every tool. With one, each tool is built once and works everywhere.
- When
- When a capability should be reachable by more than one assistant or app, or when tools belong outside the app rather than buried inside it.
- How
- Expose few, clearly named tools; write their descriptions as if a model will read them, because one will; and put the permissions in the server, never in the wording.
The problem it solves
Say you have five assistants and eight tools you would like them all to reach. Without a shared shape, that is forty separate pieces of integration, each written by hand, each needing maintenance when either end changes. Add a ninth tool and you write five more.
A protocol collapses that. Build eight servers and five clients that speak the same language, and everything connects to everything. Add a ninth tool and you write it once.
This is not a new idea — it is the reason for every standard plug, port and file format ever agreed on. It is just newly relevant, because assistants that can use tools are new enough that the wiring was being invented separately every time.
How it fits together
A server is the thing that offers capabilities: a set of tools it can perform, and sometimes resources it can read out. It is ordinary software. The interesting part is not what is inside it but that it describes itself in an agreed way — here are the things I can do, here is what each one needs, here is what it gives back.
A client is the application the model lives in. It connects to servers, collects what they offer, and puts that in front of the model as a set of available actions. When the model decides to use one, the client makes the call and hands the result back.
The model itself never talks to your database. It asks for a tool to be run, and something outside it decides whether that is allowed and does the work. That separation is the whole safety story, and it is worth understanding clearly.
When you reach for it
When the same capability should be available in more than one place — a lookup that your internal assistant, your support tooling and your editor all want.
When tools should be maintained separately from the assistant using them, by the team that owns the underlying system rather than whoever built the chat interface.
And when not. One tool, one application, one team: a direct function call is simpler, faster and easier to reason about. A protocol is worth its overhead when there is more than one of something on at least one side. Reaching for it before that is architecture for its own sake.
How to build a good server
Keep the tools few and plainly named. Twenty near-identical tools is not thoroughness; it is a choice you have handed to the model, and it will get some of them wrong. Two well-named tools beat ten overlapping ones.
Write the descriptions for the reader you actually have. A tool description is read by a model deciding whether to use it, so it should say what the tool does, when it is the right choice and when it is not — in plain sentences, not in the compressed style of internal documentation.
Put the limits in the server. What a tool may touch, how much it may change, what needs confirming first: all of that belongs in the code, where it is enforced, not in an instruction asking the model to be careful. A prompt is a request; a server is a rule.
Return errors that say what to do next. “Not found” leaves a model guessing. “No listing with that id; list ids first with the search tool” turns a dead end into a next step.
And return less. A tool that hands back an entire record when three fields were wanted fills the model’s attention with material it has to read past. Tool output is context, and the same discipline applies.
Where it stops
A protocol describes how things connect. It has nothing to say about whether a particular tool should exist, who may use it, or what happens when it is used badly. Connecting an assistant to a system that can delete things is straightforward; deciding that it should be able to is a judgement, and it stays yours.
MCP makes the wiring standard. What runs through it is still your design.
