# MCP 2026-07-28: a stateless core

> The Model Context Protocol release published on 28 July 2026 makes the protocol stateless. The initialize handshake and protocol-level sessions are gone, every request carries its own version and capabilities, and HTTP requests must include Mcp-Method and Mcp-Name headers. For companies that already connect agents to internal systems through MCP, that means gateway rules, scaling changes and a re-test plan.

URL: https://corrplus.net/blog/mcp-2026-stateless-specification/
Updated: 2026-11-13
Corrplus Team

## Is the MCP 2026-07-28 release final?

Yes. The [Model Context Protocol](/glossary/model-context-protocol/) project published a release candidate on GitHub, "2026-07-28 RC", on 29 May, and the final release on 28 July 2026. The project blog announces it as the stable, generally available revision. The two-step timeline makes it easy to confuse the RC with the final text. As of November 2026, the text to build against is the 2026-07-28 version on the specification site.

The blog sums up the change in one line: MCP moves from a bidirectional, stateful protocol to a request/response, stateless one. It also says plainly that there is some migration cost, especially for developers who relied on session identifiers.

What MCP gives an agent does not change: tools, resources and prompts. The principles in our post on [MCP for AI agents](/blog/mcp-ai-agent-integration/), namely least privilege, no token passthrough, human approval and a step-by-step audit log, all still apply. What changes is how that traffic travels over the network and how you govern it.

## What does "stateless" actually mean here?

In earlier revisions the client opened with an `initialize` handshake, negotiated version and capabilities once, and over HTTP the server could assign an `Mcp-Session-Id`. Every later request belonged to that session. In 2026-07-28:

- **No handshake.** Every request carries its protocol version and client capabilities in its own `_meta` field. Over HTTP an `MCP-Protocol-Version` header is also required and must match the body.
- **No sessions.** The `Mcp-Session-Id` header is gone. A server that needs state across calls returns an explicit handle from one of its tools, and the model passes it back as an ordinary tool argument.
- **Discovery is its own call.** Servers must implement `server/discover`, which advertises supported versions and capabilities. Clients may call it first.
- **Server-to-client requests are redesigned.** When a server needs input from the user or a model completion, it no longer sends its own request. It returns an "input required" result, and the client retries the original request with the answers attached. The specification calls this Multi Round-Trip Requests (MRTR).
- **Broken streams do not resume.** SSE resumability is removed. If a connection drops, the in-flight request is lost and the client must send it again with a new request ID.

The business consequence is mostly about scaling. Without sessions it no longer matters which server instance handles a request, so you can drop sticky sessions on the load balancer and the session store behind them. Servers become easier to scale horizontally, run on serverless platforms and restart.

## Why do the Mcp-Method and Mcp-Name headers matter for gateways?

Every Streamable HTTP request must carry an `Mcp-Method` header (for example `tools/call`), and tool calls, resource reads and prompt requests must also carry `Mcp-Name` (the tool name or resource URI). The specification states the purpose: so that load balancers, gateways and observability tools can route and inspect requests without parsing the JSON body.

In practice that enables:

- **Per-tool authorisation.** A gateway can allow a request with `Mcp-Name: cancel_order` only for certain roles.
- **Per-tool rate limits and cost metering.** Calls per tool can be counted without opening the body.
- **Routing.** Different tools can go to different back-end services.

Servers can also mark specific tool parameters, such as region or tenant, to be mirrored into `Mcp-Param-*` headers. The rule that matters for security: a server that processes the body must reject the request with a 400 and a `HeaderMismatch` error if headers and body disagree. That stops a gateway deciding on the header while the server acts on a different body. The specification also advises intermediaries that enforce policy on these headers to reject requests whose version header is old or missing, because older versions do not include that validation.

## Which features are being deprecated?

| Feature | Status | Suggested path |
|---|---|---|
| Roots | Deprecated | Pass directories or files as tool parameters, resource URIs or server configuration |
| Sampling | Deprecated | Call the model provider's API directly |
| Logging | Deprecated | Write to stderr on stdio, or use OpenTelemetry |
| Legacy HTTP+SSE transport | Deprecated | Move to Streamable HTTP |
| Dynamic Client Registration | Deprecated | Client ID Metadata Documents (CIMD) |
| Tasks | Moved out of the core | Optional `io.modelcontextprotocol/tasks` extension |

Deprecated features keep working. The lifecycle policy introduced with this release sets a minimum twelve-month deprecation window before anything is removed. Tasks, used for long-running work, now live in an official extension built on polling.

Authorisation is tightened too: clients must validate the `iss` value returned by the authorisation server before redeeming a code, and must bind stored client credentials to the authorisation server that issued them. List responses such as `tools/list` now carry caching hints, and servers should return tools in a stable order. Conventions for carrying OpenTelemetry trace context are defined as well, which makes it easier to connect agent calls to the observability stack you already run.

