mcp just went stateless — the 2026-07-28 spec rewrites how agents scale

the Model Context Protocol published its 2026-07-28 specification on July 28, 2026 — the largest revision since the protocol launched. the headline change: MCP moves from a stateful, session-oriented protocol to a stateless request/response core. if you have built or deployed an MCP server, this affects you.

what stateless means in practice

the previous spec required sticky sessions, a shared session store, and gateway-level deep packet inspection to keep a client talking to the same server instance. every request had to route back to the session that initialized it. that made MCP servers hard to scale horizontally and brittle behind load balancers.

the 2026-07-28 spec eliminates all of that. every request is self-describing. the initialize / initialized handshake and the Mcp-Session-Id header are gone. a server instance that handles one request has no obligation to handle the next one from the same client. that means MCP servers can now run behind a plain round-robin load balancer — the same way any stateless API runs.

the Mcp-Method and Mcp-Name headers

to compensate for removing per-session routing, the Streamable HTTP transport now requires an Mcp-Method header on every request. the Mcp-Name header is required for tools/call, resources/read, and prompts/get requests specifically.

the result: gateways, load balancers, and rate-limiters can route on headers without inspecting the request body. a CDN edge rule can send all tools/call requests to a high-performance cluster and all resources/read requests to a caching tier. servers reject requests where the headers and body disagree, so the headers cannot be faked to bypass routing policy.

multi-round-trip requests and list caching

stateless does not mean single-request-only. the spec adds Multi Round-Trip Requests: a structured way for a server to ask for more information mid-operation without requiring persistent session state. the client carries the context between rounds; the server stays stateless.

tools/list, resources/list, and prompts/list responses now carry a ttlMs field. clients can cache those lists for the specified duration and skip redundant discovery calls. for high-volume agent setups where every task starts with capability discovery, that is a meaningful reduction in round-trips.

authorization hardening

the spec tightens OAuth in several concrete ways. RFC 9207 issuer validation is now required (issclaim must match the authorization server's metadata URL). Dynamic Client Registration is being formally replaced by client metadata documents. scope accumulation on step-up and credential binding to the issuing authorization server are both specified in new Security Enhancement Proposals.

the practical effect: clients that relied on DCR to register dynamically will need to adopt the new CIMD flow. the spec gives a migration path, but it is a breaking change for OAuth-integrated MCP deployments.

the extensions framework

MCP previously had no formal way to add capabilities outside the core spec. new capabilities either waited for a spec revision or lived as unofficial patterns. the 2026-07-28 spec introduces a formal Extensions framework (SEP-2133): extensions are identified by reverse-DNS IDs, negotiated through an extensions map on client and server capabilities, live in their own ext-* repositories with delegated maintainers, and version independently of the core spec.

Tasks, MCP Apps, and Enterprise Managed Authorization are the first extensions using this path. the goal is to give the ecosystem a structured way to experiment without polluting the core protocol.

who needs to act, and when

the 2026-07-28 spec ships with updated Tier 1 SDKs (TypeScript, Python, Go). if you maintain an MCP server that relies on Mcp-Session-Id or the initialize handshake, you will need to migrate. Anthropic has said Claude will adopt the 2026-07-28 spec going forward, and AWS AgentCore Gateway already supports the new headers.

for most vibe-coding setups — local MCP servers wired to a single Claude Code session — the day-to-day impact is minimal. the spec change matters most if you are running multi-user or production agent infrastructure where horizontal scaling and gateway routing are real problems. for those deployments, this is the change that makes MCP operationally serious.