- The 2026-07-28 MCP release candidate removes the initialize/initialized handshake and Mcp-Session-Id, making the protocol stateless so any request can hit any server instance.
- Stateless MCP eliminates the need for sticky sessions, shared session stores (often Redis), and gateway body inspection, enabling simple round-robin load balancing and easier horizontal scaling.
- State doesn’t disappear; it shifts into explicit handles returned by the server and passed back by clients in later tool calls, allowing any instance to resolve needed context.
- Routing becomes simpler and faster via a required Mcp-Method header, letting gateways route by method without parsing JSON bodies.
- Caching becomes explicit with ttlMs and cacheScope, replacing stream-based invalidation and reducing long-lived connections.
The 2026-07-28 MCP release candidate makes the protocol stateless: no handshake, no session id, any request can land on any server instance.
That one change deletes the infrastructure most remote MCP servers were built around, sticky routing and a shared session store, and lets them run behind a plain load balancer.
If you run a remote MCP server, the work before July 28 is real but bounded. State moves into explicit handles, routing moves to a header, and three features you may depend on are now deprecated.
The release candidate for the next Model Context Protocol spec, dated 2026-07-28, went out ahead of the final publication on July 28. Most of the coverage leads with the headline word, stateless, and then lists the feature bullets. The feature bullets are fine. The reason stateless matters is buried under them, and it is the part that changes how you deploy.
The reason sits one layer down. The protocol used to open every connection with an initialize and initialized handshake, then hand back an Mcp-Session-Id that the client attached to every follow-up request. That session id forced everything else. Your load balancer had to route a given client back to the same server instance every time, because that instance held the session. If you ran more than one instance, you needed sticky routing or a shared session store so any instance could rehydrate the session. And your gateway often had to read the request body to figure out where to send it.
The new spec removes the handshake and removes the session id. Client metadata that used to travel during connection setup now rides along in a _meta field on each individual request. Any request carries everything the server needs to answer it, so any request can hit any instance.
What the session was costing you
The word stateless sounds abstract until you map it to the boxes in your deployment diagram.
A remote MCP server that previously needed sticky sessions, a shared session store, and deep packet inspection at the gateway can now run behind a plain round-robin load balancer. That is the whole pitch, and it is a large one. Sticky sessions are the reason horizontal scaling was awkward. One instance dies and every client pinned to it loses its session. You add an instance and existing clients never move to it. A shared session store, usually Redis, is one more thing to run, secure, and pay for, and it sits in the hot path of every request.
Drop the session and that entire apparatus becomes dead weight. Requests spread evenly across instances. An instance can go down mid-conversation and the next request just lands somewhere else. You scale by adding boxes, not by tuning affinity rules.
The tradeoff is that state you actually need does not vanish, it moves. Servers keep application state through explicit handles. The server hands the client an identifier, the client passes it back as a tool argument on later calls, and the server looks up whatever that handle points to. State is still there. It is just carried in the payload instead of implied by the connection, which is what makes any instance able to serve any request.
Routing and caching move too
Two smaller changes fall out of the same design and are worth wiring in early.
Routing now happens on a header. The spec adds a required Mcp-Method header, so a load balancer or gateway can route on method name without cracking open the JSON body. If you want fast tool calls on one pool and long-running work on another, you can split them at the edge with a header rule instead of body inspection.
Caching gets explicit. Responses can carry ttlMs and cacheScope, which replace the old streaming approach to invalidation. Your client can cache a tools/list response for as long as the server says it is good for, instead of holding an open stream to hear about changes. Fewer open connections, fewer surprises.
The extensions split, and what it signals
Two features ship as official extensions rather than core: MCP Apps and Tasks.
MCP Apps lets a server hand back an HTML UI template that renders in a sandboxed iframe and talks back over JSON-RPC. A server can now return a small interface, not just text and structured data.
Tasks is the interesting one, because it was already in the protocol. It shipped as an experimental core feature in the 2025-11-25 spec, the async pattern where a tool call returns a handle and the client drives it with tasks/get, tasks/update, and tasks/cancel. Real production use surfaced enough that it needed a redesign, and the maintainers moved it out of core into an extension rather than freeze a shaky design into the spec. That is the right call, and it tells you something about how this protocol is being run now. Extensions version independently and negotiate through capability maps, so a rough edge in Tasks no longer drags the whole spec.
Three things you may be leaning on that are now deprecated
The release adds a formal deprecation policy, features stay functional for at least twelve months after they are marked, and three land on the list in this cut.
Roots is deprecated. If you used it to tell a server which directories or resources were in scope, move that into tool parameters or resource URIs.
Sampling is deprecated. If your server asked the client to run an LLM completion on its behalf, integrate a provider API directly instead.
Logging is deprecated. Send diagnostics to stderr or emit OpenTelemetry.
None of these break on July 28. But the direction is set, and building anything new on top of them is building on a countdown.
What to actually do before the spec lands
The ten-week window between the candidate and the final spec exists so SDK maintainers and client implementers can validate against real workloads, and the Tier 1 SDKs are expected to ship support inside it. You do not have to move on day one. You do have to know where you stand.
If you run a remote server, find every place you assumed a session. Anything that stored per-client state keyed on the session id needs to become an explicit handle passed as a tool argument. Check whether your gateway does sticky routing or body inspection, because both can go. Grep your server for Roots, Sampling, and Logging and plan their replacements.
If you consume MCP servers, watch your SDK version and start caching tools/list with the server's ttlMs instead of refetching on every turn.
The stateless core is the largest revision since the protocol launched, and it is the good kind of large. It removes machinery instead of adding it. A remote MCP server stops being a stateful service that needs careful routing and becomes an ordinary HTTP endpoint you can scale the boring way. That is worth the migration, and the migration is smaller than the headline makes it sound.
If you run a remote MCP server, plan to remove session-dependent infrastructure and refactor any implicit per-connection state into explicit handles that clients pass back on subsequent calls. Update your edge routing to use the new Mcp-Method header instead of inspecting request bodies, and adopt ttlMs/cacheScope so clients can cache safely without holding open streams. As you migrate, audit anything that assumed sticky sessions or a shared session store, because those components become unnecessary—and can become failure points—once requests are truly stateless.