The most interesting MCP update this summer removes something.

Since the July 28 specification, Model Context Protocol's HTTP transport no longer requires a protocol-level session. An agent can send a request to an endpoint, get a response, then come back later without the infrastructure having to remember the previous network conversation.

On paper, this is plumbing. In practice, plumbing is often what decides whether a tiny tool stays a local script or can sit comfortably on serverless infrastructure.

Theo Browne, who has spent plenty of time being unimpressed by MCP, gets at the useful part in a recent video. What changed his mind is not another category of tool call. It is that the protocol finally stopped making servers preserve a network relationship many tools never needed in the first place.

A small function used to drag a session behind it

In the previous Streamable HTTP model, a server could create a session identifier. Later requests then had to return with that identifier.

As soon as several instances sit behind a load balancer, an annoying question appears: where does that session live? You either keep routing the client back to the same machine or share state between machines. A tool that takes three parameters and returns JSON has now become a small distributed-systems problem. Apparently the weather was too peaceful.

The 2026-07-28 specification removes that layer. JSON-RPC messages are sent individually as HTTP POST requests to one endpoint. The response can be plain JSON or an SSE stream scoped to that request. The old standalone GET stream endpoint is gone as well.

The server no longer needs an MCP session ID just to understand which network conversation the next request belongs to.

Not a thrilling sentence. A surprisingly useful one.

Stateless does not mean amnesiac

The word "stateless" is dangerous because it invites people to simplify the story until it becomes wrong.

MCP does not prevent an application from keeping state. The official release notes explicitly make that distinction. It is the protocol transport that stops imposing its own session.

A tool that starts a long-running job can still return an explicit handle. The agent keeps that handle in context and sends it back on a later call. The same pattern can work for a task, cart, workflow or any other object that genuinely needs to survive several requests.

That is arguably healthier. If state matters to the application, it becomes visible application data. It no longer hides inside a network relationship every developer has to maintain by default.

Almost boring. Usually a good sign.

Remote MCP starts looking more like an ordinary API

This is where Theo's tone changes completely.

He argues that the old mechanism made scaling and deployment needlessly awkward for many small MCP servers. With the new model, the same endpoint can live much more naturally on Lambda, a Cloudflare Worker or another platform that creates and destroys instances on demand.

That is not because "serverless" is magically better. A server without implicit session state simply requires less coordination between instances.

For a maker, a tiny team or somebody publishing lots of narrow tools, that distinction is practical. A service nobody calls can cost almost nothing to keep around. If one starts getting traffic, more instances can answer without first rebuilding a session layer around it.

Simon Willison, whose work Theo discusses, says the new model finally made some MCP experiments feel worth releasing after earlier attempts. That is a personal experience, not a universal benchmark. It still illustrates the important failure mode: standards are not always rejected because they cannot do the job. Sometimes they are rejected because they demand too much ceremony before the first useful result.

Sometimes a better protocol is one that disappears a little

MCP is still a substantial standard. The July release also changes authorization and formalizes extensions. None of that guarantees that an MCP server is well designed, secure or preferable to a CLI.

Removing sessions from the core transport fixes a more basic problem: developers were paying complexity even when their applications had no use for it.

I find that direction more interesting than another flashy feature. Agents already have plenty of capabilities. What they often lack are interfaces ordinary enough that we can create lots of them without building a tiny cathedral around every button.

A good tools protocol should probably let complexity appear when the actual problem is complex.

For once, the upgrade is less protocol. I can live with that.