MCP is stateless: what the 2026-07-28 spec changes and what you need to do now

The Model Context Protocol people froze the release candidate for spec version 2026-07-28 on 21 May 2026, and since 28 July 2026 it is final. The TypeScript SDK v2.0.0 with support for it is out as well. This is the biggest change to the protocol since the very first launch, and if you run MCP servers yourself or are working through L4 and L6 right now, it is worth understanding this rather than waiting until every SDK has moved. Six Specification Enhancement Proposals work together to turn MCP into a stateless protocol. Sounds academic, but it has very concrete consequences for deployment, auth and your code. I will go through the ten points that actually matter.

Step 1, the core in one sentence

MCP is now stateless at the protocol level. Up to 2025-11-25 you had to establish a session before you could call a tool at all. That session bound the client to exactly the server instance that issued it. With 2026-07-28 every request is self-contained and can land on any instance.

That is the one idea everything else depends on. Once you have internalised it, the other nine points follow almost by themselves.

Step 2, handshake and session are gone

The initialize/initialized handshake was removed (SEP-2575). Protocol version, client info and capabilities, which used to be exchanged once at connection time, now travel in _meta on every single request. If a client needs the server capabilities up front, it fetches them via the new server/discover method.

The Mcp-Session-Id header and the session hanging off it are gone too (SEP-2567). Here is what the difference looks like. Before, with a session:

POST /mcp HTTP/1.1
Mcp-Session-Id: 1868a90c-3a3f-4f5b
Content-Type: application/json

{"jsonrpc":"2.0","id":2,"method":"tools/call",
"params":{"name":"search","arguments":{"q":"otters"}}}

Now, a single self-describing request:

POST /mcp HTTP/1.1
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: search
Content-Type: application/json

{"jsonrpc":"2.0","id":1,"method":"tools/call",
"params":{"name":"search","arguments":{"q":"otters"},
"_meta":{"io.modelcontextprotocol/clientInfo":{"name":"my-app","version":"1.0"}}}}

Step 3, what that means for your deployment

This is where it gets practical. A remote MCP server used to need sticky sessions, a shared session store and in places deep packet inspection at the gateway. All of that falls away. The same server now runs behind a perfectly ordinary round-robin load balancer.

If you have been scaling your server horizontally and the sticky sessions gave you a stomach ache, that is the best news in the whole spec. You throw infrastructure out instead of adding more.

Step 4, keeping state without a session

Stateless does not mean your application may no longer have state. Servers that need state across calls now do it the way HTTP APIs have always done it. You return an explicit handle from a tool, for example a basket_id or browser_id, and the model passes it back in on later calls as a perfectly normal argument.

That is more than just a replacement for session state. The model can combine these handles across several tools and pass them between steps. The state is visible to the model instead of hidden in transport metadata. In practice that is often the cleaner solution.

Step 5, new routing headers

The Streamable HTTP transport now requires the headers Mcp-Method and Mcp-Name (SEP-2243). That lets load balancers, gateways and rate limiters route on the operation without reading the body. Important for you if you build your own infrastructure. The server rejects requests where header and body contradict each other. So set the headers correctly, otherwise you collect errors.

Step 6, lists become cacheable

List and resource-read results now carry ttlMs and cacheScope (SEP-2549), modelled on HTTP Cache-Control. Your client thereby knows exactly how long a tools/list response stays fresh and whether it may share it across several users. A permanently open SSE stream is no longer the only way to learn that a list has changed.

On top of that comes W3C Trace Context in _meta (SEP-414). The key names traceparent, tracestate and baggage are now fixed in the spec, so a trace from the host app through the client, the server and everything behind it shows up as a single span tree in an OpenTelemetry backend.

Step 7, extensions become first-class

Extensions existed in 2025-11-25 already, but without a formal process. SEP-2133 changes that. Extensions now have reverse-DNS IDs, are negotiated via an extensions map in the capabilities, live in their own ext-* repositories and version independently of the spec.

Two official extensions come along right away. MCP Apps (SEP-1865) lets servers deliver interactive HTML interfaces that the host renders in a sandboxed iframe. And Tasks, which was still an experimental core feature in 2025-11-25, becomes an extension. If you built against the old experimental Tasks API, you have to migrate. tasks/list is out, because it cannot be scoped safely without sessions. Instead you drive a task with tasks/get, tasks/update and tasks/cancel.

Step 8, auth gets stricter

Six SEPs harden authorization so it sits closer to real OAuth 2.0 and OpenID Connect deployments. Two of them you should know.

Clients now have to validate the iss parameter on authorization responses, per RFC 9207 (SEP-2468). That is a cheap safeguard against a class of mix-up attacks that is especially common in the MCP pattern with one client and many servers. In a future version clients will reject responses without iss, so start shipping it now. Clients also declare their application_type during dynamic client registration (SEP-837). That prevents the common case where an authorization server wrongly classifies a desktop or CLI client as "web" and rejects its localhost redirect URI.

Step 9, deprecations and an error code that changes

Three core features are deprecated under the new lifecycle policy (SEP-2577). Roots, sampling and logging. Those are pure annotation deprecations, they keep working, for at least another year. The recommended successors are tool parameters and resource URIs instead of roots, direct integration with the LLM provider APIs instead of sampling, and stderr or OpenTelemetry instead of logging.

One detail that can bite you if you are not paying attention. The error code for a missing resource moves from MCP's own -32002 to the JSON-RPC standard -32602 Invalid Params (SEP-2164). If your client matches on the literal value -32002, adjust it. And inputSchema and outputSchema are now full JSON Schema 2020-12 (SEP-2106), including oneOf, anyOf, $ref and $defs. External $ref URIs, however, you must not resolve automatically.

Step 10, what you should do now, concretely

The window between RC and final is over, the spec applies. If you run a server, this is no longer preparation but migration: get the spec and the changelog against 2025-11-25 and test your server against the final version. Above all the three places that are genuine breaking changes. The missing handshake, the removed session header and the changed error code. The TypeScript SDK has caught up with v2.0.0, for the other tier-1 SDKs it is worth checking their release notes.

If you are only just starting with MCP, this is no reason to panic. The basic concepts from L4, server, client and tools, stay exactly the same. What changes sits one level down in the transport. Learn the model first, then the transport details.

What next

If the mental model is not solid yet, go through What is MCP first. If you are planning your own server, the entry point is Planning an MCP server. For the auth part, which this spec tightens, the playbook MCP server auth with OAuth 2.1 is the next step. And when you are done and want to publish, Publishing an MCP server helps.

Source

• Official announcement with all SEP numbers: https://blog.modelcontextprotocol.io/posts/2026-07-28-release-candidate/
• Spec and changelog against 2025-11-25: https://modelcontextprotocol.io