The Session Tax: Stateless MCP for Auditable Cloud Agents

The Session Tax: Why Sticky MCP Connections Don’t Scale With Agent Fleets

Every MCP server built against the 2025-11-25 specification pays what we’d call a session tax: the recurring infrastructure cost of keeping a stateful connection alive across every request an agent makes. The client sends an initialize request, the server responds with initialized, and from that point on every subsequent call has to land back on the exact server instance that handled the handshake. That constraint is invisible with one agent talking to one server. It stops being invisible at fleet scale. Once an organization runs many agents against production cloud systems at once, the tax becomes the dominant infrastructure cost, because every server instance now has to remember, and defend, a growing table of open sessions.

The tax shows up in two places. First, the load balancer needs sticky routing (session affinity keyed on a client) instead of plain round-robin, which means every new server instance you add has to inherit the same routing table. Second, if a server instance restarts, every agent connection routed to it loses its session and has to re-handshake, so a routine deploy becomes a coordinated cutover.

The 2026-07-28 MCP specification release candidate was published 2026-05-21. It carries a ten-week validation window ending at the 2026-07-28 final release. It also removes the mechanism that creates the tax: the initialize/initialized handshake and the Mcp-Session-Id header are gone entirely. Every request now carries its own protocol and client information in _meta fields instead, so no server instance needs to remember which client it talked to five minutes ago.

That last row matters operationally: a remote deployment can now route traffic on the Mcp-Method header alone, which means infrastructure teams can make routing decisions without inspecting or terminating the request body.

Stateless by Default: What the 2026-07-28 Spec Actually Changes

The mechanism is worth spelling out precisely. “Stateless” is doing a lot of work in that sentence. Under the RC, a client’s protocol version and identifying details travel with each individual request instead of being negotiated once at connection time. There’s no session object living in server memory. There’s no shared session store either, no Redis instance or database table that a horizontally scaled deployment has to stand up just to keep agent connections coherent across instances.

That single change collapses two categories of infrastructure MCP operators used to build: sticky load balancer configuration and a shared session backend. Neither is exotic engineering. But both are recurring maintenance cost. And both introduce a new way to break: a session store outage takes down every agent connection at once, even ones that never write to it.

The spec pairs this with two new headers, Mcp-Method and Mcp-Name. Infrastructure can route and observe traffic without opening the request body. A reverse proxy can log which tool an agent called. It can shed load selectively by method, using header inspection alone. Two more additions, ttlMs and cacheScope parameters, let clients cache list and resource responses locally instead of re-fetching them on every call. That cuts redundant round-trips for agents that repeatedly ask a server “what tools do you have.”

The practical test for whether your own MCP integration benefits from this: count how many places in your infrastructure exist solely to keep a session alive across requests. Under the RC, that count goes to zero.

This works when your load balancer can already route on request headers, since Mcp-Method gives it a signal to route on immediately. It fails when your server-side MCP code still assumes one long-lived connection per client internally, because removing the handshake from the wire protocol doesn’t remove the assumption from code written against it. That code has to change too.

Long-Running Actions Get a Real Abstraction: The Tasks Extension

Removing session state solves the connection problem. But agents acting on live production systems run into a second, unrelated problem: some actions take minutes, not milliseconds. Provisioning a cluster, running a remediation, migrating a workload: none of these fit a single synchronous tools/call request/response cycle. Before this RC, teams handled that gap with ad hoc polling scripts. Others bolted custom webhook callbacks onto the protocol instead.

The Tasks extension graduates from experimental to a core feature in the 2026-07-28 spec specifically to close that gap. Instead of a tool call blocking until the action finishes, a server can answer tools/call with a task handle immediately. The client then drives progress with three calls: tasks/get to check status, tasks/update to receive progress, and tasks/cancel to abort. The long-running action becomes a tracked object instead of an open connection the client has to keep alive.

