MCP Goes Stateless: What the 2026-07-28 Spec Breaks and How to Fix It

The Model Context Protocol just shipped its biggest spec change since launch — and if you’re running an MCP server, there’s a non-trivial chance something you built is now broken. The 2026-07-28 specification removes the stateful session model entirely. The initialize handshake is gone. Mcp-Session-Id is gone. Every request must now be fully self-contained. Servers that stored per-connection state behind a session ID need to be redesigned, and the migration window is 4-6 weeks before clients start enforcing the new spec.

What Changed

Until now, every MCP connection followed a fixed ritual: client connects, sends initialize, receives back an initialized response containing an Mcp-Session-Id header, then includes that header on every subsequent request. The session ID was the glue that tied requests together and let servers maintain per-client state.

The 2026-07-28 spec ends all of that. Two SEPs do the work: SEP-2575 removes the initialize/initialized handshake, and SEP-2567 removes the session header. In their place, every request now carries its own context — protocol version, client info, and client capabilities travel in a _meta field on each request. A new server/discover method handles capability negotiation for clients that need it upfront.

What Actually Breaks

The compatibility story is straightforward but worth spelling out: a legacy client cannot talk to a modern-only server. A modern client cannot connect to a legacy-only server. If you’re running a server that expects initialize as the first message, it will fail against 2026-07-28 clients. If you’re storing user context, conversation history, or tool state inside a server-side session store keyed by Mcp-Session-Id, that state has nowhere to go.

The community reaction was predictably divided. One camp: “In retrospect, stateful MCP was clearly wrong.” The other: “This just makes it a REST API.” The REST comparison is half-right — stateless request/response over HTTP is obviously similar. But MCP still carries tool schemas, type discovery, and agent-native semantics that REST doesn’t have. The real story is simpler: stateful protocols are hard to scale, and MCP was paying that tax unnecessarily.

How to Migrate

All four Tier 1 SDKs support 2026-07-28 as of publication day. Here’s the TypeScript path:

// Before — 2025-era stateful connection
await server.connect(new StdioServerTransport());

// After — SDK v2 stateless handler
import { createMcpHandler, McpServer } from '@modelcontextprotocol/server';

const handler = createMcpHandler(() => {
  const server = new McpServer({ name: 'my-server', version: '1.0.0' });
  // Register tools, resources, and prompts here
  return server;
});
// Pass { legacy: 'reject' } to refuse 2025-era client connections

The full migration checklist, per the Agentic AI Foundation’s migration guide:

• Update your SDK — TypeScript to @modelcontextprotocol/server@2.x, Python to mcp>=2.0
• Delete your initialize handler
• Search and remove every Mcp-Session-Id read and write in your codebase
• Move server-side session state to the application layer: a database, Redis, or request parameters
• Test against both legacy and modern clients during the transition window

Why This Is Actually Good

Set aside the migration pain for a moment. The upside is real. Once your server is stateless, any instance can handle any request. No sticky sessions. No shared session stores. Serverless and edge deployments — Cloudflare Workers, AWS Lambda, Google Cloud Run — work without custom infrastructure workarounds. Cloudflare has already published MCP v2 support natively on Workers. AWS AgentCore and Google Vertex Agent Engine are already running 2026-07-28.

Caching also becomes possible in a way it never was before. The new spec lets tools/list and resources/list return TTL headers, so clients can cache tool catalogs across sessions instead of re-fetching them on every connection. For agents that start frequently, this is a meaningful latency improvement.

What Else Is New

The stateless core gets most of the attention, but the 2026-07-28 spec adds more:

• Multi Round-Trip Requests (MRTR): Servers can now return input_required, letting the client collect missing information from the user and retry. Cleaner than maintaining an open bidirectional stream for elicitation flows.
• Header-based routing: New required Mcp-Method and Mcp-Name HTTP headers let gateways route and throttle agent traffic without parsing the request body. Route tools/call to a GPU pool and resources/list to a CDN edge node.
• Auth hardening: RFC 9207 issuer verification closes the confused-deputy delegation attack. Clients now explicitly specify which MCP server a token is intended for — critical when a single agent hits multiple MCP servers.
• Tasks extension: AWS contributed a formal tasks extension for long-running, durable agent workflows — the first entry in the new official extensions framework.

The Bigger Picture

The detail that doesn’t get enough attention: the 2026-07-28 spec ships with a 12-month deprecation policy for future breaking changes. No more surprises. The MCP team’s commitment is that anything removed in the next revision will be announced a year in advance. After a session model removed with short notice, that policy matters more than it sounds.

MCP is becoming infrastructure. It now scales on ordinary HTTP, fits CDN caching models, routes on headers like any other modern API, and has a formal extensions framework for capabilities that need to evolve independently. The session model was the last thing keeping it from working like the rest of the web. Now it does — and the 4-6 week migration window is the price of admission.