MCP Specification Version History and Changes

The Model Context Protocol has a version history that most teams treat as background noise. That's a mistake. Each dated revision is a precise technical claim about what a deployed server can do and, critically, what it cannot be held accountable for. If you're running MCP in production and you don't know your spec version, you don't actually know your security posture. Let me walk you through how this protocol grew up, because the sequence matters more than any single release.

Before we get into specifics: MCP uses date-string identifiers in YYYY-MM-DD format, and those dates mark the last backwards-incompatible change, not the calendar day something shipped publicly. The first version, 2024-11-05, predates the public open-source announcement of November 25, 2024. Backwards-compatible additions don't trigger a new version string. Three status labels govern the spec at any moment: Draft, Current, and Final. The full sequence so far is 2024-11-05, 2025-03-26, 2025-06-18, 2025-11-25, and 2026-07-28, running roughly quarterly to biannual. Each one is a discrete, traceable architectural decision, not a fuzzy generation label.

What the 2024-11-05 release defined as the protocol's starting point

Anthropic engineers David Soria Parra and Justin Spahr-Summers built this. The architecture they locked in with the first version is clean, minimal, and coherent for what it was designed to do.

The message envelope is JSON-RPC 2.0. Two transports: local stdio and an early Server-Sent Events variant over HTTP. Three primitives sit at the center of everything. Tools are callable functions described with a name, a natural-language description, and a JSON Schema for inputs. Resources are readable context, things like files and database records, each identified by a URI. Prompts are reusable templates the server exposes directly to the client. Layered on top of that: an initialization handshake and capability negotiation, so client and server could establish a shared understanding before any real work happened.

Authorization was deliberately absent. The design assumed the MCP server ran as a child process of the host, communicating over stdin/stdout, and at that boundary the operating system enforces identity. You don't need an OAuth layer when the trust model is "same machine, same user." That's not a design flaw. It's a bounded architectural choice, and it was coherent for the moment.

What nobody fully anticipated was velocity. Within a few months, the community had built over a thousand MCP servers. OpenAI announced MCP support in March 2025. The protocol was no longer living in a local-only world, and the absence of an auth model was about to become load-bearing in the wrong way.

What 2025-03-26 changed when remote deployment arrived

Two headline changes drove this revision, and they're deeply connected.

The first is transport. The SSE-based remote model broke under common enterprise infrastructure. Load balancers like AWS ALB and proxies like Cloudflare impose connection timeouts and buffering limits that SSE can't reliably survive. Streamable HTTP replaced it, using standard chunked encoding. The practical effect: MCP could now traverse the same infrastructure enterprises were already running, without special carve-outs or configuration exceptions.

The second is authorization. OAuth 2.1 arrived as the baseline for remote servers. The authorization-code flow with PKCE was mandated for servers that support authorization. This was necessary and, in retrospect, incomplete. The spec at this point treated the MCP server as something close to a hybrid resource-server and authorization-server; the role separation between those two functions wasn't properly resolved. Tokens issued under this model were broad in scope and not bound to a specific server. That matters, and it becomes the primary remediation target of the next revision.

Two smaller changes deserve mention. Tool annotations arrived here, allowing tools to declare behavioral metadata like whether they're read-only or potentially destructive, giving hosts and users richer signal before execution. JSON-RPC batching was also introduced, which I'll flag immediately: it was removed in the very next revision. That kind of reversal is worth noting because it illustrates a real dynamic in protocol development. Something appears useful until it interacts with the broader system in ways that weren't visible at the time.

One practical reality for organizations auditing deployed infrastructure: SDKs adopt spec versions at their own pace. The spec publishing a new version doesn't mean your running server has updated. The prior version can remain in production for extended periods, which means the version string your server reports is the actual source of truth, not the spec's publication date.

What 2025-06-18 fixed in the authorization model and added with elicitation

This revision is where the OAuth model gets its house in order, and where a new capability enters the picture.

The core OAuth fix: MCP servers are formally classified as OAuth Resource Servers, separating that role from the authorization server. Three RFCs anchor the cleanup. RFC 9728 adds Protected Resource Metadata, enabling discovery of the corresponding authorization server. RFC 8414 handles authorization-server metadata. Most importantly, RFC 8707 Resource Indicators are required of all MCP clients, binding tokens to a specific MCP server. A token issued for one MCP server can no longer be obtained and reused by a different, potentially malicious one. PKCE, previously mandated for remote servers, is now universal. A security best practices page was formally added to the specification.

