On May 28, 2026, the MCP maintainers published the release candidate for the next specification, dated 2026-07-28. The RC eliminates protocol-level sessions, mandates two new HTTP headers, changes an error code that client code almost certainly pattern-matches against, introduces caching semantics via new response fields, locks down distributed trace propagation, and deprecates three first-class primitives. Six material changes in a single spec bump is not a routine version update. But the one that forces real architectural decisions is the first one.
The Mcp-Session-Id header and the protocol-level session that came with it are removed. With both gone, any MCP request can land on any server instance, and the sticky routing and shared session stores that horizontal deployments needed before are no longer required at the protocol layer.
That sounds like infrastructure housekeeping. It isn't. It's a question about your server's design.
The problem with hidden state
In previous MCP versions, a Streamable HTTP client established a session first. The server returned an Mcp-Session-Id, and the client carried that ID into later requests. That meant deployments had to care about sticky sessions, shared session stores, and gateway behavior that understood enough about MCP to route traffic correctly. That's manageable during experimentation, but it gets painful when you're running remote MCP servers behind load balancers, gateways, and rate limiters.
The standard workaround was messy. The common fix was sticky sessions at the load balancer. Some teams added a Redis-backed session store. Others built a gateway that inspected the request body to extract the session ID before routing. All of these solutions exist because the protocol pushed session affinity onto infrastructure.
The deeper issue isn't the infrastructure cost. It's that session state hidden in transport metadata is invisible to the model. The model cannot reason about what it can't see. A repository path, a task identifier, a browser session-all of it living in a session header is real state the agent is effectively blind to.
What replaces it
Removing the protocol-level session does not mean your application has to be stateless. Servers that need to carry state across calls can do what HTTP APIs have always done: mint an explicit handle-a basket_id, a browser_id-from a tool and have the model pass it back as an ordinary argument on later calls. In practice, this pattern, the model threading an identifier from one tool call to the next, is more than just a workable substitute for session state. It's often a more powerful one.
Hidden session state is convenient for servers, but opaque to models and harder to debug. Explicit handles make state visible. The model can reference it, reason over it, chain it between tools, and include it in multi-step flows.
This is the pattern to internalize before July 28. If your tool currently relies on server-side session memory to know which file a user is editing, or which search result they're refining, refactor that into an explicit handle the tool returns and the next tool consumes. The model then holds the thread, not the transport layer.
The stateless redesign is the same trade-off the web made when it embraced stateless HTTP. Each request is slightly heavier; in exchange you get horizontal scalability and plain load balancing out of the box.
What else ships in this RC
Beyond sessions, the release candidate delivers a stateless core that scales on ordinary HTTP infrastructure, extensions including server-rendered UIs through MCP Apps and long-running work through the Tasks extension, authorization that aligns more closely with OAuth and OpenID Connect deployments, and a formal deprecation policy so the protocol can evolve without breaking what you've built.
The routing headers are worth understanding specifically.
Every Streamable HTTP request must now include Mcp-Method (e.g., tools/call) and Mcp-Name (the name of the tool or resource). This lets load balancers, API gateways, and rate limiters route on the operation without buffering and parsing the JSON-RPC body. L7 routing on a header is significantly cheaper than body inspection-your Cloudflare Workers and gateway configs will be simpler, not more complex.
Caching also gets a first-class mechanism.
Client-side caching is now standardized: tools/list, resources/list, and resources/read responses carry ttlMs and cacheScope fields. Clients finally know how long a tool list is fresh and whether it's safe to share across users. Redundant polling drops significantly.
The Tasks extension is a clean-up job with migration cost attached.
Tasks shipped as an experimental core feature in the November 2025 spec. Production use surfaced enough redesign that the right home for it is an extension rather than the specification. The Tasks extension reshapes the lifecycle around the stateless model: a server can answer tools/call with a task handle, and the client drives it with tasks/get, tasks/update, and tasks/cancel.
If you built against the experimental Tasks API, you have migration work to do.
Three primitives are deprecated-Roots, Sampling, and Logging-but the deprecation policy adopted in this release guarantees a minimum 12-month overlap between deprecation and removal of any feature. They still work. The direction is clear; the urgency is not immediate.
The ten-week window is for SDK maintainers and client implementers to validate the changes against real workloads; under the SDK tier system, Tier 1 SDKs are expected to ship support within this window. Shipping against the RC in production before July 28 is your call, not the spec's recommendation.
What to check now
The honest risk breakdown: local MCP servers running on a single process barely notice this change. Remote servers with horizontal scaling feel it immediately.
The 2026-07-28 spec is a real breaking migration for infrastructure-heavy MCP deployments. Local toy servers may barely notice. Remote multi-tenant servers will.
A useful audit to run before the final spec ships:
- Find every place your server reads or writes to session-scoped storage between tool calls. Each one needs an explicit handle or scope the client can see.
- Test your remote server behind a round-robin load balancer with no sticky routing. If requests fail, that's where your session dependency lives.
- Check your auth layer against the tightened OAuth and OIDC requirements, specifically the issuer identification guidance in SEP-2468.
- If you use Sampling to call the host LLM from server-side tools, plan the migration to direct API calls. The deprecation window is long; the direction is final.
The stateless redesign is genuinely good for agent architectures, not just for infrastructure. When state is explicit and model-visible, a teammate like Beagle can surface it, log it, and hand it across sessions without guessing what the transport layer was holding. The protocol growing up is the right framing- MCP is moving from a promising integration protocol to infrastructure developers can actually standardize on. That's worth the migration cost.