MCP 2026-07-28: Stateless HTTP Migration Guide

The short answer

The MCP 2026-07-28 specification changes remote Model Context Protocol servers from session-oriented HTTP to a stateless-by-default request model. The initialize handshake and Mcp-Session-Id transport header are no longer the center of the protocol. Each request carries the protocol information needed to route and authorize it, while Multi Round-Trip Requests (MRTR) replace several server-initiated interactions that previously depended on a long-lived connection.

For developers, this is not a reason to rewrite every local stdio integration today. It is a migration signal for remote servers: update the SDK, test discovery and header handling, move application state into explicit handles, and review OAuth, caching, and long-running task behavior before switching production traffic.

What changed in MCP 2026-07-28

The official MCP specification release describes six changes that matter most in production:

• Stateless protocol core: remote calls can be handled by any healthy server instance without transport-level session affinity.
• Multi Round-Trip Requests: a tool can return an input-required result and let the client retry with user responses, instead of holding an open server-to-client stream.
• Header-based routing: Mcp-Method and Mcp-Name expose routing and authorization information to ordinary HTTP infrastructure without parsing JSON-RPC bodies.
• Cacheable list results: tool, prompt, and resource listings can carry ttlMs and cacheScope hints.
• Authorization hardening: issuer validation and Client ID Metadata Documents improve OAuth safety; Dynamic Client Registration is moving toward deprecation.
• Extensions and deprecations: Tasks move into an extension, while Roots, Sampling, Logging, and legacy HTTP+SSE receive a formal deprecation path.

The maintainers’ 2026-07-28 specification announcement is the normative starting point. Google’s engineering explanation independently describes why session pinning, shared state, and sticky routing became operational problems as MCP servers moved behind cloud load balancers. That makes the release more than a naming change: it changes the deployment boundary.

Visual: the old and new request paths

Figure 1 — Conceptual migration diagram. The old path depends on transport session affinity; the new path lets ordinary HTTP routing distribute requests. The diagram is an original editorial rendering based on the MCP specification announcement and Google’s infrastructure analysis.

Stateless transport does not mean that an application cannot have state. A shopping basket, browser session, or asynchronous job can still exist. The difference is that the server should mint an explicit identifier and require the model or client to send that identifier as a validated argument on the next request. State becomes visible, testable application data instead of hidden transport memory.

What a stateless tool call looks like

A 2026-07-28 Streamable HTTP request carries the protocol version and routing hints in headers, while the JSON-RPC body remains authoritative:

1POST /mcp HTTP/1.1
2Host: mcp.example.com
3Content-Type: application/json
4MCP-Protocol-Version: 2026-07-28
5Mcp-Method: tools/call
6Mcp-Name: search
7
8{"jsonrpc":"2.0","id":7,"method":"tools/call","params":{"name":"search","arguments":{"q":"MCP"},"_meta":{"io.modelcontextprotocol/clientInfo":{"name":"build-bot","version":"2.1"}}}}

The headers are useful to a gateway that needs to route, meter, or log traffic without deep packet inspection. They are not permission to trust a header over the body. The specification requires implementations to reject mismatches rather than silently choose one value.

For a migration, add tests for at least these cases. If your team is still building its baseline MCP architecture, start with the MCP developer guide before applying the protocol-level changes below.

1. A valid request reaches any instance behind a round-robin load balancer.
2. A missing or malformed protocol header fails with a useful client error.
3. A header/body method mismatch is rejected.
4. A replay with an explicit application handle is authorized for the correct tenant.
5. Tool-list caching obeys the server’s declared scope and lifetime.

A practical migration sequence

1. Inventory transport and state assumptions

Search your server and gateway code for initialize, Mcp-Session-Id, SSE endpoints, sticky-session configuration, Redis session stores, and callbacks that assume the same process will receive the next request. Separate local stdio behavior from remote Streamable HTTP behavior; the migration pressure is primarily on the latter.

Record every piece of state currently stored in a protocol session. For each one, decide whether it should become a signed handle, a database record, a cache entry, or disappear entirely. Never move a session identifier into a user-controlled argument without tenant binding, expiry, and authorization checks.

2. Upgrade the SDK in a staging branch

Use an SDK release that explicitly supports the 2026-07-28 revision. For .NET, the official MCP C# SDK 2.0 announcement documents stateless HTTP as the default, discovery-first negotiation, MRTR, standardized headers, and the compatibility path for older peers. Its later 2.2.0 release notes add hybrid stateful/stateless serving, which is useful when one endpoint must support both protocol generations.

Do not treat “the package installed” as a migration. Pin the version, read its breaking-change notes, and compile a representative server and client. For teams using interactive agent interfaces, compare the wire-level changes with the MCP Apps implementation guide so UI approvals and tool calls are tested together. For TypeScript, Python, and Go, use the corresponding official SDK migration notes and run protocol-level tests rather than relying only on application unit tests.

3. Make discovery and fallback observable

