Why MCP’s New Stateless Design Eliminates Session Stores and Handshakes

What Changed in MCP 2026‑07‑28

The Release Candidate for MCP (2026‑07‑28) replaces the protocol layer with a completely stateless design.

Old Workflow and Its Pain Points

Previously a client had to send an initialize request to obtain a Mcp-Session-Id. Every subsequent request had to carry that ID, binding the client to the specific server instance that created the session. Horizontal scaling required either sticky routing or a shared session store (e.g., Redis with consistent hashing and fail‑over). This added significant operational complexity.

POST /mcp HTTP/1.1
{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-11-25","capabilities":{},"clientInfo":{"name":"my-app","version":"1.0"}}}

New Stateless Request Model

In the new version a single request contains all necessary metadata. The client includes the protocol version and client info in the _meta field and routes the request by the Mcp-Method and Mcp-Name headers.

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

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

There is no handshake, no session ID, and any server instance can handle any request.

Stateless Protocol vs. Stateful Application Logic

The protocol no longer hides state in headers; applications that need cross‑request state must expose explicit handles such as basket_id or browser_id in tool responses. Models can then receive these handles as ordinary parameters, allowing richer stateful workflows without relying on hidden session state.

Operational Benefits

Header Routing : The required Mcp-Method and Mcp-Name headers (SEP‑2243) let load balancers, gateways, and rate limiters route traffic without parsing the JSON body. Mismatched headers cause the server to reject the request.

Client‑Side Caching : List and resource‑read responses now include ttlMs and cacheScope (SEP‑2549), mirroring HTTP Cache‑Control. Clients know exactly how long a tools/list response can be cached and whether it can be shared across users, removing the need for a persistent SSE connection.

Distributed Tracing : The _meta field now carries W3C Trace Context keys ( traceparent, tracestate, baggage) as defined in SEP‑414. A trace can flow from the host application through the client SDK, MCP server, and downstream services, appearing as a complete span tree in OpenTelemetry back‑ends.

Extensions Maturity

Extensions, introduced on 2025‑11‑25, now have a formal process (SEP‑2133). They are identified by reverse‑domain IDs, negotiated via the extensions map in capabilities, live in independent ext‑* repositories, and evolve separately from the core spec.

Two official extensions ship with this release:

MCP Apps (SEP‑1865) : Servers can push interactive HTML UI; hosts render it in a sandboxed iframe. Communication still uses JSON‑RPC with the same audit and user‑consent flow.

Tasks Extension : Graduated from the experimental core feature of 2025‑11‑25. The server returns a task handle from tools/call; the client drives the task via tasks/get, tasks/update, and tasks/cancel. Existing integrations with the 2025‑11‑25 experimental Tasks API must be migrated.

Authorization Hardening (Six SEPs)

Clients must verify the iss parameter in the authorization response (SEP‑2468) to prevent mix‑up attacks.

During Dynamic Client Registration, the application_type must be declared (SEP‑837) to avoid treating desktop/CLI clients as web apps.

Credentials are bound to the issuer (SEP‑2352), so resources automatically re‑register when moving between authorization servers.

These changes are critical because MCP’s deployment model involves a single client connecting to many servers, increasing the attack surface compared to typical OAuth scenarios.

Deprecated Core Features

Roots – replaced by tool parameters, resource URIs, and server configuration.

Sampling – replaced by direct integration with LLM provider APIs.

Logging – replaced by standard error streams for simple cases and OpenTelemetry for production.

All three are marked deprecated (not removed) and will remain functional for at least the next year.

Migration Timeline

The RC is locked on May 21; the final spec releases on July 28. SDK maintainers have a ten‑week window to add support. Breaking changes are present, but a deprecation policy (SEP‑2577) guarantees a minimum 12‑month period from deprecation to possible removal.

Author’s Assessment

The author judges the redesign as correct: the original MCP design assumed a local stdio connection, leading to stateful, single‑instance deployments that hindered scaling. Making the protocol stateless aligns it with ordinary HTTP infrastructure and simplifies both operations and future extensions.

Developers should discard their session stores, review OAuth implementations, and start planning migration to the new Tasks API before the July 28 deadline.