MCP Turns One: What the Protocol Actually Shipped vs What We Wanted

The Model Context Protocol was published by Anthropic on 25 November 2024. Twelve months and change later, the protocol has a working group, a registry of reference implementations, and a small but real footprint in production agentic systems. It also has a list of unsolved problems that the first-anniversary commentary has been politely declining to look at.

This piece is a working engineer’s read on what shipped, what got adopted, what is still missing, and what we wanted from MCP that the protocol — as currently specified — does not give us. We are not interested in the standards-body politics; we are interested in whether the spec, in its current state, is doing what it was supposed to do.

What MCP shipped

The protocol’s core, as published, is small. It defines a JSON-RPC 2.0 message envelope, a set of standard methods (initialize, tools/list, tools/call, resources/list, resources/read, prompts/list, prompts/get), and a transport story over stdio and HTTP+SSE (later HTTP+streamable). The reference implementations — @modelcontextprotocol/server-filesystem, server-git, server-postgres, server-puppeteer, and a half-dozen others — are now hosted under the modelcontextprotocol GitHub organization.

The 2025 spec revisions added structured sampling/createMessage (so a server can ask the host model to run a completion on its behalf), notifications/progress, the roots concept for filesystem scoping, and the elicitation flow for asking the user a structured question mid-tool-call. The reference SDKs now exist in TypeScript, Python, Go, Rust, and Kotlin.

The host coverage, as of late 2025, is the part that surprised us in a good way. Claude Desktop has shipped MCP natively since the launch month. Cursor, Windsurf, Cody, Continue, and Zed have added MCP client support during 2025. The OpenAI Responses API exposes an MCP-shaped tool surface (with caveats — more below). The Anthropic API supports MCP-shaped tool definitions over the wire.

That is the shipping list. It is more than the first-anniversary commentary tends to credit, and less than the marketing tends to claim.

What got adopted

The spec is not the protocol. The protocol is what people deploy. The adoption picture in late 2025 has three distinct populations.

Local-development clients. Claude Desktop, Cursor, Zed, and the IDE forks of Continue collectively have hundreds of thousands of installations with at least one MCP server configured. The most common configurations are the filesystem server, the git server, a SQLite or Postgres server, and a handful of bespoke “wrap-my-API” servers written in 50-100 lines by the host’s user. This is the layer where MCP is working as advertised. The protocol’s stdio transport is fine for local processes. The schema is approximately right. The user experience is rough but acceptable.

Hosted-agent clients. A smaller number of hosted products — Claude Cowork, Cursor’s cloud agent, a handful of OpenAI-hosted code assistants — accept user-configured MCP servers running on the user’s own infrastructure. The transport here is HTTP+streamable, the authentication story leans on OAuth 2.1, and the experience is materially worse than the local case. Users hit OAuth flows they did not expect. Token refresh failures show up as silent tool-call failures. We have not yet seen a hosted-agent client that does the network-error UX well.

Production agentic systems. A much smaller number, mostly internal, expose MCP servers as a stable internal tool plane. We have spoken with two enterprise teams shipping internal MCP servers behind their corporate auth proxy as the canonical way for their AI products to call into legacy systems. The adoption here is real but quiet. Public examples in 2025 include the Sentry MCP server, Cloudflare’s workers-mcp, and the Pulumi ESC MCP server.

The shape of the adoption tells you something the protocol’s promoters do not emphasize. MCP is a local-development protocol that is being slowly hardened into a production protocol. The order matters. The spec was designed against the local case. The production case is being grafted on.

What we wanted that did not ship

We had four hopes for MCP at launch. The protocol is, twelve months in, partway delivering on two and not yet delivering on two.

1. A real authentication and authorization model. MCP gestures at OAuth 2.1 for HTTP transports but does not specify the consent model, the scope vocabulary, or the audit story. The spec’s authoritative line is roughly “use the existing OAuth 2.1 RFC suite,” which is correct but not enough. The result is that every host has invented its own consent UI, every server has invented its own scope vocabulary, and the audit trail varies between “what the host logs” and “nothing.” We did not expect a finished identity story in a year. We did expect more progress than we got.

