MCP goes stateless: what the 2026-07-28 spec changes and how to migrate

What changed in the MCP 2026-07-28 specification?

The 2026-07-28 revision makes the MCP core stateless. It removes the initialize/initialized handshake and session IDs, introduces Multi Round-Trip Requests for mid-call user input, adds routing headers and cache hints, tightens OAuth handling, moves Tasks into an extension and deprecates Roots, Sampling, Logging and the HTTP+SSE transport.

Adoption is broad: the official MCP blog says the Tier 1 SDKs (TypeScript, Python, Go and C#) were close to half a billion downloads a month on the previous release, and all four support 2026-07-28 at launch, with Rust in beta. At least 15 companies, including AWS, Google Cloud, Microsoft, Anthropic and Cloudflare, are quoted confirming support.

Why did MCP drop sessions? The architecture before and after

Sessions forced every request from a client back to the server instance that ran its handshake. That meant sticky load balancing, shared session stores and fragile rollouts. Without sessions, any instance can answer any request, so MCP servers behave like ordinary stateless HTTP services that scale horizontally and run happily on serverless platforms.

Under 2025-11-25, an HTTP client opened a session with initialize and sent the resulting Mcp-Session-Id on every later call. Google’s Developers Blog (5 August 2026) describes the consequence: session IDs pinned clients to specific containers, so operators needed sticky session affinity at the load balancer.

Google’s post is concrete about the payoff. Round-robin load balancers work with no affinity rules; pod restarts, rollouts and autoscaling become invisible to clients; and servers can run as Cloud Run services or Cloud Functions that spin down when idle. It also reports that GitHub’s MCP server removed its Redis session storage entirely, cutting a database read and write from every call. For teams running MCP on cloud infrastructure, that is one less stateful component to operate and pay for.

How do Multi Round-Trip Requests work?

Multi Round-Trip Requests (MRTR) let a server ask the client for input without holding a connection open. The server ends the call with an interim result marked input_required, listing what it needs plus an opaque state value. The client gathers the answers and re-sends the original call with them, so any server instance can resume.

Previously, a server needing a user confirmation (elicitation) or a model completion (sampling) mid-call sent its own request back over a stream that had to stay open. Per the Stacktree write-up of the spec (SEP-2322), every result now carries a required resultType field:

1. 01Client calls a tool (or a prompt or resource) as normal, with protocol version and capabilities in _meta.
2. 02Server needs input. It returns resultType "input_required" with inputRequests (a map of the elicitation or sampling requests it needs answered) and requestState, an opaque value.
3. 03Client resolves the requests by asking the user, or its own model, as appropriate.
4. 04Client re-issues the original call with inputResponses and the echoed requestState.
5. 05Any server instance completes the work and returns resultType "complete", or asks for more input.

As Stacktree puts it, all the state rides in the payload. Our take for server authors: requestState must contain everything needed to resume, so treat it like a signed or encrypted continuation token, validate it on return and give it an expiry.

What do the new headers, cache hints and auth rules change?

Three smaller changes have big operational effects. Mcp-Method and Mcp-Name headers let gateways route, authorise and rate-limit without parsing JSON. ttlMs and cacheScope let clients cache tool and resource lists safely. And the authorization rules close gaps in OAuth handling, including a formal move from Dynamic Client Registration to Client ID Metadata Documents.

Routing headers

Streamable HTTP requests now carry Mcp-Method and Mcp-Name alongside Mcp-Protocol-Version. Stacktree describes them as required on Streamable HTTP POST requests, so a WAF or API gateway can route, rate-limit and log by method and name without inspecting the request body.

Cache hints on list results

tools/list, prompts/list, resources/list and resources/read (and, per Stacktree, resources/templates/list) can return ttlMs, a freshness hint in milliseconds, and cacheScope, either "public" or "private". Mark per-user tool lists private so a shared cache never serves one user’s tools to another.

Authorization hardening

• Issuer validation. RFC 9207 issuer validation is required; clients check the iss value against the authorization server they expect.
• application_type at registration. Clients declare it during Dynamic Client Registration, which Stacktree notes resolves rejected localhost redirects for native clients.
• Issuer-bound credentials. Credentials are tied to the authorization server that issued them and must not be reused across servers.
• CIMD over DCR. Dynamic Client Registration is deprecated in favour of Client ID Metadata Documents.

Extensions and deprecations

A new extensions framework hosts optional features: Tasks (now io.modelcontextprotocol/tasks), MCP Apps (interactive HTML UI in a sandboxed iframe) and Enterprise Managed Authorization. The deprecated features keep working for at least 12 months, though Stacktree notes the policy allows expedited removal with 90 days’ notice for security issues.

Migration checklist for MCP server and client authors

Start by finding every piece of state keyed on Mcp-Session-Id, because that is the real migration work. Then read version and capabilities from _meta, adopt input_required instead of server-initiated requests, add cache hints, route on the new headers, harden OAuth and plan off Roots, Sampling, Logging and HTTP+SSE within the deprecation window.

Stacktree notes that publication “does not turn anything off” for implementers on 2025-11-25, so you can sequence this work rather than rush it. We would order it like this:

For server authors

1. 01Inventory session state. Search for Mcp-Session-Id, in-memory maps keyed by session, and any Redis or database tables holding session data.
2. 02Replace sessions with explicit handles. If a tool opens a cart or a browser, return an ID and accept it as an ordinary argument on later calls. Store the backing state yourself, with expiry and an authorisation check.
3. 03Read context from _meta. Version, client info and capabilities arrive on every request under io.modelcontextprotocol/ keys. server/discover is available for up-front discovery but, per the MCP blog, not required.
4. 04Move to input_required. Rewrite elicitation and sampling flows to return inputRequests and requestState, and make requestState tamper-evident.
5. 05Add ttlMs and cacheScope to list and read results, with private scope for anything user-specific.
6. 06Move off HTTP+SSE to Streamable HTTP, and migrate experimental Tasks code to the tasks extension.

For client and host authors

1. 01Send _meta on every request and stop depending on a handshake to learn server capabilities.
2. 02Send the new headers: Mcp-Method, Mcp-Name and Mcp-Protocol-Version on Streamable HTTP requests.
3. 03Implement the retry loop for input_required, with a limit on rounds.
4. 04Respect cache hints and never share a private-scope cache across users.
5. 05Fix OAuth handling: validate the issuer, send application_type, key stored credentials by issuer and prepare for CIMD.

For platform and ops teams

• Drop sticky-session rules once every client you serve speaks 2026-07-28.
• Pin SDK versions and test against the hosts your users actually run before cutting over.

Where does A2A fit now that it has joined the Agentic AI Foundation?

MCP and A2A solve different problems. MCP standardises how an agent connects to tools and data; A2A standardises how agents built by different vendors discover each other and delegate work. Since 17 August 2026 both sit in the Agentic AI Foundation, hosted by the Linux Foundation, alongside goose, AGENTS.md and agentgateway.

The AAIF announcement describes A2A as letting agents on different frameworks discover each other, delegate tasks and exchange work without custom integration code. Agents publish “agent cards” describing their capabilities. More than 150 organisations support it, including AWS, Cisco, Google, Microsoft, Salesforce, SAP and ServiceNow.

Our take

Shared, vendor-neutral governance lowers the risk of betting on either protocol. Most teams need MCP first, to expose their own systems to agents; A2A becomes relevant when agents must coordinate across team or company boundaries. If you are new to the vocabulary, our guide to what agentic AI is covers the basics.

What this means for teams building now

If you run MCP servers, schedule the migration now but sequence it: remove session-keyed state first, then adopt input_required and cache hints, then retire sticky sessions once clients support the new version. If you are starting fresh, build against 2026-07-28 directly and design every tool to be stateless from day one.

• New servers: target 2026-07-28, deploy behind a standard load balancer or on serverless, and pass explicit handles for anything stateful.
• Existing servers: nothing switches off on publication, but the deprecation clock for Roots, Sampling, Logging and HTTP+SSE is running; plan replacements within the 12-month minimum window.
• Security teams: use the new headers for gateway policy and logging, review OAuth against the issuer rules, and audit handle authorisation.

The protocol change is mostly an infrastructure win; the work is in application code that quietly relied on sessions. If you want a second pair of eyes on an MCP migration or a new agent integration, our generative and agentic AI team builds and hardens these systems.

Frequently asked questions

Sources

1. The 2026-07-28 Specification — Model Context Protocol blog, 2026-07-28
2. Scaling AI Agent Infrastructure with the MCP Stateless updates — Google Developers Blog, 2026-08-05
3. What changed in the 2026-07 MCP specification — Stacktree, 2026-09-30
4. A2A joins AAIF’s open agentic stack — Agentic AI Foundation, 2026-08-17