New clients may use server/discover before invoking tools, while older servers may still require the initialize exchange. Log the negotiated protocol revision, transport mode, server identity, and fallback reason. Avoid logging bearer tokens, tool arguments containing personal data, or full prompt contents.

A useful dashboard separates:

4. Replace hidden session state with explicit contracts

A tool that previously relied on server memory should return a handle with a narrow lifetime and scope. Validate it like any other authorization-bearing input. Bind it to the authenticated subject, organization, tool name, and expected operation. If the handle represents a destructive workflow, require a fresh confirmation or approval rather than treating possession of the handle as consent.

This is where MCP’s new statelessness connects to the broader MCP security and threat-modeling guidance. A load balancer can distribute requests safely only if the application’s identity and authorization checks are safe at every hop.

5. Test MRTR, Tasks, and deprecations explicitly

MRTR changes the shape of interactive tools. A server may return an input-required result, the client may ask the user a question, and the original call may be retried with the response and request state. Test duplicate submissions, expired request state, user cancellation, and retries that land on a different instance.

For work that lasts longer than a normal request, use the Tasks extension and an external task store. Test polling, completion, failure, cancellation, and authorization on every status read. Do not keep a connection open merely because an old implementation used server-initiated messages.

Also make deprecations visible in CI. Existing Roots, Sampling, Logging, and legacy HTTP+SSE integrations may continue during the transition window, but new code should not deepen the dependency. Add an issue with an owner and a removal target rather than allowing warnings to become background noise.

Operational and security checklist

Before production rollout, verify:

• The load balancer can route MCP requests with no sticky-session rule.
• Every application handle has expiry, tenant binding, and replay controls.
• Gateways preserve MCP headers and reject conflicting body/header values.
• OAuth validates the issuer and resource audience; PKCE uses S256 where required.
• Tool-list caches are scoped correctly and invalidated after capability changes.
• MRTR state is encrypted or integrity-protected and cannot be enlarged without limits.
• Destructive tools advertise their behavior and require explicit confirmation.
• Logs contain correlation IDs and protocol metadata, but not secrets or sensitive arguments.
• Older clients have a measured fallback path with a sunset date.
• Rollback can restore the prior SDK and transport mode without losing application data.

For observability, pair protocol metrics with the privacy controls in the OpenTelemetry GenAI observability guide. A successful migration is not just fewer 400 errors; it is a system where you can explain which client revision called which tool, which authorization decision was made, and where a failed round trip stopped.

Common migration failures

“Stateless means I can delete Redis.” Only if Redis was used exclusively for protocol sessions. Application state, rate limits, task status, and replay protection may still need shared storage.

“The headers are trusted because they came from the client.” They are routing metadata, not an authorization decision. Compare them with the JSON-RPC body and enforce identity and permissions at the tool boundary.

“The new client broke our old server.” Implement discovery and a deliberate legacy fallback, then measure it. Do not silently downgrade forever.

“MRTR is just another streaming protocol.” It is specifically useful because the interaction can resume through ordinary requests. Test it as a resumable state machine, including cancellation and expiry.

“A passing compatibility test proves production readiness.” It does not. Exercise multiple instances, a real gateway, token rotation, cache behavior, failure recovery, and destructive-tool approval.

FAQ

Do local MCP servers need immediate changes?

Usually not for stdio-only development. Still upgrade deliberately if your host and SDK support the new revision, because shared code may later be deployed remotely and deprecation warnings can reveal future work.

Is MCP 2026-07-28 backward compatible?

The ecosystem provides interoperability paths, but individual SDK defaults and APIs can change. Test both the new stateless path and the older initialize-based path with the exact clients you support.

Should every MCP server become stateless?

Remote transport should be stateless by default when the workload allows it. Opt into stateful behavior only for a clearly documented requirement, not because the original sample application happened to use a session.

Conclusion

MCP’s 2026-07-28 revision turns remote tool integration into a more ordinary HTTP deployment problem: requests can be routed, cached, observed, and scaled without transport-level session affinity. The cost is a more explicit application design. Teams must move state into authenticated contracts, model interactive work as resumable round trips, and treat OAuth and cache boundaries as production code.

Start with a staging server, a multi-instance test, and one real tool workflow. Measure discovery, fallback, header validation, MRTR, and authorization before changing the default for every client. That verification-first path captures the scalability benefit without hiding migration risk.

Sources and visual credits

• The 2026-07-28 Specification — Model Context Protocol — primary specification announcement and protocol examples.
• Scaling AI Agent Infrastructure with the MCP Stateless updates — Google Developers Blog — independent production-infrastructure analysis and request examples.
• Announcing v2.0 of the official MCP C# SDK — Microsoft .NET Blog — official SDK migration details.
• MCP C# SDK releases — verified v2.2.0 hybrid serving release notes.
• Figure 1 Mermaid diagram: original editorial illustration by Essa Mamdani, based on the MCP and Google sources above.