This is the same operational shape as detect-classify-remediate-verify, a pattern already common in cloud governance tooling: an action gets initiated, its state is checked and updated over time, and the outcome is recorded with an audit trail rather than assumed from a single response. zopnight’s shipped auto-remediation capability, CDCR, already runs that loop today for cloud governance actions independent of MCP, tracking each remediation from detection through classification, execution, and verification, with an audit trail attached at every step. The Tasks extension formalizes the equivalent pattern at the protocol level: initiate, check status, report progress, and finish or cancel, all tracked as one object instead of one blocking call. That matters for any MCP implementation, including one exposing cloud governance tools, whose actions cannot complete inside a single request and need the same kind of accountable, checkable lifecycle CDCR already gives a remediation.

The problem this replaces is worth naming directly. A synchronous tool call with no task abstraction either times out and loses track of an in-flight cloud action, or it forces the client to hold a connection open for the full duration of a multi-minute operation. Neither is acceptable once agents are taking actions with real infrastructure consequences.

Authorization Hardening Closes a Gap That Scales With Agent Count

A stolen or over-scoped credential in a single human session is a bounded problem: one person, one set of actions, one remediation. The same gap in an autonomous agent’s credential is a multiplier. The agent can act continuously and at machine speed against every resource that credential can reach. That’s why six SEPs in the 2026-07-28 RC focus specifically on tightening authorization, not adding new capability surface.

None of these are exotic protections. They’re the same category of control: issuer pinning, scoped credentials, documented rotation. Any team running standing service credentials against production cloud systems already applies this to API keys and cloud access roles. The RC just brings MCP’s authorization layer up to that same baseline, instead of leaving it to each server implementation to get right on its own.

For a team running agents against production cloud governance tools, the practical question during the validation window is simple. Does your authorization server validate issuer and bind credentials correctly, not just pass a handshake? That question applies equally to a custom MCP implementation or a shipped one, like zopnight’s 43 read-only tools exposed to Claude, Cursor, and Codex. A credential that isn’t bound to its issuing server is a credential that works somewhere it shouldn’t.

What Deprecates, and What to Check Before You Adopt the RC

SEP-2577 formally deprecates three features, each on a minimum 12-month deprecation window before removal, per the spec’s Feature Lifecycle Policy: a deprecated method, type, or capability flag stays functional in every specification version published within that year, so nothing fails the day you upgrade.

Two more changes are easy to miss in a changelog skim but will fail a naive integration test. First: tool inputSchema and outputSchema are upgraded to full JSON Schema 2020-12. Schemas can now use oneOf, anyOf, allOf, and conditionals, though the root still has to be type: "object". A validator written against the older schema subset needs testing against these new composition keywords. Second: the error code for a missing resource changes from the MCP-specific -32002 to the standard JSON-RPC -32602. Any client with a hardcoded check for -32002 will silently stop catching that error after upgrading.

The concrete pre-adoption checklist: grep your client code for hardcoded MCP error codes, confirm your JSON Schema validator handles 2020-12 composition keywords, and confirm nothing in your integration depends on Roots, Sampling, or MCP-native logging outlasting the 12-month window.

Running Agents Against Cloud Infrastructure? Plan Around Statelessness Now

The 2026-07-28 spec’s ten-week validation window is exactly the period to test these changes against a non-production MCP integration before they land everywhere. Tier 1 SDKs are expected to ship support within that window. That means the client and server libraries most teams depend on will have RC support well before the July 28 final release.

Three things are worth testing, in order. First, whether your MCP deployment can run without sticky routing today; if it can’t, figure out why before you scale the agent fleet that will expose the problem. Second, whether any long-running action in your integration would benefit from the Tasks extension instead of a synchronous call that risks timing out. Third, whether your authorization implementation validates issuer and binds credentials the way the six hardening SEPs now require.

None of this requires waiting for a specific vendor to adopt the new spec version first. zopnight’s own MCP surface is a concrete example already in production: 43 read-only tools exposed to Claude, Cursor, and Codex today. That’s exactly the category this spec revision is built for. Statelessness, task tracking for longer operations, and tightly scoped credentials stop being nice-to-haves the moment more than one agent is calling an integration at once.

The spec revision is a signal, not a mandate. But the failure it targets, agent fleets outgrowing session-sticky infrastructure, shows up gradually and then all at once. The ten-week validation window is the cheapest time to check where your own integration stands.