## Do cloud platforms support the new version?

The project blog says the TypeScript, Python, Go and C# SDKs support 2026-07-28, with beta support in the Rust SDK. On release day AWS confirmed that AgentCore Gateway supports the new version. It is opt-in: you update the gateway's list of supported versions with `UpdateGateway`. AWS points out two details: the call replaces the list rather than appending to it, so you need to include the older version in what you send; and only clients that request 2026-07-28 get the new behaviour, while existing clients carry on unchanged.

Other platforms and packaged agent products move on their own schedules. If you use a packaged platform such as Copilot Studio, check its documentation for the MCP version it supports. For the broader build-or-buy question, see [Copilot Studio vs a custom AI agent](/blog/copilot-studio-vs-custom-ai-agent/).

## What should a company with MCP agents in production re-test?

A migration checklist:

1. **Take inventory.** Which MCP servers do you run, which version do they speak, and which clients and [AI agents](/glossary/ai-agent/) connect to them?
2. **Find session dependencies.** Move servers that keep a basket, draft document or user context against the session ID to the explicit handle model.
3. **Make write tools safe to retry.** A dropped stream means a resent request. Add idempotency keys or duplicate checks to tools that take payments, create orders or create records.
4. **Update the gateway.** Write per-tool authorisation, rate-limit and logging rules on `Mcp-Method` and `Mcp-Name`, and do not trust those headers on older-version traffic.
5. **Keep authorisation on the server.** The gateway is the first line of defence, not the only one. The server should still check, on every call, that the token was issued for it and that the user may use that tool.
6. **Migrate deprecated features.** OpenTelemetry instead of Logging, direct model APIs instead of Sampling.
7. **Check the audit log.** Is every tool call logged with on whose behalf, which tool, which parameters, the result and who approved it? With sessions gone, you need a trace ID that travels with each request.
8. **Test both versions together.** During the transition, confirm that old and new clients work correctly against the same server or gateway.

## Where to start

1. List your MCP servers and clients with the protocol version each one speaks.
2. Flag servers that depend on session IDs or deprecated features.
3. Move one read-only server to the new version first and trial your gateway rules on it.
4. Migrate write tools once idempotency and logging rules are in place.

This order works well at [technology and software](/industries/technology-software/) companies, where internal tooling multiplies quickly; when several teams share the same MCP servers, gateway rules give them a common language.

At Corrplus we start an MCP migration with an inventory of servers and tools, write down a risk class and an authorisation rule for each tool, then move and test servers in short cycles. For the agent itself see [AI agent development](/services/ai-agent-development/), and for the model and API layer see [LLM integration](/services/llm-integration/). If you would like a second pair of eyes on your current agent architecture, the [AI discovery sprint](/ai-discovery-sprint/) is a good place to begin.

## Frequently asked questions

### Is MCP 2026-07-28 final or still a release candidate?

It is final. The release candidate was published on 29 May and the final release on 28 July 2026. If you come across a write-up that refers to the RC, build against the 2026-07-28 text on the specification site.

### Will our existing MCP servers stop working?

Not overnight. Clients pick a protocol version on every request, so servers and gateways that keep supporting the older version continue to serve older clients. But a client on the new version does not send initialize or expect a session ID, so servers that depend on sessions need changes.

### How do the Mcp-Method and Mcp-Name headers affect security?

A gateway can see which method and which tool is being called without opening the request body, which makes per-tool authorisation and rate limits easier. The specification requires servers to reject a request when the headers and the body disagree. Still, keep the final authorisation check on the server.

### When will the deprecated features be removed?

Roots, Sampling and Logging are deprecated but still work. The new lifecycle policy sets a minimum twelve-month deprecation window before removal. Do not use them in new work, and plan the migration of existing use.

## Sources

- [MCP Blog, The 2026-07-28 MCP specification](https://blog.modelcontextprotocol.io/posts/2026-07-28/)
- [Model Context Protocol, Specification 2026-07-28: Key Changes](https://modelcontextprotocol.io/specification/2026-07-28/changelog)
- [Model Context Protocol, Transports: Streamable HTTP (2026-07-28)](https://modelcontextprotocol.io/specification/2026-07-28/basic/transports/streamable-http)
- [GitHub, modelcontextprotocol releases (2026-07-28 and 2026-07-28 RC)](https://github.com/modelcontextprotocol/modelcontextprotocol/releases)
- [AWS Machine Learning Blog, How AgentCore Gateway supports the MCP 2026-07-28 spec](https://aws.amazon.com/blogs/machine-learning/how-agentcore-gateway-supports-the-mcp-2026-07-28-spec/)