That progression from 2025-03-26 to 2025-06-18, on the auth side alone, is meaningful. OAuth went from "present but architecturally ambiguous" to "properly role-separated with token binding." Those are not equivalent security postures.

Elicitation is the other significant addition here. Servers can now pause tool execution mid-interaction and request structured input from users, using JSON Schema to define what's needed. The types are constrained to primitives: string, number, boolean. The practical benefit is that an agent can ask a user for missing information rather than failing or guessing. The practical consideration for organizations is that servers can now solicit user input mid-call, which is a new interaction surface that access policies should account for.

Structured tool output also arrived in this revision: tools can declare typed output schemas and return resource links alongside results. The MCP-Protocol-Version header became required on all subsequent HTTP requests after negotiation, making the active spec version visible at the request level. JSON-RPC batching, added in 2025-03-26, was removed here, and the protocol formally diverged from strict JSON-RPC compliance at this point.

What the 2025-11-25 release added as the protocol formalized its governance

This release is notable for two parallel stories happening simultaneously: the technical additions are real, but the governance changes are more consequential for any organization thinking long-term about MCP as infrastructure.

On the technical side: OpenID Connect Discovery 1.0 arrived in authorization server discovery. Incremental scope consent via WWW-Authenticate means clients can acquire permissions progressively, requesting only what they need for the immediate task rather than everything upfront. OAuth Client ID Metadata Documents were added as the recommended client registration mechanism. JSON Schema 2020-12 became the default dialect. Servers must now return HTTP 403 for invalid Origin headers in Streamable HTTP, closing a class of cross-origin abuse. Input validation errors were reclassified as Tool Execution Errors rather than Protocol Errors, which enables models to self-correct rather than treating a bad input as a hard failure. An experimental Tasks extension introduced tracking for durable, long-running requests with polling and deferred result retrieval. Elicitation expanded to include URL mode and richer enum support.

On the governance side, the changes are structural. A formal governance model was established with defined roles and decision mechanisms. The Specification Enhancement Proposal process, known as the SEP process, was created as the mechanism through which all subsequent spec changes are proposed and tracked. Working Groups and Interest Groups were formalized. An SDK tiering system clarified what feature support and maintenance commitments different SDK tiers require. An MCP Registry preview launched in September 2025, providing an open catalog for indexing and discovery of MCP servers, with support for public and private sub-registries.

In December 2025, Anthropic donated MCP to the Agentic AI Foundation, a directed fund under the Linux Foundation, co-founded by Anthropic, Block, and OpenAI. By this point the TypeScript and Python SDKs had each crossed one billion total downloads, with close to half a billion downloads per month recorded across Tier 1 SDKs.

The governance shift has a concrete implication for teams: changes to the spec now travel through a public SEP process with traceable discussion. Organizations can follow proposals before they become requirements, which transforms spec monitoring from a reactive activity into a prospective one.

What 2026-07-28 restructured at the protocol's architectural core

The spec authors describe this as the largest revision since launch. A release candidate locked May 21, 2026, giving SDK maintainers roughly ten weeks to validate before final publication on July 28.

The defining architectural change is a stateless core. The initialize/initialized handshake is retired. The Mcp-Session-Id header is retired. Each request now carries its protocol version, client identity, and client capabilities in the _meta field, making it self-contained. A new server/discover RPC is available for capability discovery before any tool call, but it's optional. List endpoints for tools, resources, and prompts no longer vary per connection. Servers needing cross-call state use explicit server-issued handles passed as ordinary tool arguments, which keeps the mechanism auditable and explicit rather than implicit in session infrastructure.

The practical payoff here is significant for anyone who has tried to scale MCP: standard horizontal scaling without sticky routing or shared session stores. The protocol can now run on ordinary HTTP infrastructure. Session state was a real operational burden, and removing it from the protocol's core is the kind of change that looks architectural in the spec but lands as operational relief in production.

