Stateless MCP & Your Gateway: How the 2026-07-28 Spec Reshapes Multi-Server Access

The TL;DR

MCP’s 2026-07-28 spec makes requests self-contained, removing the session dependency that previously tied every call to a specific server instance.

• • Sessions Are Gone

  The initialize handshake and Mcp-Session-Id header are removed. Instead, protocol version and client information now travel inside _meta on every request, allowing any compatible server instance to handle the call.

• • Requests Become Portable

  Because each request carries the context it needs, agents, servers, and gateways no longer have to preserve sticky session state just to keep MCP calls working across distributed infrastructure.

• • Better for Multi-Server Routing

  Gateways routing across many MCP servers no longer pay the sticky-session cost for every server behind them. The new model flattens routing complexity and makes multi-server MCP deployments easier to scale.

A single MCP server is easy to reason about. Add a second instance behind a load balancer, and the problem changes.

In the current MCP spec, a request is not fully self-contained. The server creates a session during initialization, then expects later calls to return to the same server instance through the Mcp-Session-Id header. That works until production traffic shifts after a deploy, restart, or scale-up event.

Now imagine Server A creates the session, but Server B receives the next tools/call. Server B has no memory of that session, so the request fails even though both servers are healthy. The issue is not the tool, the client, or the load balancer. It is the session model itself.

The next spec, dated 2026-07-28, deletes that mechanism outright. It’s a release candidate as of this writing, locked on May 21, 2026, with final publication scheduled for July 28, 2026, and the practical result touches anyone routing calls across more than one MCP server.

Here’s what changes, why it matters, and what you should check before the spec becomes final.

Why MCP Is Removing Sessions in the 2026 Release

MCP wasn’t designed stateless. The MCP Transport Working Group laid out the reasoning behind changing that in December 2025, and it comes down to four recurring problems teams hit once they moved MCP servers into production:

• Load balancers and gateways had to parse full JSON-RPC bodies to know where a request belonged, instead of routing on ordinary HTTP patterns.
• Stateful connections forced sticky routing, which blocks clean autoscaling.
• Developers building small, short-lived tools ended up managing session storage anyway, just to support basic back-and-forth calls.
• There was no predictable way to say where a conversation’s scope started and ended once a system spanned more than one server.

Each of those gets worse the more MCP servers you’re coordinating. A team running a single local MCP server barely notices session friction. A setup that routes across a dozen or three dozen independent MCP servers feels it on every one of them, because each server keeps its own session state and its own instance affinity. Connection issues that trace back to configuration and session mismatches are already a common failure mode at smaller scale. Multiply the number of servers and you multiply the number of places a session can silently break.

What Stateless MCP Means in the 2026-07-28 Release Candidate

Two SEPs do the core work. The initialize/initialized handshake is removed under SEP-2575. Protocol version, client info, and client capabilities, which used to get exchanged once at connection time, now travel inside a _meta object on every request. A new server/discover method lets a client fetch server capabilities up front when it actually needs them, rather than as a mandatory first step.

The Mcp-Session-Id header and the protocol-level session it represented are removed under SEP-2567. Once both are gone, any request can land on any server instance, because nothing about the request depends on which instance handled the previous one.

Here’s the shape of the change in a single request. Before, calling a tool meant a handshake first:

POST /mcp HTTP/1.1
Content-Type: application/json
{"jsonrpc":"2.0","id":1,"method":"initialize",
 "params":{"protocolVersion":"2025-11-25","capabilities":{},
           "clientInfo":{"name":"my-agent","version":"1.0"}}}

followed by every later call carrying the session ID the server issued in response. In 2026-07-28, the equivalent call is one self-contained request:

POST /mcp HTTP/1.1
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: list_repos
Content-Type: application/json
{"jsonrpc":"2.0","id":1,"method":"tools/call",
 "params":{"name":"list_repos","arguments":{"org":"acme"},
           "_meta":{"io.modelcontextprotocol/clientInfo":{"name":"my-agent","version":"1.0"}}}}

How Stateless MCP Routes Requests Without Sessions

Removing the session reshapes how a gateway operates day to day, across four distinct changes.

Request Routing Without Parsing the HTTP Body

