By On May 21, the Model Context Protocol team locked its release candidate for the 2026-07-28 specification — the largest revision to MCP since its November 2024 launch. The headline change: sessions are gone. If you run a remote MCP server in production with sticky routing, a Redis session store, or long-lived SSE streams for list-change detection, you have until July 28 to adapt. If you’re on local STDIO, you’re mostly fine. Here’s what actually changes — and what you can stop maintaining.
MCP Is Now Stateless
The Mcp-Session-Id header is eliminated. The protocol-level session concept no longer exists. This is the biggest structural change in the RC, and it lands with immediate consequences for anyone running remote MCP servers at scale.
The old model forced production teams into awkward infrastructure: sticky session rules in load balancers, Redis stores to share session state across instances, and deep packet inspection at the gateway layer just to route requests to the right replica. None of that was fun, and none of it is necessary once the protocol goes stateless.
With sessions gone, any MCP request can land on any server instance. A plain round-robin load balancer is now all you need. Your gateway routes on headers, not request body contents. Your session store goes away entirely. The official RC announcement frames it plainly: MCP should “run statelessly on commodity HTTP infrastructure” — and with this revision, it finally does.
Three More Changes That Will Break Things
New Required Headers: Mcp-Method and Mcp-Name
Every Streamable HTTP request must now include two headers: Mcp-Method (the operation, e.g. tools/call) and Mcp-Name (the tool or resource name). This gives API gateways and rate-limiters something to work with at the header level — no body inspection required to distinguish a tools/list from a resources/read. Clients that skip these headers will be rejected by spec-compliant servers. Update your client libraries early.
Cache TTL on List Results
Responses from tools/list, resources/list, and prompts/list now carry two new fields: ttlMs (how long the client can cache the result) and cacheScope (whether it’s user-scoped or global). This is modeled directly on HTTP Cache-Control. The practical effect: you no longer need to keep a persistent SSE connection open just to detect when a tool list changes. Clients can poll on TTL guidance and let the connection close. Simpler clients, lower connection overhead, more explicit contracts between servers and callers.
Tasks API Moves to an Extension
The Tasks feature shipped experimentally in the November 2025 spec. After real production usage, the redesign requirements were significant enough that Tasks doesn’t belong in the core spec — it’s moving to a formal extension with its own repository and versioning cadence. The new task lifecycle works differently: a server answers a tools/call with a task handle, and the client drives execution through tasks/get, tasks/update, and tasks/cancel. If you shipped anything against the 2025-11-25 experimental Tasks API, migration is required. This is likely the change that bites the most production deployments.
Who Actually Needs to Act
The impact splits cleanly by deployment model:
- Local STDIO users — Claude Code, Cursor, most Kiro and Codex CLI workflows — are largely unaffected. Sessions were always a remote transport concern. Your setup doesn’t change.
- Remote MCP server operators — anyone running a public or enterprise MCP server reachable over HTTP — needs to audit their session infrastructure and start planning the migration now. The RC is locked; the final spec ships July 28.
- SDK maintainers — Tier 1 SDKs (the official Anthropic Python and TypeScript libraries) are expected to ship RC support within the 10-week window. Third-party SDK authors should start reading the specification roadmap now.
What to Do This Week
If you’re running a production remote MCP server, the practical checklist is short:
- Read the RC. The release candidate post covers every change with rationale.
- Audit whether you’re relying on session state, sticky routing, or the experimental Tasks API. Those are your migration targets.
- Confirm your client sends or your server expects the new
Mcp-Method/Mcp-Nameheaders — add them now if not. - Plan your deployment move: add Streamable HTTP transport support, keep SSE temporarily for backward compatibility, retire it after clients migrate.
One more thing worth noting: the RC formalizes a 12-month deprecation window policy. Features deprecated in this release can’t be removed before July 2027 at the earliest. That’s a meaningful commitment for teams building on MCP at scale. The New Stack’s coverage of MCP’s production growing pains captures exactly why this policy matters: production teams need predictability, not just features. The broader MCP ecosystem — now over 10,000 public servers spanning Anthropic, AWS, Microsoft, GitHub, and Stripe — needed this stability anchor. The 2026 MCP roadmap laid out this direction in January; the RC delivers on it.
The Bottom Line
The 2026-07-28 RC isn’t a cosmetic update. MCP is dropping its training wheels — stateless HTTP, header-based routing, formal extensions, and deprecation windows are what enterprise-grade protocols look like. The migration work is real, especially for anyone who built on the experimental Tasks API. But the end state is a protocol that runs on the same infrastructure as everything else in your stack, without special-casing. That’s worth a few weeks of plumbing changes.
