MCP 2026-07-28 Goes Stateless: The Gateway Routing Changes Every Operator Must Make Now

When a protocol change removes an entire class of gateway infrastructure requirement, engineering teams need to audit their stack before the final spec lands. The MCP 2026-07-28 release candidate — available now, with the final specification shipping July 28 — does exactly that.

This is the largest revision to the Model Context Protocol since its launch. For operators who run AI gateways, load balancers, or MCP proxy layers, the change is not cosmetic. The stateless core removes the session pinning that made horizontal MCP deployments expensive, and the new Mcp-Method header makes MCP traffic routable at the header layer for the first time.

What happened

The MCP specification team published the release candidate for the 2026-07-28 revision on July 18. Six Specification Enhancement Proposals (SEPs) work together to make the protocol stateless at the transport layer:

• SEP-2575 removes the initialize/initialized handshake. Protocol version, client info, and client capabilities now travel in _meta on every request.
• SEP-2567 removes the Mcp-Session-Id header and the protocol-level session concept entirely.
• SEP-2243 requires Mcp-Method and Mcp-Name headers on every Streamable HTTP request.
• SEP-2549 adds ttlMs and cacheScope to list and resource-read results, modeled on HTTP Cache-Control.
• SEP-2322 replaces the open SSE stream for server-initiated prompts with a InputRequiredResult polling pattern.
• SEP-414 standardizes W3C Trace Context propagation keys in _meta for distributed tracing.

The final specification ships July 28, 2026. The release contains breaking changes for anything built against the 2025-11-25 spec.

Why it matters for AI engineering teams

Before this revision, deploying a horizontally scaled MCP server required:

1. Sticky session routing — every request carrying an Mcp-Session-Id had to land on the instance that issued it.
2. A shared session store — Redis, DynamoDB, or an equivalent store so the session state was recoverable if an instance restarted.
3. Body inspection at the gateway — because the operation type lived inside the JSON-RPC body, not in HTTP headers.

After 2026-07-28, none of these are required at the protocol layer. Any request can land on any server instance because all context it needs is self-contained in the payload and _meta. A plain round-robin load balancer handles what previously needed session-aware routing.

For teams running large agentic workloads — where the agent calls dozens of MCP tools across a session — this reduces both the infrastructure cost and the failure surface. There is no longer a session-affinity SLA to maintain.

The router/operator angle

The new Mcp-Method and Mcp-Name headers change what AI gateways and API routers can do with MCP traffic.

Header-level routing. Previously, to route MCP traffic by operation (e.g., send tools/call to a lower-latency cluster, send resources/read to a cached tier), a gateway had to deserialize the JSON-RPC body on every request. The Mcp-Method and Mcp-Name headers expose the operation and tool name at the HTTP layer, enabling rate-limiting, quota enforcement, and routing policy decisions without body inspection. Servers that receive requests where the headers disagree with the body are required to reject them, so the headers are authoritative.

Caching policy via ttlMs. The ttlMs and cacheScope fields on list results behave like Cache-Control. A gateway can now cache tools/list responses for the advertised TTL and serve them to multiple clients without hitting the MCP server on every connection. For large agent fleets that initialize many sessions, this meaningfully reduces upstream load.

Distributed tracing across the full agent path. The W3C Trace Context (traceparent, tracestate, baggage) keys are now fixed in the spec. A trace that originates in an AI gateway, passes through a Claude Code session, and calls into an MCP server can now produce a single coherent span tree in any OpenTelemetry-compatible backend — without per-SDK or per-framework coordination.

Tasks migration. The experimental Tasks API from the 2025-11-25 spec has a new lifecycle in 2026-07-28. The tasks/list method is removed. Task creation is server-directed: the server responds to a tools/call with a task handle, and the client polls with tasks/get, tasks/update, and tasks/cancel. Teams that built queuing or async-dispatch logic against the old Tasks API must migrate before July 28.

Breaking changes checklist for operators:

• Remove sticky session routing rules tied to Mcp-Session-Id
• Remove or repurpose body-inspection rules that extract operation type from JSON-RPC body
• Add routing rules on Mcp-Method and Mcp-Name headers
• Configure gateway-side caching for tools/list responses using ttlMs
• Migrate Tasks implementations to the new server-directed lifecycle
• Verify OTel trace propagation keys match the spec-fixed names
• Pin SDK versions to those that implement 2026-07-28 before upgrading MCP servers

What TheRouter users should watch or try

If your stack routes MCP traffic today — through Claude Code, any agent platform, or a custom proxy — the primary action is auditing session-affinity rules in your load balancer or gateway config. These will either become unnecessary or need to be replaced with Mcp-Method-based routing rules.

The TheRouter docs cover gateway configuration for AI provider routing, and the same request-routing primitives that handle model fallback also apply to MCP traffic tiers. Watch the July 28 final release for production-readiness guidance, as the RC contains breaking changes that SDK maintainers will need to implement.

For teams running the experimental Tasks API against any provider: treat July 28 as a hard migration deadline. The server-directed task lifecycle removes tasks/list entirely, which will break any client that polls for all active tasks.