Streamable HTTP requests now require Mcp-Method and Mcp-Name headers under SEP-2243, so a load balancer or gateway can route, rate-limit, and log based on the operation being called without opening and parsing the request body, the same pattern conventional HTTP APIs have used for years. Servers reject requests where the headers and body disagree, which gives that routing layer a built-in integrity check.

New Response Caching in MCP

List and resource-read results now carry ttlMs and cacheScope fields under SEP-2549, modeled on HTTP’s Cache-Control pattern. A client, or a gateway sitting in front of several servers, can know exactly how long a tools/list response stays fresh and whether it’s safe to share across users, instead of relying on a long-lived event stream just to learn that a list changed.

Mid-Call Prompts in Stateless MCP

Server-to-client requests, the mid-call prompts a server sometimes needs, got rebuilt for a world with no persistent connection. Server-initiated requests may now only happen while the server is actively processing a client request (SEP-2260, previously just a recommendation). The Multi Round-Trip Requests pattern (SEP-2322) replaces a held-open stream with a returned InputRequiredResult object containing an inputRequests payload and an opaque requestState string. The client collects the answer and reissues the original call with that state attached, so any server instance, not just the one that first asked, can pick up the retry.

Managing State with Explicit Handles

None of this means your application has to give up state entirely. A server that needs to track something across calls, a shopping cart, a browser session, a batch job, mints an explicit handle from a tool call (a cart_id, a job_id) and the model passes that handle back as an ordinary argument on the next call. The state still exists. It’s just visible to the model and stored wherever the server chooses, rather than hidden inside transport-layer session metadata.

That pattern still carries risk. It just relocates it. A handle is only as safe as the scoping, validation, and expiry the tool author builds around it. An unscoped cart_id that never expires and grants whatever the original session granted is a bearer token wearing a friendlier name. Moving state out of the transport layer doesn’t fix that by itself. Whoever writes the tool still has to.

What the Stateless MCP Update Means for MCP Gateways

This is where the change moves from a transport detail to an operations decision.

A gateway built to unify access to many MCP servers has effectively been managing the session problem described above, at multiplied scale. Picture one integration point routing calls out to dozens of separate services instead of a client connecting to each one directly.

Consider MCP360’s unified gateway. It sits in front of dozens of MCP servers and 100-plus tools behind a single API key, exposing search and execute meta-tools so an agent can discover and call any of them without a separate connection per service.

Every one of those underlying servers has historically carried its own session lifecycle. A stateless request format changes that. The routing layer no longer has to reconcile those lifecycles against each other, or guarantee that a follow-up call lands on the same backend instance that handled the first one.

Practically, that shows up as fewer places for a multi-server setup to break silently. A gateway can now:

• Route purely on the Mcp-Method and Mcp-Name headers
• Apply the same caching rules across every connected server via ttlMs
• Scale the number of connected servers without redesigning session handling for each new one added to the catalog

That’s the same principle that makes production multi-agent workflows tractable at scale. The complexity that used to grow with every new server in the catalog now grows much more slowly. The transport contract is identical no matter how many servers sit behind it.

MCP 2026 Security and Authorization Changes

MCP’s deployment pattern is unusual in a specific way: one client often talks to many independently operated servers, each with its own authorization server. That pattern is exactly where a class of OAuth mix-up attack becomes more likely, and six SEPs in this release exist to close that gap.

The stakes here aren’t hypothetical. The NSA’s Artificial Intelligence Security Center called out weak token and session lifecycle handling by name in a Cybersecurity Information Sheet published May 20, 2026, warning that gaps in this area can lead to session hijacking, message replay, and unauthorized reuse of valid sessions against production MCP deployments. Six SEPs in this release work directly against that category of risk.

• Issuer validation: Clients must validate the iss parameter on authorization responses per RFC 9207 (SEP-2468). It’s a low-cost check today, but a future spec version is expected to require rejecting responses that omit it, so authorization servers should start supplying it now.
• Client type declaration: Clients declare their OpenID Connect application_type during Dynamic Client Registration (SEP-837). This avoids the common failure where a desktop or CLI client gets defaulted to "web" and has its localhost redirect URI rejected.
• Credential binding: Registered credentials get bound to the issuing authorization server, with re-registration required if a resource migrates between authorization servers (SEP-2352).
• Refresh tokens: The spec documents refresh token requests against OpenID Connect-style servers (SEP-2207).
• Scope accumulation: Step-up authorization now has clarified rules for how scopes accumulate across requests (SEP-2350).
• Discovery suffix: The .well-known discovery suffix is standardized (SEP-2351).

