MCP becomes infrastructure: what a year of the protocol taught us

What was announced

On December 9 the Linux Foundation announced the Agentic AI Foundation, a directed fund co-founded by Anthropic, Block and OpenAI. Anthropic contributed the Model Context Protocol, Block contributed its goose agent, and OpenAI contributed AGENTS.md, which the press release says is already used by more than 60,000 open source projects. The platinum members are AWS, Anthropic, Block, Bloomberg, Cloudflare, Google, Microsoft and OpenAI, with 18 gold members and 21 silver members underneath, from Cisco and Datadog to Hugging Face and Zapier.

The numbers on MCP itself are the reason this happened. The MCP blog cites over 97 million monthly SDK downloads and 10,000 active servers, with client support in ChatGPT, Claude, Cursor, Gemini, Microsoft Copilot and Visual Studio Code. A protocol one vendor released in late 2024 is now a dependency of every other vendor, and no company wants to depend on a standard its competitor owns. The governance move is the predictable answer.

Operationally, little changes on the maintainer side. The MCP post says the existing governance model continues as is, maintainers keep authority over technical decisions, community proposals go through the SEP process, and Anthropic keeps funding core infrastructure. The foundation board handles budget, membership and project approval. This is a change of landlord, not of the people in the building.

The problem it solved

A year ago every model provider had its own tool-calling format and every tool had to be wrapped separately for each one. With N models and M tools you wrote N times M adapters, and most of them were slightly broken in ways only discovered in production. MCP made the tool side a server that speaks one protocol and the model side a client that speaks the same one. Write the server once and every client can call it. That is the whole idea, and it worked, which is why the download count has the shape it does.

The practical effect we noticed in applied work this year was that the argument about which tools an agent could use went away. If a data source had an MCP server it was available, and if it did not one could be written in an afternoon. The slow part of building an agent shifted from plumbing to deciding what the agent should be allowed to do with the plumbing. That is a better problem to have, and it is also a harder one.

The problems it exposed

The security best practices document in the specification is the most honest artefact the project has produced, and we would recommend reading it before connecting any agent to anything that matters. It describes a set of attack classes that only exist because a shared protocol exists. When every client can talk to every server, a flaw in the protocol layer is a flaw everywhere at once.

The confused deputy attack is the clearest example. An MCP proxy server that fronts a third-party API with a single static OAuth client ID, while letting MCP clients dynamically register, can be tricked into handing a stolen authorisation code to an attacker if the upstream provider has set a consent cookie from a previous legitimate session. The user clicks a link, the consent screen is skipped because the cookie says they already agreed, and the code lands at the attacker's redirect URI. The mitigation is per-client consent stored server-side before any forwarding happens, exact-match redirect URI validation, and a state parameter that is only set after consent is given.

Token passthrough, where a server accepts a token from a client and forwards it downstream without checking it was issued to the server, is now explicitly forbidden by the authorisation spec. The document also covers server-side request forgery through OAuth metadata discovery, where a malicious server points a client at a cloud metadata endpoint, session hijacking in multi-server deployments where a guessed session ID lets an attacker inject events into another user's stream, and local server compromise through one-click configuration that runs an arbitrary startup command. Each of these has a MUST-level mitigation in the spec. None of them are exotic. They are the standard web security failures, arriving in a new setting where the entity that acts on the payload is a language model.

The one the spec cannot fix

Prompt injection through tool results sits in a different category, and the spec addresses it only indirectly. Every tool result is text that goes back into the model's context. If a web page, a document, a database row or a calendar invite contains instructions, the model may follow them. The session hijacking section of the spec describes one path for this, where an injected server-sent event can change the tools a client believes are available. But the general case, where a legitimate server faithfully returns content that happens to contain an instruction, is a property of the model rather than the protocol.

The spec gestures at the right answer in its scope minimisation section. Broad tokens like files:* or admin:* granted up front mean a single injection can do anything the user can do. Progressive scopes, where an agent starts with read-only discovery and has to be escalated for anything privileged, limit what a successful injection can reach. That is defence in depth rather than a fix, and a protocol can only carry it so far. The rest has to happen in the client, which decides what to show the user before an action runs, and in the model, which has to learn the difference between data and instruction with an accuracy nobody has yet demonstrated at the level a bank would accept.

What holds up when every agent can call every server

The pattern we have seen work in practice this year has three parts, and none of them is clever. First, the server exposes narrow tools rather than general ones. A tool that reads one customer record by ID is safer than a tool that runs a query, even though the second is more useful, because the first bounds what an injected instruction can do. Second, the client requires a human confirmation for any tool that writes, and the confirmation shows the exact arguments. Third, the audit log records which tool was called with which arguments on behalf of which user, which is the thing token passthrough would have destroyed and the reason the spec forbids it.

The AAIF announcement is a signal that the protocol layer is settling. That frees attention for the layer above it. What we would want someone to build next is a conformance suite that checks a server against the MUST clauses in the security document, so that "MCP compatible" can start to mean "does not have the confused deputy bug" rather than "speaks the wire format". The spec now has enough MUST clauses to make that a well-defined project. Until it exists, ten thousand servers is also ten thousand places to check by hand.