MCP went stateless: your session-based servers are about to break
MCP's 2026-07-28 spec drops the initialize handshake and session header, going stateless so serverless deploys finally work — but stateful servers will break.
The 2026-07-28 MCP spec kills the `initialize` handshake and the `Mcp-Session-Id` header. If your server stashed state between calls — connection setup, per-session caches, anything keyed off that session ID — it breaks. The upside is real: with a stateless request/response core, any server instance can answer any request, so serverless and edge deploys finally work without sticky sessions or a shared session store.
The short version: this is the largest revision since MCP launched, and it's worth migrating to. But don't expect a no-op upgrade if you built anything stateful.
What actually breaks?
The handshake going away is the big one. Old MCP servers assumed a lifecycle: client calls `initialize`, server allocates a session, hands back an `Mcp-Session-Id`, and every subsequent request carried that header. Plenty of servers hung real state off that — open DB handles, auth context, an in-memory tool registry per session.
Under the new model none of that survives between requests. Each request has to carry everything it needs, or your server has to rehydrate from a shared backend on every call. If you were running a single long-lived process, you never noticed. The moment you scale to multiple instances behind a load balancer, requests fan out and the session that lived in instance A's memory isn't on instance B.
That's exactly why serverless didn't work before. A cold Lambda or a fresh Cloudflare Worker had no idea about a session created on some other invocation. Killing the session header is what makes horizontal scaling actually correct instead of accidentally-working-until-it-isn't.
Does going stateless mean losing multi-step flows?
No — that's what Multi Round-Trip Requests are for. Instead of implicit state carried by a session, a multi-round-trip request makes the continuation explicit in the payload. The server tells the client what it needs next, the client sends it back, and any instance can pick up the thread because the context is in the message, not in a process's memory.
There's also header routing and cacheable lists in the 2026-07-28 spec release, which is the sort of thing that reads boring until you're paying for it. Cacheable tool/resource lists mean an edge cache can serve your capability manifest without hitting origin — a genuine cost and latency win at the ~400M monthly SDK download scale MCP is now operating at.
The OAuth and extensions bits
OAuth/OIDC got hardened, which matters more once you're stateless — you can't lean on a session to remember who someone is, so per-request auth has to be tight. The formal extensions framework (Apps, Tasks) is the part I'm watching. A standard extension mechanism is how you avoid every vendor bolting on incompatible custom fields, which is the usual way a young protocol rots.
AWS Bedrock AgentCore, Cloudflare, and Anthropic all shipped support from day zero, so this isn't a paper spec you'll wait a year to use.
Should you migrate?
Yes, but treat it as a real port, not a version bump. Audit every place your server reads `Mcp-Session-Id` or assumes `initialize` ran. Move per-session state either into the request payload via multi-round-trip or into a shared store you hit on each call. If you're already stateless — most trivial tool servers are — you get edge deployment nearly for free.
Verdict: this is the change I'd have asked for. The old session model was the single thing keeping MCP servers off serverless, and dropping it is the right call even though it'll cost some teams a migration weekend.