None of this depends on whether you adopt the stateless core on day one. If you’re running MCP servers behind any kind of gateway or auth boundary, this is the section worth reading closely regardless of your migration timeline. It’s also deep enough to earn its own dedicated walkthrough, which is coming in a follow-up piece.

Extensions, MCP Apps, and What Else Ships July 28

Statelessness is the headline, but three other structural changes ship in the same release: extensions, schema updates, and a new deprecation policy.

Official MCP Extensions

SEP-2133 formalizes Extensions: capabilities identified by reverse-DNS IDs, negotiated through an extensions capability map, and versioned independently in their own repositories with their own maintainers. Two ship as official at launch.

• MCP Apps: Lets a server render an interactive HTML interface inside a sandboxed iframe. Every UI action still routes through the same JSON-RPC audit path as a direct tool call.
• Tasks: Experimental in 2025-11-25, now gets a lifecycle built for the stateless model. A tools/call can return a task handle, and the client drives it with tasks/get, tasks/update, and tasks/cancel. tasks/list is gone entirely, since there’s no session left to scope it to.

Schema and Error Code Updates

Tool schemas move to full JSON Schema 2020-12 under SEP-2106, adding composition keywords like oneOf, anyOf, and allOf, plus $ref/$defs references. Input schemas keep their object-root constraint. Output schemas are unrestricted.

Separately, SEP-2164 changes the error code for a missing resource from MCP’s custom -32002 to the standard JSON-RPC -32602. Check for that literal value if any client code matches on it today.

Deprecated Features in MCP 2026

SEP-2577 deprecates three original capabilities. SEP-2596, the new formal lifecycle policy, guarantees at least twelve months between deprecation and the earliest possible removal:

All three keep working in this release, and in every spec version published within that year-long window. None of this needs to happen before July 28.

Apps and Tasks raise governance questions the spec text doesn’t answer, particularly for teams running them behind a shared gateway instead of a single self-hosted server. We’ll cover that separately.

MCP 2026 Migration Checklist Before July 28

How urgent this is depends entirely on where you sit relative to the servers themselves.

The ten-week validation window opened May 21, 2026. Here’s what to do before it closes, based on where you sit:

1. Find every place your server reads or stores state tied to Mcp-Session-Id. Replace it with an explicit handle passed back as a tool argument, and move the actual state into whatever store makes sense for your domain.
   
2. Deploy behind a plain round-robin load balancer with no sticky routing and run your full test suite. Anything that fails has a hidden session dependency you haven’t found yet.
   
3. Start sending and validating Mcp-Method and Mcp-Name headers on your Streamable HTTP traffic, since gateways and rate-limiters will increasingly route on them.
   
4. Emit ttlMs and cacheScope on tools/list and resource-read responses so clients can cache safely instead of re-polling.
   
5. Confirm your authorization server supplies the iss parameter on authorization responses ahead of it becoming a hard requirement.
   
6. Pin your SDK version explicitly. For the Python SDK, that means a constraint like mcp>=1.27,<2 until you deliberately opt into a 2.0.0 pre-release. Pre-release builds carry breaking changes between releases, and stable v2 ships alongside the final spec on July 28, 2026.
   
7. If you’re on a unified gateway instead of hosting servers yourself, ask your provider for their timeline on the new headers and caching fields. MCP360, for example, absorbs the transport-layer migration for you, but confirm rather than assume.

Frequently Asked Questions

Conclusion

Statelessness relocates the need for good state design somewhere you can actually see it, and a handle the model can reason about does the job a hidden session used to do less reliably. For anyone running a single MCP server, that’s a welcome simplification. For anyone routing calls across a whole catalog of them, three internal servers or three hundred, it’s the difference between session management multiplying with every server you add and staying flat no matter how many sit behind the routing layer.

Don’t wait for July 28 to find out which one you are. The ten-week validation window exists because the maintainers expect real deployments to surface problems the design review didn’t catch, and a gateway routing to three dozen servers is exactly the kind of deployment that will find them first. Test it now, while there’s still time to file an issue instead of a workaround.

If you’re running your own MCP servers, start with the readiness checklist above, then cross-check it against our guide to fixing MCP server connection issues for the kinds of failures sticky sessions used to hide.