MCP Goes Stateless: What the 2026-07-28 Spec Changes
Session IDs and the initialize handshake are gone. Any request can land on any instance, which removes sticky routing and changes how you deploy an MCP server.
The short version
- The
initialize/initializedhandshake and theMcp-Session-Idheader are both removed. Every request is self-contained. - Protocol version, client identity and capabilities now travel in
_metaon every request;server/discoverfetches server capabilities when needed. - New required
Mcp-MethodandMcp-Nameheaders let gateways route without parsing the body. - The operational payoff: a plain round-robin load balancer, no sticky sessions, no shared session store.
The maintainers called the 2026-07-28 release the largest revision of the Model Context Protocol since launch, and for once that is not promotional language. Six Specification Enhancement Proposals work together to remove the session model the previous spec was built on.
If you run an MCP server behind anything other than a single process on a laptop, this changes your deployment.
What was removed
Three things leave the request path.
The initialize request and initialized notification (SEP-2575). Previously, a client opened a connection, negotiated protocol version compatibility, and exchanged capabilities once. That state then lived on the connection.
The Mcp-Session-Id header (SEP-2567), and with it the protocol-level session that pinned a client to a particular server instance.
In their place, every JSON-RPC request carries its own protocol version, client info and capabilities inside a _meta object on the envelope. A new server/discover method lets a client fetch server capabilities when it needs them up front — stateless and cacheable, rather than a mandatory step before any work can happen.
The consequence, in the release candidate’s own blunt phrasing: any MCP request can land on any server instance.
Why this matters operationally
Under the previous spec, a remote MCP server serving more than one instance needed three things: sticky sessions so a client kept reaching the same instance, a shared session store so state survived an instance restart, and gateway configuration capable of inspecting request bodies to route correctly.
All three are infrastructure you had to build, operate and debug, and none of them were doing anything for your users. Sticky sessions in particular interact badly with autoscaling, rolling deploys and instance failure — the moment an instance goes away, every client bound to it is in an undefined state.
With sessions removed at the protocol layer, an MCP server becomes an ordinary stateless HTTP service. Round-robin load balancing works. Replicas are interchangeable. A rolling deploy does not interrupt anything. Autoscaling behaves the way it does for every other service you run.
The new transport headers
Streamable HTTP now requires two headers on requests (SEP-2243):
Mcp-Method— the JSON-RPC method, such astools/call.Mcp-Name— the tool or resource name.
They mirror what is in the body, and the point is that a gateway can read them straight off the HTTP request without buffering and parsing JSON. That allows routing by operation — tools/call to one fleet, resources/read to another, a specific expensive tool to a specialised backend — along with rate limiting and observability at the edge.
Servers must reject requests where the headers and the body disagree, which closes an obvious spoofing route. Keeping them consistent is your responsibility when you emit them.
A mismatch between header and body is a routing bug waiting to happen. If you generate these headers anywhere other than directly from the message you are about to send, expect to debug it eventually.
The release also adds HTTP-style caching metadata (SEP-2549), including a ttlMs that lets servers tell clients how long they may cache a tools/list response, and W3C Trace Context propagation (SEP-414), which means MCP calls appear in the same distributed trace as the rest of your system. Both are unglamorous and both remove real friction.
The extensions framework
Extensions existed in the 2025-11-25 release without a process behind them. SEP-2133 supplies one: extensions get reverse-DNS identifiers, live in their own ext-* repositories with delegated maintainers, are negotiated through an extensions map on client and server capabilities, and version independently of the core specification. The SEP process gains an Extensions Track with a path from experimental to official.
This is the right shape for a protocol that wants a lean core and a wide surface of optional behaviour. Two extensions ship as the first officials: MCP Apps (SEP-1865) and Tasks.
Tasks is the one to understand, because it is how long-running work fits the stateless model. A server can answer a 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 support for the extension and the server decides when a call should become a task. Notably, tasks/list is removed, because without sessions there is no safe way to scope it.
Migrating a server
- Audit for session dependencies. Find everywhere your code reads or writes
Mcp-Session-Id, and everywhere behaviour branches on connection-scoped state. Those branches are now dead. - Move per-connection state out. Anything you were keeping on the connection either travels in
_meta, lives in a proper datastore keyed by something meaningful, or was not needed. - Remove the initialize handling and implement
server/discoverfor capability queries. - Read capabilities from
_metaon each request rather than from remembered connection state. - Accept and emit
Mcp-MethodandMcp-Name, validating that they agree with the body. - Migrate off HTTP+SSE to Streamable HTTP if you have not already; the older transport is proposed for deprecation.
- Then simplify the infrastructure — drop sticky routing and the shared session store, which is where the benefit actually lands.
The release ships with a written deprecation policy and a twelve-month window, and no existing feature is removed inside it. There is time to do this properly rather than urgently.
What it means if you only consume MCP
If you use MCP servers rather than writing them, the practical effects are indirect and mostly positive: remote servers become cheaper and more reliable to operate, so more of them will exist and be maintained; and trace context propagation means MCP calls stop being a blind spot in your observability.
Client libraries will handle the protocol changes. The one thing worth checking is that anything you built directly against the wire format — a proxy, a logging shim, a gateway rule — is updated, since those are the places that quietly hard-code assumptions about handshakes and session headers.
Boolean Solutions experience with MCP
We build MCP servers to connect internal systems to agent tooling, and the operational awkwardness of the session model was the most common reason a working prototype was slow to reach production. Explaining why a tool integration needed sticky sessions and a Redis instance was never a comfortable conversation with a platform team.
Removing that is the most useful thing this release does. It also reinforces the point we make about MCP generally: the protocol handles transport and discovery, and authorisation remains entirely yours — a subject we covered in Securing Agentic AI. If you are building MCP integrations and want a second opinion on the design, get in touch.
Further reading
- The 2026-07-28 MCP Specification Release Candidate — the official announcement, SEP by SEP
- MCP specification — the current text
- W3C Trace Context — the tracing standard MCP now propagates
- RFC 8707 Resource Indicators — now required in token requests under the revised authorisation model
Udit Mittal
Founder at Boolean Solutions. Twenty years of building and rescuing web, mobile and AI products for SaaS companies and startups — and writing down what actually worked.
Get in touch
