MCP just went stateless: what the 2026 spec release candidate changes for your servers

If you run a remote MCP server in production, the most important line in the new spec is one you can act on this week: you can delete your sticky sessions. The release candidate that locked on May 21 makes the protocol stateless. No initialize handshake to babysit, no Mcp-Session-Id pinning a client to one instance, no shared session store behind the load balancer. Any request can land on any instance. For most of the teams I have helped put MCP behind a real load balancer, that single change retires a pile of infrastructure they only built because the old protocol forced them to.

This is the largest revision of Model Context Protocol since the 1.0 spec, and unlike 1.0 it is not mostly a cleanup. It is a re-architecture. The candidate locked on May 21, 2026, the final specification is dated July 28, and the gap between those two dates is deliberate: ten weeks for SDK maintainers and client implementers to validate the changes against real workloads before Tier 1 SDKs ship support. If you maintain a server or a client, that window is for you. Here is what is in it.

What "stateless" actually means for your deployment

Before this, a client called initialize, the server handed back an Mcp-Session-Id, and every subsequent request had to carry that id back to the same instance. That is why horizontal MCP deployments needed sticky routing and a shared session store: the session lived in the server's memory, so the client had to be glued to the box that held it. It worked, but it is the kind of stateful coupling that makes scaling annoying and failures ugly.

The candidate removes the handshake and the session from the protocol layer. Client information, protocol version, and capabilities now travel in _meta metadata on every request instead of once at connection setup. The practical result is that a remote server runs behind a plain round-robin load balancer with no shared store and no sticky routing. The spec also adds two required headers, Mcp-Method and Mcp-Name, so your gateway can route on the operation without parsing the body. If you have ever run deep packet inspection at the gateway just to tell a tools/list from a tools/call, that is gone.

The session you still need, and where to put it

Stateless protocol does not mean stateless application, and this is where I expect teams to trip. Plenty of real tools need to carry state across calls: a shopping basket, a browser session, a multi-step form. The spec's answer is the one HTTP APIs have used for twenty years. Mint an explicit handle from a tool (a basket_id, a browser_id) and have the model pass it back as an ordinary argument on the next call. The state lives in your database keyed by that handle, not in the protocol. It reads as slightly more work in the tool definition, and it is the right trade: the handle is visible, auditable, and survives an instance dying mid-session.

Server-to-client requests get the same treatment. Where the old model leaned on a long-lived SSE stream to ask the client for more input mid-call, the candidate returns an InputRequiredResult that carries the input request and the request state. The client gathers the responses and re-issues the call with inputResponses echoed back, so any instance can pick up the retry. More round trips, far less operational pain.

Extensions, Apps, and Tasks: the core stopped trying to do everything

The other structural move is that the spec stopped growing in the middle. Extensions are now a formal framework with reverse-DNS identifiers, capability negotiation, and versioning independent of the core. Features that used to bloat the base protocol become opt-in extensions on a Standards Track. Two of them matter most day to day.

• MCP Apps. A server can ship an interactive HTML interface rendered in a sandboxed iframe, with declarative UI templates the host can pre-fetch and security-review before anything runs. This is the sanctioned answer to the question every consumer-facing MCP integration was hacking around: how does a server show a real UI without the host trusting arbitrary markup.
• Tasks. Long-running work moved out of the experimental core and into an extension with a proper lifecycle. A server answers a tools/call with a task handle, and the client drives it with tasks/get, tasks/update, and tasks/cancel. If you have an agent that kicks off a ten-minute job and then polls a homegrown status endpoint, this replaces that with a protocol primitive.

Authorization finally speaks OAuth properly

Six of the proposals in this candidate are about authorization, and they pull MCP into line with how OAuth 2.0 and OpenID Connect are actually deployed. The obligations that land on client implementers: validate the iss parameter per RFC 9207, declare an OpenID Connect application_type during Dynamic Client Registration, bind credentials to the authorization server that issued them, and follow OIDC patterns for refresh tokens. Scope accumulation during step-up authentication is finally spelled out instead of left to interpretation.