Multi Round-Trip Requests replace and generalize elicitation for this stateless world. A server returns a result type of "input_required" with structured requests; the client retries the original call with answers in inputResponses. Mid-call user interaction is preserved without requiring persistent session state. The elicitation capability from 2025-06-18 isn't lost; it's restructured to fit the new model.

An Extensions framework was formalized. Extensions are identified by reverse-DNS IDs, negotiated through an extensions map in capabilities, and live in their own repositories with delegated maintainers; they version independently of the core spec. An Extensions Track in the SEP process gives a defined path from experimental to official. MCP Apps allow servers to ship interactive HTML interfaces rendered in sandboxed iframes, with UI-initiated actions traveling through the same JSON-RPC audit and consent path as direct tool calls. The Tasks extension, experimental in 2025-11-25, was extended and formalized here.

A formal deprecation policy was also introduced. The protocol can now retire old patterns with a defined timeline, rather than carrying indefinite backwards compatibility. That matters for long-term spec hygiene, and for organizations, it means the cadence of sunset obligations is now predictable rather than arbitrary.

How the auth model evolved across all five versions as a single thread

The individual version histories show you what changed when. This section shows you why the sequence has a direction.

Start at 2024-11-05: no auth spec, because none was needed. The OS process boundary was the trust model. Appropriate, coherent, local-only.

Move to 2025-03-26: OAuth 2.1 arrives for remote servers, PKCE required. But the server conflates resource-server and authorization-server roles. Token scope is broad. Tokens aren't bound to a specific server. Authorization is present; it is not yet sound.

2025-06-18 completes the role separation. RFC 8707 resource indicators bind tokens to a specific server. PKCE is mandated universally. Security best practices are formalized. This is the version where the OAuth model becomes defensible.

2025-11-25 makes auth composable. Incremental scope consent, OAuth Client ID Metadata Documents, OpenID Connect Discovery: these connect MCP's auth model to the enterprise identity infrastructure organizations already manage. Auth is no longer an island.

2026-07-28 restructures the surface itself. The stateless core removes session state as an auth surface. Each request carries identity in _meta. The deprecation policy means old auth patterns now have a defined end-of-life rather than lingering indefinitely.

The arc, stated plainly: auth went from absent by design, to bolted on for remote, to hardened with proper role separation, to composable with enterprise identity, to built into the request itself. Each step was a response to a real problem the previous version left exposed.

For organizations, the version of the spec your MCP server implements is the auth model your agents are operating under. Running 2024-11-05 in a remote context means running without the protections that weren't added until 2025-03-26 and hardened in 2025-06-18. Teams that inherit deployed MCP servers without knowing the spec version have no principled way to reason about what token protections are actually in place.

What knowing the spec version of a deployed server actually tells an organization

Version tracking in MCP isn't bookkeeping. It's the mechanism by which you know what your agents can do and what controls exist over them.

Before 2025-03-26: no standardized auth. If deployed remotely, tokens were passed as input parameters, because developers had no other standard to follow. Before 2025-06-18: OAuth is present, but token-to-server binding is absent; cross-server token misuse is a live exposure. Before 2025-11-25: no formal registry, no SDK tiering, no governance process; the provenance of servers is informal and largely unauditable. Before 2026-07-28: session state is in play, with sticky routing requirements and session store exposure on the table.

The MCP-Protocol-Version header, required from 2025-06-18 onward on HTTP, makes the active version visible on every request. Organizations with request-level observability can surface this without any special instrumentation. The MCP Registry, launched in September 2025, provides a catalog against which deployed servers can be checked. An ungoverned server not in any registry is, effectively, an identity without an audit trail.

One more thing worth holding: the spec version and the SDK version are not the same thing. A current SDK may still implement an older spec revision. Your observability needs to reach the spec version the server actually implements, not the SDK version it was built with.

The SEP process, formalized in 2025-11-25, changes the forward-looking calculus. Capability changes are now visible in advance, as proposals, before they ship as requirements. That means an organization with a person monitoring the SEP process has meaningful lead time before new capabilities or new security considerations land in production.

The thesis here isn't complicated, but it's easy to skip past. Knowing which spec version each deployed server runs is the prerequisite for knowing which capabilities and which security controls are actually present. Version tracking is what makes an access policy auditable rather than assumed. Without it, you're describing a posture you haven't verified.