How MCP Grew

A standard like USB did not arrive finished. It went from USB 1 to 2 to 3 to USB-C, each version fixing what the last got wrong while trying not to break what already worked. MCP grew the same way, only far faster: four revisions in barely over a year, and the sequence tells you what actually matters when you connect AI to the real world.

This is the last part of a series on MCP. The earlier pieces took the protocol apart. This one steps back to the story: how MCP got the shape it has, how it spread, and where it is still moving, as of mid-2026.

Four revisions, one stable core

MCP was introduced and open-sourced by Anthropic in late 2024, and it has matured through a small number of spec revisions. The version numbers are just dates: a revision is stamped with the date of its last backwards-incompatible change, and a client and server agree on one during the handshake.

The 2024-11-05 release established the core: JSON-RPC, the initial five primitives, capability negotiation, and the stdio and original HTTP transports. 2025-03-26 was about going remote and getting serious: the OAuth 2.1 authorization framework, Streamable HTTP replacing the old two-endpoint HTTP+SSE transport, tool annotations, audio, and completions. 2025-06-18 hardened it: structured tool output, the elicitation primitive, the OAuth resource-server model with RFC 8707 token binding, and resource links. And 2025-11-25, the current version and the protocol's one-year anniversary release, is the largest yet: an experimental Tasks mechanism for asynchronous work, tool-calling inside sampling, a much richer elicitation, icons on tools and resources, OpenID Connect discovery and incremental consent for auth, a formal extensions framework, and a real governance structure.

The striking thing across all four is how stable the core stayed. Five of the six primitives were there from day one, and only elicitation was added later, in 2025-06-18; the rest did not change. What grew was everything around them: remoting, security, async, discovery, and governance. That is the healthy signature of a protocol that got its fundamentals right early. When you read a version string, treat it as a contract and pin the one you are building against; the differences between revisions are real but they live at the edges, not the center.

Click along the timeline to see what each revision actually added:

From one company to shared infrastructure

The reason MCP is worth learning is that it stopped being any single vendor's project astonishingly fast, and then went a step further than most standards do.

Within months of launch the major model providers lined up behind it, and the cloud platforms followed. By 2026 that had turned into shipped product: OpenAI built its Apps SDK for ChatGPT on MCP; Google offers a fleet of managed remote MCP servers across its cloud; Microsoft is baking MCP into Windows and Azure; and the AWS MCP server, giving agents authenticated access to thousands of AWS APIs, reached general availability in 2026. Two developments matter beyond the vendor list. An official server registry launched in preview in September 2025, giving the ecosystem a standard way to publish and discover servers, with private sub-registries for enterprises built on top. And in December 2025, Anthropic donated MCP to the Agentic AI Foundation, a directed fund under the Linux Foundation, putting it under open, vendor-neutral governance with a steering group, working groups, and a public specification-enhancement-proposal process. A server you write is no longer a bet on one company's ecosystem; it is a bet on a foundation-governed socket, and the socket is standard.

Extensions: MCP Apps

One 2026 development is worth calling out because it points at where the protocol is headed. The extensions framework added in 2025-11-25 lets optional capabilities be negotiated cleanly, and the first official extension, MCP Apps, a joint effort of Anthropic, OpenAI, and the MCP-UI community, brings interactive user interface to tool results. Instead of a tool returning only text, it can return a small app the host renders. That is a meaningful widening of what "a tool result" can be, and it is the kind of thing the extensions framework exists to enable without bloating the core.

The frontier

A standard this young is still resolving real questions, and it is worth knowing where the edges are.

• Discovery, from preview to GA. The registry answered "how do I find servers," but as of mid-2026 it is still a preview, and the shape of GA, along with how private and enterprise sub-registries federate, is being worked out.
• Remote and enterprise. The center of gravity has shifted from local stdio servers to remote, authenticated, multi-tenant ones. Making those safe and operable, isolation, quotas, auditability, is the current frontier of practice, and much of the 2026 roadmap points there.
• The durable value. As models read more context, some of what people once reached to MCP for, dumping documents into a call, can be done other ways. MCP's lasting value is not context-stuffing; it is actions and live data, the tool calls that touch real systems, and now the interactive apps those calls can return. That is the part no context window replaces.

The through-line of the series

Five pieces, one protocol. A stateful JSON-RPC session between a host and a set of isolated servers, exposing six primitives, negotiated up front, carried over stdio or Streamable HTTP, secured with OAuth and bound tokens, and now discoverable through a registry and extensible through things like MCP Apps. Learn that frame and you can read any MCP server, any spec revision, and any new tool in the ecosystem, and know where it fits. The protocol will keep evolving at the edges. The center, the part worth learning once and keeping, is the part that has not moved since day one.