2. A serializable tool-call trace. A tool call invoked by an agent is, in production, the kind of event you want to audit, replay, and reason about across systems. MCP gives you the call and the response. It does not give you the trace identifier, the principal, the call-graph context, or the audit envelope. The OpenTelemetry working group’s gen_ai semantic conventions are moving toward filling this gap, but the gap is not in the protocol itself. A useful interop layer would have made tool-call observability a first-class part of the spec.

3. A registry the field actually uses. The modelcontextprotocol GitHub organization hosts the reference servers. There is no canonical registry of community servers that publishes provenance, version compatibility, and a minimum-quality signal. Awesome-MCP lists exist on GitHub and have hundreds of entries; we cannot find a single canonical source. The result is that picking an MCP server for a non-trivial integration is, in 2025, a code-review exercise. We expected a real registry to exist by now. It does not.

4. A model for long-running and asynchronous tool calls. MCP’s tool-call shape is request-response with a progress notification. It does not have a first-class concept of a tool call that takes 12 hours, returns nothing, and produces a side-effect the agent can observe at a later turn. The 2025 streamable HTTP transport helps with intermediate updates. It does not solve the underlying shape. A real production agent fleet runs many calls of this kind, and the protocol is making the integrator invent the pattern.

What did ship that we did not ask for

Two things shipped that we did not expect and that we now think were correct.

Resources as a first-class concept. Early MCP discussions treated everything as a tool. The spec separated tools/call from resources/read and prompts/get, on the basis that read-only data, tool invocations, and prompt templates are three different things the host should treat differently. We thought this was over-engineered at the time. We were wrong. The separation has paid off in host UX — Claude Desktop attaches resources as visible context, runs tool calls with explicit confirmation, and treats prompts as one-shot templates — in a way that a single “everything is a tool” surface would not have.

Sampling. A server asking the host to run a model completion on its behalf was the most controversial part of the early spec. It looks, on paper, like a security footgun. In practice it is the part of the protocol that lets MCP servers be more than glue code. A server that can ask the host to summarize a long file, or extract structured data from a captured page, becomes a small composable agent in its own right. The pattern is being used in a handful of production servers and is, in our reading, an underrated part of why MCP feels different from a pure RPC layer.

The competitor question

The honest comparison MCP faces in late 2025 is not OpenAI’s Function Calling — which is a model API, not an interop protocol — but two adjacent specs.

The first is Google’s A2A (Agent-to-Agent Protocol). A2A is at a different layer — agent-to-agent rather than agent-to-tool — and the two specs were promoted by their respective sponsors as complementary at the AAIF launch. In practice they overlap at the edges (an A2A “skill” can be backed by an MCP tool; an MCP server can call out to an A2A peer). The overlap is not yet a problem, but it will become one if either spec absorbs the other’s responsibility.

The second is OpenAI’s hosted-tool surface in the Responses API, which exposes a built-in mcp tool type for invoking MCP servers from inside an OpenAI completion. This is an interesting move — OpenAI is adopting MCP as a client without adopting MCP’s vocabulary in their own SDK surface — and it has the side effect of making MCP the de facto cross-model tool wire, even though the protocol’s home is Anthropic.

Neither competitor is replacing MCP in 2026. Both are incentivizing the spec to grow up faster than it might have otherwise.

What we expect from year two

A reasonable working list for the protocol’s second year, in our reading:

• A proper auth/audit annex. Not a wholesale rewrite — the OAuth 2.1 base is fine — but a canonical consent flow, a standard scope vocabulary, and an audit-envelope shape.
• A registry with a quality signal. The current state-of-the-art is “the README says it works.” That is not good enough for production.
• First-class long-running tool calls. A standardized pattern for the 12-hour call that yields, and the way an agent observes the side effect on a later turn.
• A spec-level statement of relationship with A2A. Either the two specs declare orthogonality cleanly, or one absorbs the other. The current ambiguity will cost the integrators time.

The first year of MCP shipped a working protocol with a real user base and an honest set of unsolved problems. That is more than most standards-body launches achieve. The second year’s question is whether the protocol’s maintainers can resist the temptation to ship optional features and focus on the missing-load-bearing-pieces list above. The answer will determine whether MCP becomes the field’s interop substrate or just its best-marketed one.