MCP’s Biggest Update: Stateless Core Eliminates Sessions, Handshakes, and Lowers Remote Deployment Barriers

The new MCP version, described by the official blog as a "stateless core," represents the most significant protocol change since its inception.

Previously, MCP required a client to send an initialize request, receive an initialized response, and maintain a session using the Mcp-Session-Id header. The update removes this handshake entirely; each request now carries protocol version, client identity, and capability information in the _meta field, allowing it to be processed by any server instance behind a simple round‑robin load balancer.

If you need to discover a server's capabilities ahead of time, you can optionally use the new server/discover RPC, though it is not required.

Operationally, the stateless design means remote MCP servers no longer need shared storage to maintain session state, dramatically lowering the barrier to horizontal scaling and making deployment as simple as launching a new instance.

The protocol’s statelessness does not force applications to be stateless; developers can generate a handle and pass it as a parameter, giving the model explicit visibility of the state.

Multi Round‑Trip Requests (MRTR) replace the previous need for a persistent bidirectional stream when the server must ask the client for input (e.g., elicitation, sampling, directory listing). The server now returns resultType: "input_required" with the question, and the client retries the original call with the answer, all without a long‑lived connection. This directly enables features such as elicitation for services like Supabase.

Header‑based routing requires Streamable HTTP requests to include Mcp-Method and Mcp-Name headers. Gateways, rate limiters, and WAFs can route and meter traffic based solely on these headers, avoiding JSON body parsing.

Cacheable list results – responses from tools/list, prompts/list, resources/list, and resources/read now contain ttlMs and cacheScope. Clients can cache these directories and avoid repeated fetches on reconnection.

Authorization hardening includes three key changes:

Authorization servers must return an iss parameter (RFC 9207); clients must verify this before exchanging tokens, closing a cross‑server misuse vulnerability.

Dynamic Client Registration (DCR) is officially deprecated in favor of Client ID Metadata Documents (CIMD); DCR remains usable but will be removed in the future.

Client credentials are now bound to the issuing authorization server, preventing reuse across servers.

Tasks become an extension . The experimental core task API has moved to the io.modelcontextprotocol/tasks extension, using polling‑based tasks/get and tasks/update. Change notifications no longer use an HTTP GET endpoint; they are unified under the subscriptions/listen stream.

Deprecation policy : The Roots, Sampling, and Logging features are marked deprecated, as is the HTTP + SSE transport. Each deprecation provides at least a twelve‑month grace period.

SDK support: Tier‑1 SDKs for TypeScript, Python, Go, and C# fully implement the new specification, while the Rust SDK is in beta.

“Statelessness is an unobtrusive fix, but it lets this protocol be deployed inside real companies. No one will tweet about it, but every ops team will feel the impact. That’s the best release.” – Evan Kirstel

“When running multiple Claude Code instances in the same codebase, any stateful component on the server quickly becomes a coordination nightmare.” – Chad Justice

If you previously hesitated because remote MCP deployment was complex, the new stateless core invites a fresh evaluation: MCP is moving from a demo to core infrastructure.

MCP announcement (https://claude.com/blog/bringing-mcp-2026-07-28-to-claude)

MCP official blog (https://blog.modelcontextprotocol.io/posts/2026-07-28/)

New specification document (https://modelcontextprotocol.io/specification/2026-07-28)