mcp spec updates

The original launch and first revision set a baseline worth knowing

The November 2024 launch established the fundamentals: synchronous tool calling, stdio and HTTP transports, basic resource and prompt primitives. A coherent, working protocol. The kind of thing you could build on.

The March 2025 revision was largely stabilization. No reported breaking changes. Think of it as the team catching their breath after real-world use exposed the rough edges.

What that first version conspicuously lacked was a formal authorization model. Authentication was left, for the most part, to implementers. That sounds reasonable as an initial design decision, but in practice it meant every team building on MCP was also building their own security layer, with all the variance in quality that implies.

There was no structured output from tools either. Everything came back as raw text, which meant downstream models had to parse free-form strings to act on results. No reliable, auditable, field-level output. No mechanism for a server to pause mid-session and ask a user for additional information. And session state lived in memory, per server instance, which meant scaling required sticky sessions. Route a request to the wrong replica and the session broke.

These were not obscure edge cases. Any team deploying MCP in a serious context would hit all four of them almost immediately. But what if those four gaps weren't independent problems — what if they were symptoms of the same underlying design decision? The 2025-06-18 release is a direct, deliberate response to each.

How 2025-06-18 formalized authorization and gave tools structured outputs

The authorization change in 2025-06-18 is the one that matters most. It's worth slowing down here.

MCP servers were formally classified as OAuth 2.0 Resource Servers. Clients requesting tokens must now include a resource parameter, per RFC 8707, and that parameter explicitly binds the access token to a specific MCP server. Without that binding, a token issued for one server could be presented to a different server, what's called a confused deputy attack. The token is legitimate; it's simply being used somewhere it was never intended to go. RFC 8707 closes that. But how does this affect the teams who had already built their own authorization layers on top of the earlier spec? It means their security posture may be stronger than the baseline but no longer maps cleanly to the formal model — a compliance gap worth auditing.

Alongside the classification came a dedicated Security Best Practices page. Token passthrough, session hijacking, PKCE requirements, redirect URI validation, proxy misuse: the spec now addresses each explicitly. That's not just documentation. It's a statement about the threat model the protocol expects to operate inside.

The MCP-Protocol-Version header, required on all HTTP requests after the initial handshake, solves a quieter problem. Without explicit version negotiation, a mismatch between client and server could silently break behavior in ways that were hard to diagnose. The header makes the version contract visible.

Structured tool output arrived via the structuredContent field. Tools can now return typed JSON instead of raw text, and that changes things downstream in ways worth naming: models parse and act on structured results more reliably, and outputs become auditable at the field level. You can examine exactly what a tool returned, field by field, rather than trying to extract meaning from an unstructured string.

Elicitation is the fourth change, and conceptually the most interesting. A server can now pause tool execution mid-session and, via a JSON schema, request specific information from the user. A booking tool asks for travel dates. A file processor asks about preferred output format. The governance implication is non-obvious: users are now formally part of the tool execution path. That's a new human-in-the-loop surface, and your review processes need to account for it.

The title field addition feels minor, separating the human-facing display name from the programmatic identifier on tools, resources, and prompts. But consider what it closes. Before this, what a user saw in an interface and what actually executed could diverge silently. The separation makes that divergence visible.

What 2025-06-18 didn't solve: authorization discovery still required per-server configuration, incremental scope consent had no mechanism, and asynchronous execution remained absent. Those gaps set up the next release precisely.

What 2025-11-25 added to make MCP viable for production deployments

OpenID Connect Discovery 1.0 support addressed the per-server configuration burden directly. Servers can now be discovered and authorized through standard OIDC flows. OAuth Client ID Metadata Documents were added as a recommended client registration mechanism. Together, these changes mean you're not manually configuring authorization for each new MCP server you add to an environment, which, if you've ever maintained a large integration estate, is not a small thing.

The incremental scope consent mechanism, via the WWW-Authenticate header, deserves particular attention. Clients can now acquire additional permissions mid-session without re-authenticating from scratch. For enterprise workflows where a user's scope of activity expands over the course of a session, this is the difference between a workable system and a frustrating one.

The sampling extension added tool calling support in a way that changes agent architecture meaningfully. Servers can now include tool definitions and specify tool choice behavior in sampling requests. The practical result: servers can orchestrate multi-step agent behavior internally, without the client driving every round trip. Server-side agent loops become viable. The client is no longer the sole orchestration surface.

Tasks appeared here as an experimental feature for the first time. A durable request can be tracked, polled, and have its results retrieved asynchronously. The "experimental" label is telling. The team shipped it knowing that production use would surface redesign requirements. The 2026 release candidate confirms that judgment.

