MCP Ships Its Biggest Spec Revision Yet: Goodbye Session State

Source: Model Context Protocol Blog — 2026-07-28

Summary

The Model Context Protocol project shipped its largest specification revision since authorization was added, and the headline change is architectural: MCP drops the initialize/initialized handshake and per-connection session state entirely, moving to a stateless core where every request self-describes its protocol version and capabilities via _meta. Alongside that, the spec adds "Multi Round-Trip Requests" to replace server-push for mid-call user input, new Mcp-Method/Mcp-Name headers for gateway-level routing, cacheable list results via ttlMs/cacheScope, a formal extensions framework (moving Tasks out of core), and RFC 9207-based auth hardening. GitHub's MCP server had already adopted the change ahead of the formal release, and coverage from The Register and TechCrunch flagged the same shift as a big deal for anyone running MCP behind load balancers or gateways.

Key Takeaways

• MCP moves from a stateful, session-based handshake to a stateless core: each request carries its own protocol version and capability info instead of relying on a prior initialize exchange tied to a persistent connection.
• Removing session state means MCP servers no longer need sticky sessions or deep packet inspection at gateways/load balancers — any request can be routed to any backend instance, which is a real operational simplification for anyone running MCP at scale.
• New Mcp-Method/Mcp-Name headers let infrastructure route and cache requests without parsing the message body, and ttlMs/cacheScope let list results (tools, resources, prompts) be cached instead of re-fetched every time.
• "Multi Round-Trip Requests" replace the old server-push model for cases where a tool call needs mid-flight user input, and a new formal extensions framework moves less-core features (like Tasks) out of the base spec so implementations can adopt them independently.

Reel Script

Hook (~18s): If you've built anything on MCP, the protocol you're using just changed its core architecture — it dropped session state entirely, and that's not a small version bump, it's the biggest rewrite since MCP got authorization.

Core Concept (~85s): The old MCP handshake worked like a phone call: your client "dials in" with an initialize message, the server picks up and remembers who you are for the rest of that connection — that's session state. The problem is sessions are sticky: if you're running MCP behind a load balancer, every request from that client has to keep hitting the same server instance, because that's the only one that remembers the handshake. That's exactly the same headache stateful web servers had fifteen years ago, before everyone moved to stateless REST APIs where every request carries its own credentials and context. MCP just made that same move. In the new spec, every single request is self-describing — it carries its own protocol version and capability info in a _meta field — so there's no shared memory to keep in sync, and any server instance behind a gateway can handle any request.

Hands-On (~120s): Picture the before-and-after as an architecture diagram. Before: client sends initialize, server allocates session state and replies initialized, then every subsequent call implicitly depends on that stored state — which means your gateway needs sticky routing or deep packet inspection just to keep requests going to the right backend. After: client sends a request that's fully self-contained, tagged with new Mcp-Method and Mcp-Name headers right at the transport layer — so a plain reverse proxy can route and even cache the request just by reading headers, no body parsing required. On top of that, list-type responses — your available tools, resources, prompts — can now carry a ttlMs and cacheScope, so a gateway can serve a cached copy instead of re-asking the server every time. And for the one thing sessions were genuinely useful for — a tool call that needs to pause and ask the user something mid-flight — they added a dedicated mechanism called Multi Round-Trip Requests, instead of relying on server-push through a long-lived connection.

Takeaway (~25s): This is MCP admitting it under-designed for infrastructure the first time around, and fixing it properly instead of patching around it. If you're running or building an MCP gateway, this a genuine "go read the migration guide" moment — the stateless core changes how you scale and cache, not just how you code against it.

Discussion