MCP, Past the Handshake
The server took an afternoon. You wrote it, pointed your agent at it, and the calls landed on the first try: the schema was right, the responses came back clean, the demo ran twice without a stumble. Then it moved behind a shared service so the rest of the team could reach it, and nothing broke. That is the part worth worrying about. The same call from anyone returns the same records — every account, every deal, everybody’s. The protocol did its job exactly as specified. It was never asked who was on the other end.
The tap is the easy part
You already know what the protocol buys you: one agreed way for a client to ask a server what it offers and then use it, so a server built once is reachable from a coding agent, an editor and a chatbot without an adapter written for each pairing. That is the standard everyone connected to, and it is genuinely solved.
Think about tapping a card in a shop in a city you have never visited. The exchange between the card and the reader is standardised, which is why it works there at all. But the tap is not the payment. In the moment after it, a request travels to whoever actually holds the money, carrying with it who is spending. It gets measured against what that person is allowed to spend. It comes back approved, or refused with a reason: not enough left, or reported stolen. At the counter both refusals look identical, and they mean entirely different things.
MCP standardises the tap. It does not say who is spending, how much room is left, or what a refusal means. The layer that answers those questions has a name in production: a control plane, sitting between your agent and every server it talks to.
Nobody hands the whole office one card
The first thing that layer carries is identity. A broker in front of the servers routes each request with the identity and scope of the actual person behind it, rather than a single service credential shared by everyone. Skip it and your permission model quietly collapses to whatever that one credential can reach, which is how the CRM tool in the opening ends up handing everyone the whole book.
The second is a budget. Each tool gets a timeout contract and a share of the run’s remaining time, sized by how slow it is expected to be. When one call overruns, the control plane tightens the limits on the calls after it, instead of letting the run drift and die at the end with nothing finished.
The third is what a failure says. Errors come back as machine-readable codes mapped to actions, because the right move differs sharply by reason. A timeout is worth retrying. A malformed argument is worth repairing. A permission refusal is worth neither: retrying it only fails again, faster, and the honest response is to stop and ask a human. Leave failures as free English and you have handed that judgement to the model, which will guess, confidently. This is the dial that decides how much of this you are willing to leave running unattended.
The list finds it, the protocol calls it
Before any of that, the agent has to find the server. Discovery is its own layer, and the emerging shape of it is plain: an organisation publishes a machine-readable list of what it offers at its own domain — servers, agents, skills, ordinary web tools — and registries index those lists so an agent can query them mid-task. Each entry carries metadata, a publisher identity, a trust manifest and a namespaced name you can pin. The agent checks the entry, then connects using the resource’s own protocol. The list is how you find a capability; the protocol is how you use it. Keeping the two apart is what stops “the agent found a tool online” from becoming “the agent ran a tool nobody vetted”.
This is also how capability gets added at all now. A server for the database, a server for the file system, and one open harness puts more than seventy integrations behind that single surface, identical in a desktop app and through the API. Changing model or interface stops meaning rewritten integrations. It never stops meaning that each of those servers is something somebody has to find, authorise, budget and watch. A standard can tell you the two ends fit. It cannot tell you the call should go through.