An error handling change that gets less attention than it deserves: input validation errors must now be returned as Tool Execution Errors rather than Protocol Errors. Previously, bad input terminated the exchange. Now, a model can self-correct and retry without breaking the session. That's a meaningful reduction in brittleness for any workflow where inputs are generated dynamically.

The governance formalization in this release is, in some ways, as consequential as the technical changes. The SEP (Specification Enhancement Proposal) process was established with defined roles and decision-making mechanisms. Working Groups and Interest Groups were formalized. An SDK tiering system was introduced so developers could assess compliance speed, maintenance responsiveness, and feature completeness before committing to a dependency. The MCP Registry reached approximately two thousand entries by November 2025, representing 407% growth from the initial batch announced in September 2025.

That last number is worth sitting with. An ecosystem growing that fast needs governance infrastructure, not just technical infrastructure. The 2025-11-25 release provided both. MCP was no longer a single-vendor specification; it was a governed standard with community input paths. For any organization making long-term architectural bets, that transition matters more than most of the feature additions.

Why the 2026-07-28 release candidate is a structural rethink, not an incremental update

The release candidate was published May 21, 2026, with the final spec scheduled for July 28. The deliberate ten-week validation window is its own signal: SDK maintainers and client implementers are testing against real workloads before the spec locks. You don't do that for an incremental update.

The foundational change is the stateless protocol core, driven by two SEPs. The previous model required every session to begin with an initialize/initialized handshake, and every subsequent request to echo an Mcp-Session-Id header, with server state held in memory. When a request landed on a different replica, that replica saw no session and broke. Sticky sessions were the only way to scale, and anyone who has run sticky sessions in a high-availability environment knows exactly what that costs operationally.

The new model distributes what used to be session state into the payload itself. Every request carries its own protocol version, client identity, and negotiated capabilities inside the _meta object on the JSON-RPC envelope. A server/discover endpoint replaces the stateful handshake. With that, MCP servers can be load-balanced with a simple round-robin, and the infrastructure complexity that sticky sessions introduce evaporates.

Two new routing headers follow from this. Mcp-Method and Mcp-Name allow gateways to route by method and tool name at the header level, without parsing the JSON body. ttlMs and cacheScope on list and resource results give intermediaries a standard caching contract. These are the details that make the stateless architecture composable with existing infrastructure patterns rather than just theoretically elegant.

Statelessness is the load-bearing decision of this release, quite literally. Tasks, MCP Apps, Multi Round-Trip Requests, and the Extensions framework all follow from it. On a stateful session model, none of them would be coherent.

The new interaction patterns the stateless core enables: Tasks, MRTR, and MCP Apps

The Tasks extension in 2026-07-28 is a redesign, not a continuation, of the experimental feature from 2025-11-25. Production use of the earlier implementation surfaced enough issues that the team moved it out of the core spec and into an extension. That's a governance decision as much as a technical one, and it reflects a kind of institutional candor about what "experimental" actually means.

The new lifecycle is explicit: a server responds to a tools/call with a task handle. The client then drives that task with tasks/get, tasks/update, and tasks/cancel. Task creation is server-directed. The client advertises support for the extension; the server decides when a particular call should run as a task. Long-running tasks are trackable and cancellable by design. The lifecycle is auditable because it's explicit, not because someone thought to log it.

Multi Round-Trip Requests, the MRTR extension, replaces how prior versions handled server-initiated calls like sampling and elicitation. Previously, a server would pause and hold a connection while waiting for user input. The new model is architecturally cleaner: the server returns an InputRequiredResult carrying the questions it needs answered and an opaque requestState blob. The client gathers the responses and re-issues the original call, this time with inputResponses included. All state lives in the payload. No held connection. Entirely consistent with the stateless core.

MCP Apps introduces something that will expand your security threat model. It is also worth considering what the governance architecture here implies before treating this as a straightforward capability addition. Servers can now ship interactive HTML interfaces that hosts render in a sandboxed iframe. Tools must declare their UI templates ahead of time; hosts can prefetch, cache, and security-review them before anything runs. UI-initiated actions travel through the same JSON-RPC audit and consent path as direct tool calls, not a separate channel. Unknown UI code cannot execute at runtime without prior review. That's a deliberate constraint, and it's the right one.

Authorization tightening and the Enterprise-Managed Authorization extension

The iss parameter validation requirement, per RFC 9207, addresses mix-up attacks, a category of vulnerability that becomes particularly relevant in MCP's specific usage pattern: one client communicating with many servers simultaneously. Without iss validation, an attacker who can intercept authorization responses could substitute their own authorization server's response for a legitimate one. It's a subtle attack, and it's exactly the kind of thing that gets overlooked when teams are moving fast.

