Agent Builder Foundations

Earlier MCP versions opened a connection with an initialization handshake: the server issued an Mcp-Session-Id header, and the client had to send it back on every following call, which meant that call had to land on the same server instance that issued it. The 2026-07-28 spec — the largest revision since MCP launched — removed that handshake. Each request is now self-contained: protocol version and client capabilities travel inside the request's own _meta parameter, so any gateway node can service any call. The same revision also formalized a governed extensions system (SEP-2133) so new capabilities ship independently of the core spec, and hardened the authorization spec toward standard OAuth 2.0/OpenID Connect patterns.

Treat this the same way you'd treat choosing between a stateful WebSocket session and stateless HTTP requests. A stateful protocol needs every follow-up call routed to the specific instance holding that session's state — you either pin the client to that instance (sticky sessions) or replicate the state to a shared store every backend can read. Either way, that instance failing mid-session drops the session's context with it. A stateless protocol removes that constraint by having each request carry what a handler needs to serve it, so a load balancer can route purely on capacity and any healthy instance can pick up the next call. MCP moving from the former to the latter is a protocol-level decision to make gateway fleets behave like ordinary horizontally scaled web infrastructure instead of like a session-affine service.

Before the 2026-07-28 spec, an MCP client opened a session with an initialization exchange, and the server responded with a session identifier the client was required to echo on every subsequent request. That identifier was the mechanism binding a client to one server instance: whichever instance issued the session ID was the only one that could correctly service later calls in that session, because session state (negotiated capabilities, protocol version) lived on that instance and nowhere else by default.

The new spec drops the handshake and the header. Instead, the protocol version and the client's capabilities are included directly inside the _meta parameter of each request. Nothing about serving a given call depends on which instance served the previous one, because the previous call's context isn't implicitly required — the current call restates what it needs. That is what "stateless" means here concretely: not that MCP servers can't hold state at all (a tool implementation can still be stateful in whatever way it needs), but that the *protocol* no longer requires request-to-request server affinity to interpret a call correctly.

Two other changes shipped in the same revision, distinct from statelessness but bundled into the same spec bump: a governed extensions system (SEP-2133) that gives each new protocol capability a reverse-DNS identifier, a dedicated repository with delegated maintainers, and its own release cadence — so a client and server negotiate which extensions they both support via an extensions capability map, instead of every new feature forcing a core version bump; and six SEPs that bring MCP's authorization specification closer to standard OAuth 2.0 and OpenID Connect deployment patterns, without changing how a specific gateway's inbound credential check (IAM/SigV4, OAuth/JWT) is implemented.

• Story-backed: the AWS AgentCore Gateway writeup names the specific mechanism change (session-handshake header replaced by a self-contained _meta parameter) and the two accompanying spec changes (governed extensions via SEP-2133, six authorization-hardening SEPs), and reports that AgentCore Gateway operators enable the new spec version via a single UpdateGateway call rather than a redeployment.
• Storyline-backed: the gateway-mcp thread shows the practical consequence within days — Azure API Management shipping a dedicated AI Gateway tier as a control plane spanning multiple model providers and MCP servers, evidence that the ecosystem is building on the assumption that MCP traffic can be routed statelessly.
• Editorial inference: the load-balancing and failover framing (sticky routing vs. stateless routing, HTTP's own history of this trade-off) is LLM Digest's synthesis connecting the protocol change to standard distributed-systems scaling practice; it is not a claim from either source article.

• Drop session-affinity infrastructure once your MCP clients and servers both speak the 2026-07-28+ spec. Sticky load-balancer rules or a shared session-ID store are no longer required by the protocol; keep them only if something else in your stack (not MCP itself) still needs them.
• Check your MCP client/server library version before assuming statelessness. A library built against a pre-2026-07-28 spec version may still perform the old handshake; confirm the library negotiates via the _meta parameter, not a lingering Mcp-Session-Id header, before removing affinity routing.
• Treat extension support as negotiated, not assumed. With SEP-2133, a server can support an extension your client doesn't know about, or vice versa; check the negotiated extensions capability map rather than assuming a feature is available because the spec version matches.
• Re-verify your gateway's inbound auth separately from the spec bump. The authorization hardening changes the *specification's* alignment with OAuth 2.0/OIDC; it does not automatically change how your specific gateway validates inbound credentials, so upgrading the protocol version is not itself an auth upgrade.

• Assuming statelessness before your stack supports it: removing sticky routing while a client or server library still relies on the old session-handshake header silently breaks multi-call sessions.
• Conflating "stateless protocol" with "stateless tools": the protocol no longer requires server affinity to route a call correctly, but a tool implementation behind the gateway can still hold state (a database connection, a cache) — that's an application-level design choice, not something the spec decides for you.
• Treating the authorization SEPs as a credential-mechanism upgrade: they align the spec with OAuth 2.0/OIDC conventions, but your gateway's actual inbound auth check doesn't change unless you change it.
• Skipping the extension negotiation check: assuming a peer supports an extension because both sides report the same core protocol version, when SEP-2133 extensions are negotiated independently of core version.

See MCP for the protocol's broader adoption arc and tool use for the wider set of agent tool-calling failure modes this scaling change doesn't address.