The release candidate for the next version of MCP (Anthropic’s protocol for connecting AI models to external tools and data) is now available, and the MCP blog calls it the largest revision of the protocol since launch. The final specification ships on July 28, 2026. The candidate contains breaking changes.
The headline change is a stateless protocol core. Under the previous 2025-11-25 spec, every MCP client had to open a session with a server before making tool calls: a handshake exchanged an Mcp-Session-Id, and that ID pinned subsequent requests to a specific server instance. Horizontal deployments required sticky sessions, shared session stores, and deep packet inspection at the gateway. The new spec removes the handshake and the session header entirely. Protocol version, client info, and capabilities now travel as metadata on each individual request, meaning any server instance can handle any request. Teams running MCP servers on serverless infrastructure or behind round-robin load balancers will recognize what this unlocks: deployment patterns that the prior spec made structurally difficult.
The spec still permits stateful applications. Servers that need continuity across calls can issue an explicit handle from a tool and have the model pass it back as an argument on later calls. The RC documentation notes this pattern can outperform hidden session state because the model can reason about and compose handles across steps.
A new extensions framework formalizes a capability that existed informally before. Extensions are now identified by reverse-DNS IDs, negotiated through a capabilities map, and versioned independently of the core spec. Two official extensions ship with the RC. MCP Apps lets servers deliver interactive HTML interfaces that hosts render in a sandboxed iframe, with UI actions flowing through the same audit path as direct tool calls. The Tasks extension (previously experimental in the core spec) reshapes long-running work around the stateless model: a server returns a task handle, and the client drives it with tasks/get, tasks/update, and tasks/cancel. The prior experimental Tasks API is not forward-compatible; teams that shipped against it will need to migrate.
Authorization hardening accounts for six specification enhancement proposals. The changes bring MCP’s auth layer closer to how OAuth 2.0 and OpenID Connect actually behave in production: clients must now validate the iss parameter on authorization responses (a fix for a mix-up attack class that is more common in MCP’s single-client, many-server pattern), and clients declare their OpenID Connect application_type during Dynamic Client Registration to avoid the common case where an auth server defaults a desktop or CLI client to “web” and rejects its localhost redirect URI.
Three features are formally deprecated under a new lifecycle policy: Roots, Sampling, and Logging. All three continue to work in this release and in any spec version published within a year of it. Removing them requires a separate proposal under the lifecycle rules. The formal deprecation policy is a direct response to the fact that this spec breaks implementations; it is the mechanism intended to prevent a repeat.
The structural context worth noting: MCP is an Anthropic-led specification, not an IETF or W3C track. The project has its own governance process (Specification Enhancement Proposals) and its own maintainers. OpenAI’s Realtime API and Google’s Agent-to-Agent protocol address adjacent problems (real-time model I/O and multi-agent coordination, respectively) under similarly vendor-controlled processes. Whether MCP becomes the durable cross-vendor standard for tool integration or a broadly adopted Anthropic-flavored default depends on adoption outside the Anthropic ecosystem, which the RC does not address.
For teams running MCP servers in production now, the practical checklist is concrete: audit any client code that matches on the -32002 error code (it changes to the JSON-RPC standard -32602); plan a migration off the 2025-11-25 experimental Tasks API before July 28; and if your auth server does not yet return the iss parameter on authorization responses, start that work because a future spec version will require clients to reject responses that omit it.
Published on the Model Context Protocol blog on 2026-05-22.