If you adopted the 1.0 enterprise auth profile, OAuth 2.1 with PKCE, which is the thing I told everyone shipping to customers to adopt in the 1.0 migration notes, you are most of the way there. The new requirements are hardening, not a rewrite. But they are exactly the kind of detail a security review catches, so walk the six proposals before you assume your existing flow passes.

What is being deprecated, and the runway you get

Three features get deprecated in this release: Roots, Sampling, and Logging. The important word is annotation-only. Nothing is removed. They keep working in this release and in every spec version published within a year of it, so this is not an emergency. It is a planning item.

If any of these are load-bearing in your server, the move is to schedule the migration inside the twelve-month window, not to scramble. The deprecation policy itself is the quiet good news here: the spec now has a formal feature lifecycle (Active, Deprecated, Removed) with a minimum of twelve months between a deprecation and the earliest it can be removed. MCP is now something you can build a roadmap against.

What this breaks in servers you already wrote

Most working servers keep working, same as the 1.0 transition. The breakage is narrow and worth checking explicitly. Two things go on the test list.

• The missing-resource error code changed from the MCP-custom -32002 to the JSON-RPC standard -32602. If any client code branches on -32002, it stops matching. Grep for it.
• Tool schemas now use full JSON Schema 2020-12, so composition (oneOf, anyOf, allOf), conditionals, and references are all in play, and output schemas are unrestricted. That is a capability gain, not a break, but a client that hand-rolled a partial JSON Schema validator will need widening. It is also a good moment to revisit how you write tool schemas at all, which is the whole argument in tool descriptions are prompts, fix the registry.

Beyond those, the work is adopting the stateless transport in your SDK once Tier 1 support lands, and deciding whether you want the new extensions. Neither is forced on the final-spec date. The deprecations and the error-code change are the only items with a clock on them.

The migration I would run in the ten-week window

1. 01
   Pin your SDK version now

   Before you touch anything, pin the MCP SDK version your servers and clients run today. The next ten weeks will ship a lot of SDK churn as Tier 1 libraries chase the candidate. You want to upgrade on purpose, not get dragged.
2. 02
   Grep for -32002

   Find every place client code branches on the old missing-resource error code and plan the switch to -32602. Small change, easy to miss, breaks silently.
3. 03
   Inventory your session state

   List every server that holds state across calls today. For each, decide the explicit handle that replaces it (basket_id, browser_id, job_id). This is the design work the stateless core asks of you, and it is better done on a whiteboard than under deadline.
4. 04
   Re-read your auth flow against the six proposals

   If you ship to customers, walk your OAuth and OIDC flow through the iss validation, application_type, and refresh-token requirements. Fix the gaps while it is a code review and not an incident.
5. 05
   Schedule the deprecations, do not rush them

   Roots, Sampling, Logging: note where you use them, put the migration in the next two quarters, move on. You have twelve months minimum.
6. 06
   Validate against a real workload before July 28

   The whole point of the window is that implementers test the candidate against production-shaped traffic and file what breaks. If you run MCP at any scale, you are exactly who that feedback loop needs. Stand up the candidate behind a round-robin balancer and throw real traffic at it.

Who should move now, and who can wait

If you maintain an SDK, a client, or a widely used server, move now. The candidate is locked, the shape will not change much before July 28, and the validation window exists precisely so your feedback lands before the spec is final. Waiting means shipping support late and finding the breakage in production instead of in the RC.

If you are an application team running a couple of servers behind your own gateway, you can wait for your Tier 1 SDK to ship stable support, then adopt the stateless transport as a deliberate upgrade. Do the cheap, clock-bound work now (the error-code grep, the auth review, the deprecation inventory) and let the bigger transport migration follow the SDK. For enterprises standing up MCP governance on top of all this, the stateless model actually makes the governance layer simpler, a thread I pulled on in the Databricks Unity AI Gateway write-up.

MCP spent its first year proving the idea and its 1.0 proving it could be stable. This candidate is the version that decided to scale: stateless core, opt-in extensions, real OAuth, a deprecation policy you can plan against. It is the least glamorous release the protocol has had and probably the most important. Read the spec, pin your SDKs, and use the ten weeks.

Source: the Model Context Protocol blog, "The 2026-07-28 MCP Specification Release Candidate" at https://blog.modelcontextprotocol.io/posts/2026-07-28-release-candidate/.