The applicationtype declaration during Dynamic Client Registration resolves a common friction point for non-browser clients. Previously, authorization servers could default desktop or CLI clients to the "web" application type and subsequently reject localhost redirect URIs. Explicit applicationtype declaration removes that ambiguity.

The Enterprise-Managed Authorization extension, which reached stability on June 18, 2026, is the most organizationally consequential change in the entire arc. It replaces per-server OAuth consent prompts with a single enterprise login. Seven MCP servers were supporting it at the stability announcement. The central implication: access policy becomes organizational rather than per-server. An organization manages authorization for all connected MCP servers from one place, which is a different model of governance entirely.

To understand why this works, we must first look at the progression that made it possible: OAuth Resource Server classification established the token-binding foundation; OIDC Discovery eliminated per-server manual configuration; incremental scope consent made step-up authentication workable; enterprise-centralized authorization collapsed the per-server consent model into a single organizational control plane. Each release tightened one layer of the same authorization stack, which is not how most protocols evolve when they're moving quickly.

What the Extensions framework and formal deprecation policy mean for long-term governance

SEP-2133 gives the Extensions framework something it lacked in the 2025-11-25 release: a formal process. Extensions are now identified by reverse-DNS IDs, negotiated through an extensions map on the capabilities object, independently versioned, and maintained in dedicated repositories with delegated maintainers. A new Extensions Track in the SEP process provides a defined path from experimental to official.

For teams making long-term architectural decisions, this matters practically. New capabilities can be adopted and governed without waiting for a core spec revision. The protocol can evolve; existing deployments need not break.

W3C Trace Context propagation, via SEP-414, deserves more attention than it typically receives. The traceparent, tracestate, and baggage key names are now fixed in the spec. A distributed trace originating in a host application can follow a tool call through the client SDK, through the MCP server, and through any downstream calls, all as a single coherent span tree in any OpenTelemetry-compatible backend. Observability is no longer an implementation detail left to individual teams. It's a first-class protocol concern, and if you've ever tried to debug a multi-hop agent failure without coherent trace context, you know why that matters.

The formal deprecation policy establishes an Active to Deprecated to Removed lifecycle with a minimum of twelve months between deprecation and earliest possible removal. Three features were formally deprecated in 2026-07-28: Roots, replaced by tool parameters or config; Sampling, replaced by direct provider API calls; and Logging, replaced by stderr or OpenTelemetry. None of these break on July 28. The twelve-month floor is a guarantee, not a suggestion.

The conformance requirement is the policy change with the longest tail. A Standards Track SEP can no longer reach Final status without a matching scenario in the conformance suite. The same suite scores official SDKs against the tier system. The practical meaning is simple but significant: spec changes must be testable, and SDK compliance must be demonstrable, not asserted. That's a higher bar than most protocols hold themselves to.

Reading the version arc as a map of expanding agent capability and expanding attack surface

I want to push back slightly on how this version history usually gets discussed, because I think the framing of "capability additions" obscures something important.

Every capability addition is also an attack surface addition. The two are not separable, and treating them as distinct things leads to governance gaps. Structured tool output makes agents more reliable and makes outputs auditable; it also means a compromised tool can return carefully crafted JSON that downstream parsing logic may interpret in unintended ways. Elicitation creates a human-in-the-loop surface that improves user control; it also creates a social engineering surface if the server's prompts are attacker-controlled. MCP Apps enable rich interfaces with strong pre-declaration constraints; they also introduce a new sandboxed execution environment that will be probed, because every new execution environment gets probed.

One might argue that the Security Best Practices page added in 2025-06-18 was sufficient acknowledgment of these risks — but does documentation alone change how teams actually behave when moving fast? What's notable is that the pattern of pairing new capabilities with new controls has held through subsequent releases. That's not the typical trajectory for a young protocol moving quickly.

What the version arc actually maps is the progressive specification of what it means to be a trustworthy agentic system. The original spec described what agents could do. The subsequent releases have progressively described the conditions under which agents are permitted to do those things: who authorized the action, under what token scope, with what session provenance, observable by whom, auditable at what level of granularity, reversible via what mechanism.

For practitioners, each date stamp in the spec is not just a changelog entry. It marks when the protocol's trust model changed. If your security review predates 2025-06-18, you have not reviewed token binding. If it predates 2025-11-25, you have not reviewed OIDC discovery, or the governance formalization that changed how the spec itself evolves. If it predates the 2026-07-28 release candidate, you have not reviewed a stateless architecture where session state is distributed into payloads and Tasks, MRTR, and MCP Apps are live.

The version arc is not a feature list. It is a record of how the protocol's attack surface has expanded, and how each expansion has been matched, sometimes imperfectly, with a new layer of control. Reading it that way gives you something more useful than a changelog: a map of what your security and governance posture needs to cover, and a clear signal of when that map was last redrawn.