MCP Goes Stateless: What the 2026-07-28 Spec Changes for Developers

The Model Context Protocol 2026-07-28 specification drops session state for a stateless HTTP core. This unlocks horizontal scaling, simpler deployments, and new patterns like Multi Round-Trip Requests.

The Model Context Protocol has been the connective tissue between LLM applications and external tools since late 2024. But the original spec carried a structural constraint: it was stateful at the protocol layer. Servers had to maintain session state, track Mcp-Session-Id headers, and handle initialization handshakes. That worked for local development and small deployments. It broke down at scale.

The 2026-07-28 specification, published in late July, is the largest revision since launch. Its headline change is exactly what the title says: MCP is now stateless at the protocol layer. The session abstraction is gone. The Mcp-Session-Id header is gone. The initialize handshake is simplified. What replaces it is ordinary HTTP request/response semantics that any load balancer, CDN, or serverless platform already understands.

What Changed Concretely

The spec revision touches five areas that matter to developers building MCP servers or clients:

  1. Stateless transport core. No protocol-level sessions. Each request carries all context it needs. A request can be answered by any server instance behind a standard HTTP load balancer.
  2. Multi Round-Trip Requests (SEP-2322). The pattern that replaces server-initiated requests. Servers return handles (opaque identifiers) from tool calls. Clients thread those handles back as arguments on later calls. State moves from the transport layer into the model's context as ordinary arguments, where the model can see and reason about it.
  3. Header-based routing. New Mcp-Method and Mcp-Name headers let gateways route on header values without inspecting request bodies.
  4. Cacheable list results. tools/list, resources/list, and prompts/list can now return ETag and Cache-Control headers. Clients can conditional-GET. This matters when you have hundreds of tools and want to avoid re-fetching on every session.
  5. Authorization hardening. A formal WWW-Authenticate challenge flow replaces the ad-hoc approaches servers improvised. The extensions framework is also formalized so vendors can extend the protocol without forking it.

The full specification is on the MCP site. The release announcement walks through the rationale. Microsoft's Azure team published a detailed breakdown of what this means for App Service scaling. Google's developer blog covers the same ground for Cloud Run and GKE.

Why This Matters for Server Authors

If you run an MCP server today — whether it's a database connector, a filesystem bridge, or an internal API wrapper — the migration path is straightforward but not zero-effort.

Drop session storage

Your server no longer needs to map Mcp-Session-Id to in-memory state. That means no Redis for session affinity, no sticky sessions in your load balancer, no cleanup logic for abandoned sessions. A stateless server is a simpler server.

Adopt handle-based patterns

Where you previously stored a database cursor, file handle, or authenticated connection in session state, you now return a handle from the tool call. The client passes it back. Example flow:

// Client calls tool
{
  "method": "tools/call",
  "params": {
    "name": "db_query",
    "arguments": { "sql": "SELECT * FROM users WHERE active = true" }
  }
}

// Server returns a handle instead of the full result set
{
  "result": {
    "content": [{ "type": "text", "text": "Query queued. Handle: qry_abc123" }],
    "structuredContent": { "handle": "qry_abc123", "rowCount": 1247 }
  }
}

// Client fetches pages using the handle
{
  "method": "tools/call",
  "params": {
    "name": "db_fetch",
    "arguments": { "handle": "qry_abc123", "offset": 0, "limit": 100 }
  }
}

This pattern — sometimes called "server-driven pagination via handles" — is now the idiomatic way to stream large results without protocol-level sessions.

Update your SDK

Tier 1 SDKs (TypeScript, Python) have 2.0 releases that implement the 2026-07-28 revision. The TypeScript SDK v2.0 runs on the new spec. The Python SDK has a 2.0 beta. If you pinned to 1.x, plan the upgrade. The breaking changes are mostly around transport initialization and session handling — your tool definitions and business logic stay the same.

What This Means for Client Authors

Claude Code, Cursor, and other MCP clients gain two practical benefits:

Claude's announcement notes that MCP tunnels (research preview) also benefit: they connect Claude to MCP servers inside private networks without inbound firewall rules, and the stateless core makes the tunnel infrastructure simpler to operate.

Operational Wins

The stateless shift is not just architectural hygiene. It changes what's possible in production:

What Hasn't Changed

The tool, resource, and prompt primitives are stable. The JSON-RPC 2.0 envelope is stable. The capability negotiation model is stable. If you built an MCP server against the 2025 spec, your tool definitions and handler logic are largely portable. The work is in the transport layer and any session-dependent patterns you adopted.

Migration Checklist

  1. Audit your server for Mcp-Session-Id dependencies. Remove session storage.
  2. Identify stateful patterns (cursors, auth tokens, partial results) and convert to handle-based returns.
  3. Upgrade to SDK 2.0 (TypeScript) or 2.0 beta (Python).
  4. Test behind a load balancer with multiple replicas. Verify requests distribute correctly.
  5. Add ETag and Cache-Control to list endpoints.
  6. Implement WWW-Authenticate challenge flow if you gate access.

The Bigger Picture

MCP's stateless turn reflects a broader pattern in AI infrastructure: the protocols that win are the ones that compose with existing HTTP infrastructure rather than demanding their own runtime. The 2025 spec asked you to run a stateful WebSocket server. The 2026 spec asks you to run an HTTP handler. That difference compounds across every deployment decision downstream.

For developers, the takeaway is practical: MCP servers are now boring HTTP services. That is a compliment. Boring services scale, debug, and operate with the tooling you already have.


If this was useful, you can support my open-source work on Ko-fi or check out my services.