Run Your MCP Servers Behind a Load Balancer Now

Before July 28, every remote MCP server had a quiet infrastructure problem: it needed sticky sessions. A load balancer that round-robined requests across instances would silently break things, because an MCP session was pinned to whichever server instance handled the initial handshake

• which meant your deployment needed either affinity routing or a shared session store. Most teams picked affinity and moved on. The 2026-07-28 specification removes that constraint entirely, and the change is bigger than a version bump.

The release candidate for MCP 2026-07-28 was locked on May 21, 2026 - the largest revision to the protocol since launch - and the final spec shipped on July 28, after a ten-week validation window for SDK maintainers and implementers. If you run MCP servers in production, this is a real code change on some paths, not just a header update.

What the stateless core actually changes

The 2026-07-28 specification converts MCP from a bidirectional stateful protocol into a request/response stateless one. The initialize and initialized handshake is removed. The Mcp-Session-Id header is removed. Every request now carries its own protocol version, client identity, and capabilities - which means any server instance can serve any request behind a plain round-robin load balancer. That single architectural decision is what everything else in the release hangs off.

Three infrastructure changes fall out of this directly:

• Routability. New required Mcp-Method and Mcp-Name headers let load balancers and gateways route requests without inspecting the JSON-RPC body. This matters for rate limiting, service meshes, and anything that needs to make routing decisions without deep packet inspection.
• Cacheability. The addition of ttlMs and cacheScope to list and resource-read responses enables predictable caching
• so a busy tools/list call does not have to hit your server on every agent invocation.
• Traceability. W3C Trace Context propagation in _meta is now documented (SEP-414), locking down the traceparent, tracestate, and baggage key names so distributed traces correlate across SDKs and gateways. A trace that starts in a host application can follow a tool call through the client SDK, the MCP server, and whatever the server calls downstream, and show up as a single span tree in an OpenTelemetry-compatible backend.

Cloudflare's Agents SDK supports the spec from day zero, so developers can run MCP servers directly in Workers, call tools without transport-session overhead, and enable richer flows like elicitation for approvals. GitHub's MCP Server also shipped support ahead of the official release date.

How server-initiated calls work without a persistent connection

This is the technically interesting part of the spec. The old model let servers call back into clients - to ask a user a question, request sampling, or check roots - by holding a Server-Sent Events stream open. The old design handled that by opening a long-lived SSE stream back to the client and holding state until the answer arrived. In a load-balanced deployment that breaks, because the client's answer can land on a different instance than the one waiting for it.

The replacement is Multi Round-Trip Requests (SEP-2322). The server returns resultType: "input_required" plus an opaque request-state token, the client gathers the answers, then calls the same tool again with inputResponses attached. Every leg is an ordinary client-to-server request. Because the state token encodes everything the server needs to resume, any instance in the pool can handle the follow-up.

Server-initiated requests may now only be issued while the server is actively processing a client request (SEP-2260). Earlier spec versions recommended this; it is now required. A user is never prompted out of nowhere, and every elicitation traces back to something they or their agent started.

What is deprecated, and what the timeline actually means

Roots, Sampling, and Logging are deprecated (SEP-2577). They still work, and they will keep working for at least twelve months. New implementations should not adopt them. The legacy HTTP+SSE transport is in the same position.

The key guarantee is a minimum deprecation window: a feature must remain Deprecated for at least twelve months, measured from the release of the revision that first marks it Deprecated, before it is eligible for removal. That puts the earliest possible removal at July 2027 - and only if a subsequent spec version explicitly drops them.

What this means in practice:

During the deprecation period, wire-level behavior is unchanged. No types are removed, no capability negotiation changes, and no existing implementations break. The deprecation serves as a signal to the ecosystem to stop building on these features and to plan for their eventual removal.

The migration work people are underestimating

Most coverage of this spec change focuses on the headline: handshake gone, stateless now, deploy anywhere. That part is largely handled by SDK upgrades. The harder work is finding hidden session state in your own server logic.

Once session dependencies are removed, deploy multiple server instances behind a round-robin load balancer and run your test suite. Any test that fails has a hidden session dependency you missed. That is the single most useful diagnostic step - more useful than reading changelogs.

The other frequently missed item is the elicitation refactor. Elicitation and sampling were effectively blocked on remote MCP servers that could not hold SSE connections or share session state across instances. Multi Round-Trip Requests let those features run on ordinary stateless, load-balanced infrastructure - at the cost of one more breaking migration to plan in step with the stateless core. If you implemented elicitation against the 2025-11-25 spec, the callback pattern needs to become a retry pattern.

A practical checklist before the next deploy:

• Replace any Mcp-Session-Id usage with the explicit-handle pattern
• Update clients to send MCP-Protocol-Version, Mcp-Method, and Mcp-Name on every request
• Replace -32002 error handling with -32602
• Audit server code for anything that opens or holds an SSE stream for sampling callbacks
• Add ttlMs to your tools/list responses where the tool set is stable
• Search for roots/list, sampling/createMessage, and logging/setLevel - not to delete them now, but to know your migration surface before the window closes

MCP is not being replaced - it is being demoted to infrastructure, which is the best thing that can happen to a protocol. The extensions framework (SEP-2133) gives the ecosystem a path to add capabilities - Tasks, MCP Apps, enterprise auth - without bloating the core every team has to implement. That is what makes this revision more than a cleanup: it draws a line between what the protocol owns and what the ecosystem owns.

MCP 2026 stateless spec: common questions

What is the MCP 2026-07-28 spec?

It is the largest revision to the Model Context Protocol since its launch. The core change is making the protocol stateless: the initialize/initialized handshake is removed, along with Mcp-Session-Id. Every request now self-describes, so any server instance behind a round-robin load balancer can handle any request without sticky sessions or shared state.

Does the new MCP spec break existing servers?

Partially. The SDK upgrades handle the mechanical renames, but server code that holds SSE streams open for sampling or elicitation callbacks needs to be refactored to the Multi Round-Trip Request pattern. Any hardcoded -32002 error handling also needs to become -32602. Run a multi-instance load-balancer test against your suite - failures point directly to hidden session dependencies.

Are Roots, Sampling, and Logging removed from MCP?

No. They are deprecated as of July 28, 2026, with a minimum 12-month window before they are eligible for removal. Wire-level behavior is unchanged during the deprecation period - existing implementations keep working. The signal is to stop building new things on them, not to migrate immediately.

What replaces sampling in MCP 2026?

The Multi Round-Trip Request pattern (SEP-2322) replaces the server-initiated callback model. Instead of holding a connection open, the server returns an InputRequiredResult with an opaque state token. The client collects the needed input and re-issues the original call with inputResponses attached. Because all state is in the payload, any server instance can handle the continuation.

Is the HTTP+SSE transport still supported?

It is deprecated as of July 28, 2026, not removed. It has the same 12-month minimum window as the other deprecated features. Teams that have not yet moved off HTTP+SSE should treat this as the start of their offramp, not a signal to wait another year.