MCP 2026-07-28: the protocol goes stateless and gets ready for the enterprise

On 28 July, the Model Context Protocol got its largest update since it was launched. The new version, named after its date, 2026-07-28, changes how MCP works at the most basic level. The protocol no longer depends on sessions, and that makes it far easier to run MCP servers the way other web services are run.

What changes

MCP becomes stateless. Until now, a client had to open a session with a server through a handshake, and the server had to remember that session. In the new version, every request carries what the server needs, including the client’s identity and capabilities. Any server instance behind a load balancer can therefore answer any request, without sticky sessions or a shared store for session data. Routing information is also placed in HTTP headers, where gateways and load balancers can read it.

Authorisation is tightened. The specification aligns more closely with OAuth 2.1 and OpenID Connect, and requires issuer validation to stop so-called mix-up attacks, where a token from one authorisation server is used against another. A new extension, Enterprise-Managed Authorization, lets IT give access to MCP servers centrally through the company’s identity provider.

Extensions get their own track. Features such as MCP Apps, which let servers show interactive interfaces in chat clients, and Tasks, for long-running jobs, are now extensions that can develop at their own pace outside the core.

Features are deprecated with notice. Sampling, roots, built-in logging, dynamic client registration and the old HTTP with SSE transport are marked as deprecated. A new policy requires at least 12 months of notice before a feature is removed, so nothing will disappear before July 2027.

Why it matters

For integration platforms, statelessness is the key change. An iPaaS that exposes hundreds of integrations as MCP tools needs to scale them like any other API: many instances, automatic restarts and a load balancer in front. With sessions, that was possible but awkward. Den Delimarsky, lead maintainer of the protocol, said to VentureBeat that before, a failed pod meant failed requests, and that this is no longer a problem.

The deprecation policy matters just as much for large companies. A protocol that can change without warning is hard to build on. Twelve months of notice is the kind of promise enterprise architects need before they standardise on something.

What it costs

The change is not free. David Soria Parra from Anthropic, one of the creators of MCP, told The Register that teams who built their own implementation face a lot of work to get it right. Clients and servers also need to support a common version, or one side has to translate. For a while, many companies will run old and new MCP side by side.

What to ask

1. When does your platform support 2026-07-28? Ask your iPaaS and gateway vendors for a date, both for their MCP servers and their MCP gateway.
2. Do you have your own MCP code? Find the MCP servers and clients your teams built themselves, and plan the migration before the old features are removed.
3. Can IT control access centrally? Check whether your identity provider and MCP clients support Enterprise-Managed Authorization.