MCP Stateless RC shifts server design fast

The 2026 MCP release candidate removes protocol sessions and pushes servers toward plain HTTP.

The 2026-07-28 release candidate for [Model Context Protocol](https://modelcontextprotocol.io/) changes how production servers route, cache, and observe requests, with 10 weeks to adapt before finalization.

1. The protocol is now stateless

The biggest change is simple: the protocol-level session is gone. SEP-2567 removes Mcp-Session-Id, and SEP-2575 removes the initialize and initialized handshake. Clients now send version and capability data in _meta on each request, while a new server/discover method covers upfront capability lookup.

For operators, that means MCP can sit behind a normal round-robin load balancer without sticky routing or a shared session store. For developers, it means protocol state is no longer the place to keep application state. If you need a cart, browser session, or deployment handle, you pass an explicit ID as a tool argument.

• No session affinity at the protocol layer
• No initialize round-trip before every connection
• Application state stays in your app, not the transport

2. Routing now depends on headers, not body parsing

Every Streamable HTTP request must include Mcp-Method and Mcp-Name. That lets load balancers, gateways, and rate limiters route requests without buffering and inspecting the JSON-RPC body first. Servers must reject requests when the headers and body disagree, which also gives you a clean integrity check.

This is the sort of change infrastructure teams notice immediately. Header-based L7 routing is cheaper than body inspection, and it fits existing tools such as [Cloudflare](https://www.cloudflare.com/) Workers, API gateways, and standard HTTP proxies. The spec is making the transport easier to operate, not harder.

3. Three old features are on a migration path

SEP-2577 marks Roots, Sampling, and Logging as deprecated under the new feature lifecycle policy. The policy adds Active, Deprecated, and Removed stages, with at least 12 months between each stage, so these methods still work for now. But the direction is clear, and teams using them should plan a replacement path.

Roots will shift to explicit tool parameters, resource URIs, or server configuration. Logging moves to stderr for stdio transports or [OpenTelemetry](https://opentelemetry.io/) for structured observability. Sampling is the hardest one to replace because it lets server tools borrow the client’s LLM for completions. The spec maintainers want direct provider calls instead.

• Roots: replace with explicit inputs or config
• Logging: move to stderr or OpenTelemetry
• Sampling: refactor toward direct LLM API calls

4. Caching and long-running work are better defined

The RC adds standardized client-side caching for tools/list, resources/list, and resources/read responses through ttlMs and cacheScope. That gives clients a clear freshness window and tells them whether cached data can be shared across users. In practice, it should cut redundant polling.

Two extensions fill in other gaps. The Tasks extension handles long-running jobs by returning a task handle and letting clients poll with tasks/get. MCP Apps, now part of the extensions framework, lets tools return interactive HTML inside sandboxed iframes in clients such as [Claude](https://claude.ai/), [ChatGPT](https://chatgpt.com/), [VS Code](https://code.visualstudio.com/), and [Goose](https://block.github.io/goose/).

5. The migration checklist is short but urgent

The spec says you have ten weeks before the final release on July 28, so the practical work is already obvious. Remove any routing logic that depends on Mcp-Session-Id. Add the new headers to all outgoing Streamable HTTP requests. Then test behind a plain round-robin load balancer to see what breaks.

If your server uses Sampling or Roots, start the refactor now rather than waiting for the final spec. Also add ttlMs to list responses so clients can cache them properly. The point of the RC is to give SDK maintainers and implementers time to validate real workloads before the spec locks in.

• Delete session-based routing assumptions
• Add Mcp-Method and Mcp-Name
• Validate on standard load balancers
• Plan Sampling and Roots replacements

How to decide

If you run MCP infrastructure, start with the session and header changes, because those affect uptime and routing first. If you build tools on top of MCP, focus on the deprecation path for Sampling, Roots, and Logging. If you ship clients, prioritize caching and task handling, since those changes improve performance and user experience with less code churn.

In short, operators should fix transport assumptions, platform teams should update observability and caching, and product teams should watch the new extension model for app-like workflows.