Migrate Your MCP Server Before the Stateless Spec Ships

The MCP 2026-07-28 release candidate, locked May 21st, removes the Mcp-Session-Id header entirely. If you run a remote MCP server behind a load balancer - or plan to - that change touches your deployment model before the spec goes final on July 28, 2026. This is not a version bump you can skip and catch up with later.

The release candidate delivers a stateless protocol core, the Extensions framework, Tasks, MCP Apps, authorization hardening, and a formal deprecation policy. The maintainer framing is blunt: "The protocol is now stateless: no handshake, no session id, any request can hit any server instance." That sentence has large consequences for anything you have deployed today.

What the stateless core actually changes

The biggest technical change is that MCP is becoming stateless at the protocol layer. 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.

Most MCP server failures in production stem from assumptions about session state that the protocol never guaranteed. The 2026-07-28 specification release candidate eliminates this entire class of problems by making the protocol stateless at the core.

The mechanism is practical. Every request is now self-contained - protocol version, client info, and capabilities travel in _meta on every request - meaning any server instance can handle any request. A production MCP server that previously needed sticky sessions and a shared session store can now run behind a plain round-robin load balancer.

New Mcp-Method and Mcp-Name headers let load balancers and gateways route on the operation without body inspection. That is a meaningful operational win: your gateway can rate-limit the tools/call endpoint without opening every JSON-RPC envelope, the same way it already handles any ordinary HTTP API.

The Tasks extension and why it left the core spec

Tasks shipped as an experimental core feature in 2025-11-25. Production use surfaced enough redesign that the right home for it is an extension rather than the specification.

The new lifecycle is built around stateless operation from the ground up. 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. Task creation is server-directed: the client advertises the extension and the server decides when a call should run as a task.

This works naturally with the stateless core because task state lives in a backing store, not in server memory. Any server instance can handle status queries or cancellation requests as long as they share access to the task store. For teams whose agents run operations that last longer than a request timeout - a code review, a document parse, a multi-step search - this is the first spec-endorsed way to model that cleanly.

If you shipped against the 2025-11-25 experimental Tasks API, you have a migration ahead. Anyone who shipped against the 2025-11-25 experimental Tasks API will need to migrate to the new lifecycle. It is not enormous work, but it is not zero work either.

What is deprecated and what that actually means

Three features enter deprecation in the RC: Roots, Sampling, and Logging. This is worth reading carefully before anyone starts ripping out code.

Three features enter deprecation: Roots (replaced by tool parameters or config), Sampling (call the LLM provider API directly), and Logging (use stderr or OpenTelemetry). A formal deprecation policy guarantees a minimum twelve-month window between deprecation and removal, so none of these break on July 28.

All three methods and their capability flags continue to work in this release and in every spec version published within twelve months of the final July 28 spec. You have at least until mid-2027 before they stop working. The signal is directional, not a cliff.

The replacements are sensible: pass workspace paths as tool parameters or resource URIs instead of Roots; call the LLM API directly from your server code instead of Sampling; write to stderr or ship to OpenTelemetry instead of Logging. None of those migrations are architectural - they are plumbing changes.

Also shipping in the RC: list and resource read results now carry ttlMs and cacheScope fields modeled on HTTP Cache-Control, so clients know exactly how long a tools/list response is fresh and whether it is safe to share across users. That alone should reduce redundant list calls in any agent that queries tools repeatedly.

The practical migration checklist

The 2026-07-28 specification eliminates complexity for teams running MCP servers in distributed environments. Migrate if your deployment uses multiple server instances, requires horizontal scaling, or struggles with session state management. The stateless core provides immediate value in these scenarios. Hold off if your server runs as a single process for a single client. The stateful model works fine in that case and migration overhead exceeds the benefits.

For everyone else, the five things to do before July 28:

• Audit your transport code for initialize handshake and Mcp-Session-Id usage - these are the breaking changes that will surface first in load-balanced environments
• Add Mcp-Method and Mcp-Name headers to your Streamable HTTP requests so gateways can route without body inspection
• If you used the 2025-11-25 experimental Tasks API, migrate to the new tasks/get / tasks/update / tasks/cancel lifecycle
• Add ttlMs to list and resource responses so clients cache correctly
• Leave Roots, Sampling, and Logging alone for now; follow your SDK's migration timeline when it ships guidance

For the TypeScript SDK - 66 million npm downloads, 27,000+ dependent packages - that migration will be well-documented and gradual. The ten-week window exists precisely so the SDK does the heavy lifting, not every individual server maintainer.

One broader point worth holding onto. The first part of 2026 is when MCP stopped being a thing that individual teams adopted as a bet and became the thing that teams assumed when scoping new agentic work. The 2026-07-28 spec is the protocol catching up with that reality - making MCP deployable on infrastructure that does not know or care what MCP is, which is exactly how mature protocols should behave.

A teammate like Beagle, sitting inside Slack and watching your MCP-connected integrations get invoked through agent workflows, benefits directly from a stateless protocol: no ghost sessions, no routing surprises when a server restarts mid-conversation. The plumbing getting boring is the good news.

The final spec publishes July 28. If you have production MCP servers, the time to read the RC is now, not after it ships.