The 2026-07-28 version of the Model Context Protocol turns MCP from a stateful, session-based protocol into a stateless request-and-response one. There’s no more initialize handshake and no Mcp-Session-Id, and every request carries what the server needs to know. For people running MCP servers, that means plain load balancing and routing on HTTP headers. For people securing them, it means gateways can authorize per tool, OAuth gets harder to confuse, and some features are on a twelve-month path out. It’s also a breaking change, so here’s what moves, what breaks and what to check.
What “stateless” means here
In earlier versions, a client opened a session with a handshake and the server kept per-session state. The official release post says the new version retires “the initialize / initialized exchange along with the Mcp-Session-Id header.” Each request now travels on its own, carrying its protocol version, client identity and client capabilities in a _meta field. A new server/discover call lets a client ask for a server’s capabilities up front, but it’s optional.
The practical effect, in the maintainers’ words: “any request can land on any instance behind a plain round-robin load balancer,” with no shared session storage. That’s why cloud providers and hosting platforms lined up behind this release.
Stateless doesn’t mean your tools can’t remember anything. The maintainers suggest that if a server needs state across calls, it should “mint an explicit handle from a tool and have the model pass it back as an argument.” They say this works better than hidden session state, because the model can see the handle and pass it between tools.
The changes that matter most
| Change | What it does | Who should care |
|---|---|---|
| No handshake or sessions | Every request is self-describing; optional server/discover |
Anyone who stored state against a session ID |
Mcp-Method and Mcp-Name headers |
Required on Streamable HTTP requests, so gateways see the method and tool name without parsing the body | Gateway, WAF and rate-limiter operators |
| Multi Round-Trip Requests (MRTR) | A server asks for user input mid-call by returning input_required; the client retries with the answers |
Servers that use elicitation, such as confirmations |
| Cacheable lists | List responses carry ttlMs and cacheScope and a deterministic order |
Clients that re-fetch tool catalogs |
| Authorization hardening | RFC 9207 issuer validation; credentials bound to their issuer; Dynamic Client Registration deprecated | Anyone implementing OAuth for MCP |
| Extensions framework | Tasks move out of the core into an extension, alongside MCP Apps and Enterprise-Managed Authorization | Long-running and enterprise workflows |
| Deprecations | Roots, Sampling and Logging deprecated; legacy HTTP+SSE transport deprecated | Older servers and clients |
What gets safer
Gateways can authorize per tool
Because the method and tool name now travel in headers, a gateway, rate limiter or web application firewall can “route and meter on those headers instead of parsing JSON bodies.” For security, that means you can allow, block or rate-limit specific tools at the edge, rather than all-or-nothing on an MCP endpoint. When LiteLLM’s MCP authentication bypass was under active exploitation, its official workaround was to block /mcp/ routes entirely, as we covered in our LiteLLM analysis. Header-level routing gives operators finer options than that.
OAuth mix-ups are closed off
The release post says authorization is “where implementers spend most of their integration time,” and it tightens three things:
- Authorization servers should return an
issparameter per RFC 9207, and clients must validate it before redeeming a code. That “closes an authorization-server mix-up hole,” where a client could be tricked into sending a code to the wrong server. - Client credentials are bound to the issuer that minted them, with no reuse across authorization servers.
- Dynamic Client Registration is formally deprecated in favor of Client ID Metadata Documents (CIMD). It keeps working for now, but will be removed in a future version.
Fewer long-lived connections
MRTR removes the need to keep a bidirectional stream open so a server can ask the user something mid-call. Supabase, quoted in the release, says this lets its stateless server confirm with the user before an action, “like the cost of a new project before it’s created, or a query that would delete data.”
What needs care
- State handles are model-controlled input. If your tools now pass explicit handles through the model, treat every handle that comes back as untrusted: check that it exists, belongs to the calling user, and hasn’t expired. This is our reading, not a spec requirement. It’s the same rule as in the Semantic Kernel vulnerabilities: any argument the model fills in can be shaped by injected content.
- Header routing only helps if headers and body agree. The spec covers this: under SEP-2243, servers “MUST reject requests where the values specified in the headers do not match the values in the request body,” so a gateway can’t approve one tool while the server runs another. Make sure your server or SDK actually enforces it, and put header-based policies on a gateway you control.
- Breaking changes are real. The maintainers warn of “some migration cost, especially for developers that did depend on session identifiers.”
Migration checklist
- Update your SDK. The TypeScript, Python, Go and C# SDKs support 2026-07-28; the Rust SDK has beta support.
- Find anything keyed on session IDs and move it to explicit handles or your own storage.
- Replace server-initiated requests (elicitation, sampling, roots) with the MRTR pattern.
- Move OAuth clients to CIMD, and make sure clients validate the
issparameter. - Update gateway rules to use
Mcp-MethodandMcp-Name, ideally with per-tool policies. - Plan for deprecations. Roots, Sampling, Logging and HTTP+SSE keep working for at least twelve months under the new deprecation policy, but new code shouldn’t adopt them.
If you’re still deciding whether MCP is the right integration layer at all, start with our comparison of MCP, APIs and computer use. This release doesn’t change that decision, but it makes MCP much easier to run like any other HTTP service.
MCP release post and specification checked on October 16, 2026.
