Four days ago I wrote about the agent transport layer gap — how MCP solved tool calling and A2A solved multi-agent coordination, but the actual mechanism for moving bytes between agents remained a fragmented, underspecified mess. The MCP 2026-07-28 specification release candidate, published last week, takes a direct swing at part of that problem. The protocol core is going stateless.
This is not a minor revision. The handshake is gone. The Mcp-Session-Id header is gone. Any request can now hit any server instance without session affinity. For anyone building production agent infrastructure, this changes deployment architecture in ways that matter.
What “Stateless” Actually Means
The MCP protocol was designed around a session model. When a client connected to an MCP server, the two would perform a handshake, exchange a session identifier, and include that Mcp-Session-Id header on every subsequent request. The server used this identifier to maintain conversational state — tool definitions, sampling parameters, resource caches — across a sequence of related calls.
This model works fine for single-server deployments. A single Claude Code instance talking to a local filesystem MCP server doesn’t have a scaling problem. But production agent systems don’t look like that. They look like an orchestration agent running in one cloud environment, delegating to specialized agents running in other environments, each potentially connecting to multiple MCP servers simultaneously.
Under the session model, horizontal scaling of MCP servers required sticky sessions — routing all requests from a given client to the same server instance so the session state remained valid. In Kubernetes, this means sessionAffinity: ClientIP. For any deployment that needs to scale beyond one server instance, you’re now running a session store (Redis, memcached, or something similar) and threading session context through your load balancer configuration. That’s operational complexity that has nothing to do with what the agent is actually trying to accomplish.
The 2026-07-28 spec eliminates this at the protocol level. The handshake is gone. The session header is gone. Each request is self-contained — it carries everything the server needs to process it, without referencing shared state from a previous exchange. The server can be scaled horizontally behind a plain round-robin load balancer with no sticky session configuration.
Routable Headers and the MRTR Pattern
The stateless core ships alongside a new header pattern called MRTR — Multi-Round-Trip Routable headers, specified as SEP-2243. This is where the transport gap gets properly addressed.
Under the old session model, a streaming response from an MCP server came back on the same connection established during handshake. The session identifier tied the stream to the correct server-side state. Without sessions, a stateless server handling a multi-turn conversation needs another way to route response fragments back to the correct in-flight request.
MRTR headers embed routing context directly in the HTTP headers themselves — not in a shared session store. When an agent sends a request, it includes a route token in the request headers. When the server streams a response, it echoes that route token back in the response headers. Intermediate proxies (load balancers, API gateways) can inspect and route based on these headers without needing access to a shared session store.
Concretely, this means a deployment like the one I described four days ago — orchestration agent in Region A, specialized coding agent in Region B, both talking to MCP servers in different availability zones — can now use standard HTTP routing infrastructure. No Redis for session affinity. No sticky session configuration. Just SEP-2243 headers doing the correlation work at the transport layer.
This doesn’t fully solve the firewall problem I mentioned in the transport layer post. Enterprise security stacks still flag long-running streaming connections. But it removes one entire class of infrastructure complexity that made the transport problem worse than it needed to be.
Authorization Hardening: OAuth 2.1 and OpenID
The release candidate also tightens authorization, driven by gaps exposed in real-world deployments. The changes center on OAuth 2.1 and OpenID Connect integration.
MCP’s original authorization model was minimal — servers could accept or reject requests, but the protocol didn’t specify how credentials should be propagated or validated across trust boundaries. In a single-vendor ecosystem this is fine. When Anthropic’s Claude Code connects to Anthropic’s own MCP servers, credential propagation is internal. But production agent systems compose MCP servers from multiple vendors, running in different security domains, with different credential formats.
The 2026-07-28 RC formalizes how authorization tokens flow through a request chain. If agent A is delegating to agent B, which is calling MCP server C, the spec now defines how agent A’s authorization context propagates through B to C without re-authentication at every hop. This is the credential-propagation problem I noted in the May 2026 MCP RCE disclosure — the fix wasn’t just patching the vulnerability, it was redesigning how trust is established across agent-to-server boundaries.
OAuth 2.1 removes password grant flows and requires PKCE for all grant types. OpenID Connect adds an identity layer on top. For MCP servers running in enterprise environments, this means authorization can now be delegated through standard OIDC providers rather than requiring custom per-server credential management.
Extensions as First-Class Citizens
The 2026-07-28 spec also formalizes extensions as a first-class protocol concept. Previous MCP versions treated extensions as informal additions — servers could expose extra capabilities beyond the base spec, but clients had no standard way to discover or negotiate them.
The RC introduces a formal extension negotiation mechanism. Servers can declare supported extensions in their initial response, clients can request specific extensions during capability negotiation, and the protocol defines how extension-specific message types are identified and routed. This matters because the MCP ecosystem has exploded — from 50 servers in March 2025 to over 200 by May 2026 — and a significant portion of that growth happened through server-specific extensions that weren’t portable across clients.
Two extension categories stand out for agent builders: server-rendered user interfaces and long-running tasks. Server-rendered UIs let an MCP server send structured UI definitions (think React component specifications) that the client renders natively — this enables progressive disclosure patterns where a tool’s output can include interactive elements without a separate rendering round-trip. Long-running tasks formalize how agents handle operations that exceed normal request timeouts — the spec now defines a task lifecycle (pending → running → complete/failed) with intermediate progress notifications, rather than leaving it to server-specific patterns.
What Changes for Agent Infrastructure Builders
If you’re running MCP servers behind a session-aware load balancer today, the migration path to the stateless spec has two phases. Phase one is SDK updates — the TypeScript, Python, and Rust MCP SDKs all need to update to handle stateless requests. The official release candidate has been available since the spec lock on May 21, giving SDK maintainers a ten-week window to prepare, but not all SDKs have shipped 2026-07-28-compatible releases yet. Phase two is deployment reconfiguration — removing sticky session rules, updating health checks that depended on session state, and updating any infrastructure that reads Mcp-Session-Id headers.
For new deployments, the stateless core is an immediate improvement. You can deploy MCP servers as stateless pods behind a standard Kubernetes Service with no session affinity, scale horizontally with a simple round-robin load balancer, and rely on MRTR headers for multi-turn routing. The operational overhead drops significantly.
The deeper implication is that MCP is evolving from a tool-calling protocol into a full agent infrastructure layer. The 2026-07-28 spec moves it closer to being the transport AND authorization AND capability-negotiation layer that production multi-agent systems need. A2A handles the coordination problem between agents. MCP is now better equipped to handle the transport problem between agents and the tools those agents rely on.
That’s the missing piece I wrote about on July 19 — not fully solved, but significantly improved. The protocol stack is starting to close the gap.
Comments
Powered by GitHub Discussions via Giscus. Sign in with GitHub to leave a comment.