The Model Context Protocol - the wire format most agent tools now use to reach external tools and data sources - ships its largest revision since launch on July 28, 2026. The release candidate has been locked since May 21, giving SDK maintainers a ten-week window to catch up, according to the official MCP specification blog. The headline change is not a new feature. It is the removal of the one thing every MCP deployment has depended on since the protocol's first release: the session.
What a stateless core actually removes
Every MCP connection used to start with an initialize handshake that
returned an Mcp-Session-Id header, and every request after that had to
reach the same server instance that issued it. That is gone. Protocol
version, client identity, and capabilities now travel in a _meta field on
every request instead of being negotiated once and pinned to a session. Any
server instance can now answer any request, per the specification blog,
which means a remote MCP deployment that needed sticky routing, a shared
session store, or packet inspection at the load balancer to keep requests on
the right instance no longer needs any of that.
Server-initiated requests - a confirmation prompt mid-task, for example -
had to assume a persistent connection back to the client. They are
restructured too: a server can only issue one while actively handling a
client request, and the client can resume the exchange from any instance
using a requestState payload it echoes back on retry.
Three things are removed outright: the initialize/initialized handshake,
the Mcp-Session-Id header, and the tasks/list method, which the spec blog
says "can't be scoped safely without sessions". A non-standard -32002 error
code for missing resources is replaced with the JSON-RPC standard -32602.
Three features that were part of the core are marked deprecated rather than removed: Roots, Sampling, and Logging. They still work.
The part that is actually new: a deprecation clock
Protocol revisions have shipped breaking changes before. What has not existed until this one is a written commitment about how much notice the next breaking change gets. The spec blog now defines a formal lifecycle - Active, Deprecated, Removed - and guarantees, in its own words, "at least twelve months between deprecation and the earliest possible removal." A conformance suite gates new Standards Track proposals from reaching Final status without going through that lifecycle.
That is the detail worth sitting with if you build against MCP rather than just consume it through a client. A protocol that reserves the right to change anything at any time is a protocol you can only track by reading every release. A protocol that commits to twelve months' notice is one you can plan a migration against - which is a different, better problem to have, even though this particular revision predates the policy that would have given it more runway.
Extensions get the same kind of structure applied going forward: reverse-DNS
identifiers, independent versioning, and their own repositories under the SEP
process, rather than accreting into the core spec. Tasks - previously an
experimental core feature for long-running operations - moves into one of
the first such extensions, redesigned so a server returns a task handle and
the client drives progress with tasks/get, tasks/update, and
tasks/cancel instead of relying on a live connection.
Who this actually disrupts
Coverage from The Register quotes Anthropic's David Soria Parra putting the disruption where it actually lands: "If you built your own implementation, it's going to be a lot of uplift to make this correct." Anyone on an official SDK is expected to absorb the change within the ten-week validation window Tier 1 SDKs get before the July 28 ship date. Anyone who hand-rolled a client or server against the wire format directly inherits the session-removal work themselves, and backward compatibility between the old and new protocol revisions is not guaranteed - a server speaking 2026-07-28 and a client still expecting a session id will not silently interoperate.
Six SEPs also tighten authorization against current OAuth 2.0 and OpenID
Connect practice: iss parameter validation per RFC 9207, an
application_type declaration during dynamic client registration, and
credentials bound to the server that issued them. None of that is optional
hardening bolted on top - it is part of the same revision.
What this has nothing to do with
MCP governs how an agent talks to a tool or data source over the wire. It
says nothing about how the instructions an agent loads - a SKILL.md, a
project's AGENTS.md, a rules file - got onto the machine running that
agent, and it has no equivalent yet of pinning a specific server to a
specific protocol revision the way a lockfile pins a package to a commit.
skillfold's manifest and lockfile resolve and hash skill sources; they say
nothing about MCP servers and do not touch protocol versions at all. If your
agent setup depends on MCP servers, this migration is a client and server
compatibility problem you handle independently of anything a skill manifest
covers, and as of this specification there still isn't a standard way to
declare and reproduce "which MCP protocol revision does this agent's setup
expect" the way you can declare which skill revision it expects. That gap is
worth naming, not papering over with an unrelated tool.
If you maintain an MCP server or client directly rather than through an official SDK, the ten-week window closes soon. If you consume MCP only through a client that tracks the spec, the practical action item this week is confirming which SDK version you are on and whether it has picked up the 2026-07-28 revision yet.