The new stateless MCP spec: what changed and why it matters

The MCP specification released on 28 July 2026 makes the protocol stateless at its core. It removes the initialise handshake and the Mcp-Session-Id header, so every request carries its own protocol version, client details and capabilities. Any server instance can handle any request behind an ordinary load balancer. The revision also adds routing headers, cacheable tool lists, multi-round-trip requests for approvals, a formal extensions framework, stronger authorisation, and deprecates roots, sampling, logging and the old HTTP+SSE transport.

What is the 2026-07-28 MCP specification?

The Model Context Protocol lets AI applications connect to tools and data; our beginner’s guide to MCP covers the basics. On 28 July 2026 the maintainers published a major revision, named by its date. The release candidate was locked on 21 May 2026, and official SDKs for Python, TypeScript, Go and C# shipped beta support beforehand. The maintainers describe it as the biggest revision since MCP launched, according to the MCP blog.

What does “stateless” mean here?

Stateless does not mean your application has no state. It means state is explicit: if a workflow needs to remember something, such as a deployment ID, it passes it in the request rather than relying on a hidden transport session. This is how ordinary web APIs already work, and it is why Google, Microsoft and others have welcomed the change for cloud and serverless deployments, as the Google Developers Blog explains.

What else changed?

Routing headers: Requests carry headers such as Mcp-Method and Mcp-Name, so gateways can route, meter and authorise without reading the body.
Cacheable listings: Tool and resource lists include a time-to-live, so clients can reuse catalogues instead of fetching them each time.
Multi-round-trip requests: A tool can ask the user to approve a step, such as deleting data, and the client re-issues the call with the answer.
Extensions framework: MCP Apps and Tasks for long-running work are now formal extensions.
Stronger authorisation: OAuth handling hardened; dynamic client registration deprecated in favour of client ID metadata documents.
JSON Schema 2020-12: Tools can use full modern JSON Schema for inputs.

What has been deprecated?

Roots, which let clients indicate relevant file locations
Sampling, which let a server ask the client’s model for a completion
Logging as a protocol feature
The legacy HTTP+SSE transport

Deprecated features have at least a 12-month removal window, and clients that speak the new revision can fall back to the old handshake for older servers, so migration can be gradual.

What does it mean for businesses?

For most business users, nothing visible changes: assistants and directory connectors are updated by their providers. Teams that run their own MCP servers should plan an upgrade, because the new model makes servers cheaper to scale and easier to secure behind standard infrastructure. Our guide to building an MCP server covers the basics.

How should teams migrate?

Inventory your servers: List every MCP server you run, its SDK version and who uses it.
Upgrade SDKs: Move to SDK versions that support 2026-07-28; several answer both revisions from one endpoint.
Make state explicit: Replace anything that depended on the session with explicit IDs passed in requests.
Replace deprecated features: Move off sampling, roots, logging and HTTP+SSE.
Review security: Validate routing headers against the body, sign and expire any request state, and guard against duplicate side effects on retries.
Test with real clients: Check behaviour in Claude, ChatGPT and your IDEs before switching over.

Security reviewers have noted that the new design changes the attack surface, for example by putting some parameters in headers; our guide to MCP security risks covers what to check.

Why did the maintainers make this change?

As MCP moved from local developer tools to remote servers used by large organisations, sessions became the main obstacle to scale. Pinning each client to one server made load balancing, serverless hosting and failover awkward. Removing sessions lets MCP servers run like any other HTTP service, which brings its request model closer to familiar web APIs and to model APIs such as Anthropic’s Messages API.

How UIUX Studio helps

Our product engineering team builds and migrates MCP servers for internal systems, including authorisation, gateways and testing against major clients.

Frequently asked questions

When was the stateless MCP spec released?

The final 2026-07-28 specification was published on 28 July 2026.

Will my existing MCP server stop working?

Not immediately. Clients can fall back to the older handshake, and deprecated features have at least 12 months before removal.

What is Mcp-Session-Id?

The header that tied a client to one server session; the new spec removes it.

Does stateless mean no memory?

No. Application state still exists; it is passed explicitly rather than held in a transport session.

Do business users need to do anything?

Usually not; providers update their clients and hosted connectors.