Agent Builder Foundations

Earlier MCP opened with a handshake: the server issued an Mcp-Session-Id header, the client echoed it on every call, and each call had to land on the issuing instance. The 2026-07-28 spec removed that. Protocol version and client capabilities now travel in each request's _meta parameter, so any node can serve any call. The same revision added governed extensions (SEP-2133) and moved authorization toward standard OAuth 2.0/OpenID Connect.

This is the stateful-session versus stateless-HTTP choice.

• Stateful: follow-up calls must reach the instance holding session state. You pin clients (sticky sessions) or replicate state to a shared store, and a failed instance drops its sessions.
• Stateless: each request carries what the handler needs. The load balancer routes on capacity, and any healthy instance takes the next call.

MCP moved from the first to the second, so gateway fleets can behave like ordinary horizontally scaled web services.

Before the change, the session identifier was the binding. Negotiated capabilities and protocol version lived only on the instance that issued the ID, so only that instance could interpret later calls correctly.

Now each request restates its protocol version and capabilities in _meta. Serving a call no longer depends on which instance served the previous one. "Stateless" applies to the protocol only: a tool implementation can still hold state such as a database connection or cache. The protocol just stops requiring request-to-request server affinity.

Two other changes shipped in the same revision and are independent of statelessness:

• Governed extensions (SEP-2133). Each capability gets a reverse-DNS id, its own repository and maintainers, and its own release cadence. Client and server negotiate support through an extensions capability map instead of a core version bump.
• Authorization hardening. Six SEPs align the spec with OAuth 2.0 and OpenID Connect patterns. They do not change how a given gateway validates inbound credentials.

• Remove session-affinity infrastructure once clients and servers both speak 2026-07-28 or later. Keep sticky rules only if something other than MCP needs them.
• Verify library versions first. Confirm your client and server libraries negotiate through _meta, not a lingering Mcp-Session-Id header, before dropping affinity routing.
• Read the negotiated extensions map. A matching core version does not mean a peer supports a given extension.
• Audit gateway auth separately. Upgrading the protocol version is not an inbound-auth upgrade.

• Removing sticky routing while a library still uses the old handshake, silently breaking multi-call sessions.
• Confusing a stateless protocol with stateless tools; tool-level state remains an application decision.
• Treating the authorization SEPs as a credential upgrade for your gateway.
• Assuming extension support from a matching core version.

See MCP for the protocol's adoption arc and tool use for tool-calling failures this scaling change does not address.