The Model Context Protocol publishes its 2026-07-28 revision today, and the headline for anyone who operates a remote MCP server is that the protocol no longer has sessions. The initialize handshake is gone, the Mcp-Session-Id header is gone, and the version and capability information that used to be exchanged once at connection time now rides along in _meta on every request. That single decision is what removes sticky routing from the deployment picture. The same revision brings MCP Apps and a rebuilt Tasks extension, six authorization proposals, and the protocol's first formal deprecation policy, which puts Roots, Sampling and Logging on a twelve month clock.
The short answer
The Model Context Protocol revision dated 2026-07-28 publishes today, replacing 2025-11-25 as the current version. It removes the initialize handshake and the Mcp-Session-Id header, moves protocol version and capabilities into _meta on every request, and requires Mcp-Method and Mcp-Name headers on the Streamable HTTP transport so gateways can route without parsing bodies. List responses gain ttlMs and cacheScope. MCP Apps arrives as the first official extension, Tasks is rebuilt around handles rather than session bound objects, and a formal feature lifecycle gives every deprecation a twelve month floor.
Most protocol revisions add things. This one is mainly interesting for what it takes away, and the thing it takes away is the session.
The handshake is gone
Under 2025-11-25, an MCP client opened a connection, sent initialize, received the server's capabilities, sent initialized, and only then got on with the work. The server handed back an Mcp-Session-Id, and every subsequent request carried it. That is a perfectly normal design, and it is the design that made horizontal scaling awkward, because a request carrying a session id has to reach the instance that knows about that session.
In the 2026-07-28 revision the handshake does not exist. Protocol version, client information and capabilities travel in _meta on every request. There is no session id header and no protocol level session at all.
The consequence is stated plainly in the specification announcement: any request can land on any server instance. Round robin is enough. The shared session store that a horizontally deployed server needed in order to survive a request hitting the wrong replica has nothing left to store.
We would put this in the category of changes that look small in a diff and rearrange an entire deployment diagram.
What the transport now requires
Two headers become mandatory on the Streamable HTTP transport: Mcp-Method and Mcp-Name. They carry the operation being invoked, which means a load balancer, a gateway or a rate limiter can route and count on the operation without opening the request body. Servers must reject requests where the headers contradict the body, so the header cannot be used to smuggle one operation past a rule written for another.
List responses and resource reads pick up ttlMs and cacheScope, borrowed fairly directly from HTTP's Cache-Control thinking. A client knows how long a tools/list response stays valid and whether it may be shared across users. Holding a Server Sent Events stream open just to hear that a list changed stops being necessary.
Put together, these three details describe an MCP server that behaves like an ordinary HTTP service. That is the whole argument of the revision, and it is why the project called it the largest change since launch.
MCP Apps and the new Tasks
Two extensions ship alongside the core. MCP Apps is the first official one, and it lets a server render interactive HTML in a sandboxed iframe on the client side. Tools declare their UI templates up front, which allows a client to prefetch them and a security reviewer to look at them before anything renders. Every action a user takes in that interface goes back through normal JSON-RPC, so the consent and audit path is the same one a direct tool call follows. No side channel.
Tasks was reworked for a world without sessions. A server answers tools/call with a task handle, and the client drives the work with tasks/get, tasks/update and tasks/cancel. Task creation is server directed, based on the capability the client advertised. One casualty is tasks/list, removed because listing tasks needs a scope to list within and sessions were the scope. Anyone using the experimental Tasks API from 2025-11-25 has migration work here, and it is the sharpest edge in the revision.
The deprecation policy is the quiet win
For the first time MCP has a written feature lifecycle: Active, Deprecated, Removed, with at least twelve months between the second and the third. Deprecation starts as an annotation, and the method keeps working.
Three features enter it immediately. Roots gives way to tool parameters or configuration. Sampling gives way to talking to an LLM provider directly. Logging gives way to stderr for stdio servers and OpenTelemetry for structured observability.
There is a version of this news that reads as churn. We read it the other way. A protocol that grew this fast needed a way to shed the parts that duplicated the ecosystem around it, and writing the removal rules down before using them is the difference between evolution and breakage.
What to check this week
Start with state. Anything your server keeps against a session id needs a new home, either inside the request or in storage you key yourself. Then look at what your deployment no longer needs: sticky configuration on the load balancer, the shared session store, gateway rules that read bodies to work out which method is being called.
Check your SDK before you write code. The release candidate locked on May twenty first and today is the publication date, a ten week window scoped so that Tier 1 SDKs could validate against real workloads and ship support. Beta SDKs landed on June twenty ninth. At the time we wrote this, the specification's own versioning page still listed 2025-11-25 as current, which is the sort of thing that flips within hours of a publication date rather than before it.
Sources and further reading
- The 2026-07-28 MCP specification release candidate
- Model Context Protocol blog
- MCP versioning and revision status
- Feature lifecycle and deprecation policy
- Microsoft's MCP for beginners notes on the 2026-07-28 release candidate
Frequently asked questions
Does removing sessions break servers written against 2025-11-25?
It changes how they are written, which is not the same as breaking them overnight. Version negotiation still exists, so a server can support both revisions while clients catch up, and the deprecated features stay in the specification with a twelve month floor before they become eligible for removal. What genuinely has to be rewritten is anything that kept per connection state between the initialize call and later requests, because that anchor no longer exists. If your server stored a user identity, a working directory or a set of enabled tools against a session id, that state has to move into the request itself or into your own storage keyed by something you control.
What do Mcp-Method and Mcp-Name actually buy an operator?
Routing and rate limiting without reading request bodies. Before, a gateway that wanted to treat tools/call differently from tools/list had to parse the JSON-RPC payload to find out which one it was looking at, which is expensive at the edge and unpleasant to write. The new revision requires both headers on the Streamable HTTP transport, so nginx, Envoy or an API gateway can match on a header the way it does for any other HTTP service. Servers are required to reject requests where the headers disagree with the body, which is what stops the header from becoming a lie a client can tell.
What replaces the persistent SSE stream for list changes?
Cache metadata. List responses and resource reads now carry ttlMs and cacheScope, modelled on HTTP Cache-Control. A client caches tools/list for as long as the server says it may, and cacheScope tells it whether that response is shareable across users or specific to one. The practical effect is that a client no longer needs to hold a long lived stream open purely to be told that a list changed, which is the single most annoying thing about running MCP behind infrastructure that has opinions about idle connections.
Why deprecate Sampling and Logging?
Both were places where MCP had grown a second version of something the surrounding ecosystem already does well. Sampling asked the client to run an inference on the server's behalf, and the guidance now is to integrate with an LLM provider directly instead. Logging is replaced by stderr for stdio servers and by OpenTelemetry for anything that wants structured observability, which is what most operators were already piping their MCP servers into. Roots goes too, with tool parameters or configuration taking its place. In all three cases the replacement is boring and already in your stack, which is the point.
What should I do first if I run an MCP server in production?
Inventory your state. Write down every piece of information your server currently associates with a session, then decide for each one whether it belongs in the request, in a token, or in a store you own. After that, check whether your deployment still needs the pieces it was built around: the shared session store, the sticky load balancer configuration and any gateway rule that inspects bodies can usually go, and removing them is where the operational win actually shows up. Tier 1 SDK support was scoped to arrive inside the ten week window between the release candidate lock on May twenty first and today, so check your SDK's release notes before you start.