Skip to content
FLAVIO COPES
flaviocopes.com

MCP is now stateless: what the 2026-07-28 update changes

By

MCP 2026-07-28 removes protocol sessions, improves HTTP deployment, and adds extensions for interactive apps, long tasks, and enterprise auth.

~~~

The new MCP specification makes every request self-contained.

That sounds like a small protocol detail. It changes how easily we can deploy and scale remote MCP servers.

The MCP 2026-07-28 specification removes the initialization handshake and protocol-level sessions. It also adds better HTTP routing, caching, authorization, long-running tasks, and interactive user interfaces.

This is a big update.

Let’s separate what the protocol now provides from what we still have to build.

Why stateless MCP matters

Previous MCP versions started with an initialize exchange. A remote server could also issue an Mcp-Session-Id that the client sent with later requests.

This made the protocol feel more like a long conversation between one client and one server instance.

That becomes awkward when you have several server instances behind a load balancer. You either route every request from a client to the same instance, or share session state between all instances.

The new protocol removes both the handshake and Mcp-Session-Id.

Every request now includes the information needed to process it:

The server does not need to remember an earlier initialization request. Any available instance can handle the next call.

This makes remote MCP servers a better fit for ordinary HTTP infrastructure. You can place them behind a round-robin load balancer or deploy them to serverless and edge platforms without building protocol session management first.

Stateless does not mean your application has no state

The protocol is stateless. Your application can still be stateful.

Suppose a tool creates a browser session, shopping basket, or deployment job. The tool can return an identifier:

{
  "deploymentId": "deploy_82f1"
}

The model passes that identifier to the next tool call:

{
  "deploymentId": "deploy_82f1"
}

The state still exists. It is now explicit instead of hidden inside the MCP transport session.

This is the same idea used by regular web APIs. HTTP is stateless, but the applications built on HTTP are not.

Stateless MCP also does not give you infinite scaling automatically. Your database, authentication system, rate limits, and tool implementation still have to scale.

It removes one important source of infrastructure complexity.

MCP requests are easier to route and cache

The new version adds Mcp-Method and Mcp-Name HTTP headers.

For a tool call, they might look like this:

Mcp-Method: tools/call
Mcp-Name: search

A gateway can now route, authorize, meter, or rate-limit requests using headers. It no longer needs to inspect the JSON-RPC request body first.

List responses can also include cache instructions. Calls such as tools/list and resources/list return a time-to-live and cache scope.

Clients can reuse a tool catalog instead of fetching it again on every connection. A stable tool order also helps preserve prompt caches.

Multi Round-Trip Requests replace open connections

A stateless server sometimes needs more information before finishing a tool call.

For example, a deployment tool might need the user to approve its estimated cost.

The new Multi Round-Trip Request flow lets the server return input_required. The client asks the user for the missing information, then retries the original request with the answer attached.

This replaces server-initiated requests that depended on a connection being held open.

The useful part is not the name. A stateless tool can now pause for approval or missing input without maintaining a protocol session.

MCP Apps bring interfaces into the conversation

MCP Apps let a server return an interactive HTML interface instead of only text or structured data.

A tool can declare a UI resource for a form, chart, dashboard, document viewer, or other interface. The MCP host renders it inside a sandboxed iframe.

The app stays inside the conversation. It can receive tool results and request new tool calls through a controlled message channel.

This is useful when a series of chat questions would be clumsy. Picking a region, instance size, and scaling configuration is often clearer in one form.

But MCP Apps do not mean every agent can suddenly create and display arbitrary interfaces. Both the server and host must support the extension. The host also controls the sandbox, permissions, and available capabilities.

Tasks support long-running work

Some tools take longer than one HTTP request.

A CI pipeline, video render, data import, or deployment may run for minutes. Holding the original connection open is fragile.

The Tasks extension lets a server return a durable task handle. The client can then:

Tasks are opt-in. The client announces support and the server decides whether a tool call should become a task.

This fits the stateless core because the task state lives behind an explicit handle. The protocol does not depend on the original server connection staying alive.

Enterprise authorization is more practical

The core authorization specification now follows production OAuth 2.0 and OpenID Connect deployments more closely.

The release adds issuer validation, binds client credentials to their authorization server, and starts moving away from Dynamic Client Registration toward Client ID Metadata Documents.

There is also an Enterprise-Managed Authorization extension. It lets an organization manage MCP access through an existing identity provider such as Okta or Microsoft Entra ID.

An administrator can define which MCP servers employees may access. Joining, changing roles, and leaving the company can then follow the organization’s normal identity policies.

Again, this is not automatic SSO for every MCP server. The client, server, authorization service, and identity provider must support the flow.

This is a breaking protocol update

The stateless redesign changes the wire protocol.

The official TypeScript, Python, Go, and C# SDKs support 2026-07-28. Rust support is available in beta. Older clients and servers may continue using earlier protocol versions until both sides can negotiate the new one.

The release also deprecates Roots, Sampling, Logging, and the legacy HTTP+SSE transport. They still work, with a minimum twelve-month deprecation window, but new implementations should use their replacements.

If you maintain an MCP server, read the migration notes for your SDK. Pay particular attention if your code depends on session identifiers or long-lived streams.

If you only use MCP servers through an agent, you do not need to change anything today. Your client and server providers have to add support first. Anthropic says support for the new core is rolling out across Claude products.

What this update really changes

MCP started as a common way for models to call tools and read resources.

This release makes it look more like production application infrastructure:

That is a meaningful shift.

It does not mean one prompt automatically builds a secure SaaS application with working UI, authentication, and operations. We still have to implement those parts.

MCP now gives clients and servers a shared way to connect them.

Read the official release announcement, the 2026-07-28 specification, and the migration guide for the SDK you use before updating a production server.

Tagged: AI · All topics
~~~

Related posts about ai: