Today, July 28, 2026, the Model Context Protocol project published its 2026-07-28 specification, the largest single revision since MCP launched. If your team has shipped an MCP server, wired an agent host to one, or built a product around tool calling in the last two years, this release touches you directly. The maintainers are calling it a clean break on purpose: a stateless protocol core, a formal extensions framework, and an authorization model that finally lines up with how OAuth and OpenID Connect actually get deployed in enterprise environments.
The reason to care now rather than next quarter is that this is a breaking release. The request format changed, a core feature moved out of the specification, and one error code changed value. None of it is exotic, but it needs a deliberate migration, and the ten week validation window that started when the release candidate locked on May 21 closes today. Tier 1 SDKs, Python and TypeScript, are expected to have full support ready within that window, which means the tooling to migrate exists even where your own code does not yet reflect it.
Every version of MCP before this one worked the same way underneath. A client connected, called initialize, and the server handed back a session ID that every later request had to carry. That ID only meant something to the server instance that issued it, so any deployment running more than one instance needed sticky routing or a shared session store to keep requests landing in the right place. It is ordinary infrastructure, but it is infrastructure you built purely to work around a limitation in the protocol, not because your product needed it.
The 2026-07-28 spec removes the handshake and the session ID outright. Protocol version, client identity, and capabilities now travel in a _meta field on every request instead of being exchanged once at connection time, and two new headers, Mcp-Method and Mcp-Name, let a gateway or load balancer route traffic without inspecting the request body. The practical result is that any instance of your MCP server can answer any request, so a plain round robin load balancer works out of the box, with no sticky routing and no shared session store to keep consistent.
Removing the protocol session does not mean your server has to be stateless too. The pattern the spec authors converged on is an explicit handle: a tool returns an identifier, a job ID, a basket ID, a draft ID, and the agent passes that same identifier back as an ordinary argument on the next call. The server stores the real state wherever it already stores state, Postgres, Redis, a queue, and the identifier is just a pointer into it. This is arguably a better design than hidden session state, because the model can see the handle, reason about it, and pass it between tools deliberately instead of relying on transport plumbing it has no visibility into.
Extensions existed informally in the previous spec version, but this release gives them a real process. Each extension gets a reverse-DNS identifier, is negotiated through an extensions map that clients and servers advertise to each other, lives in its own repository with its own maintainers, and can version independently of the core specification. Two extensions ship as officially supported in this release, and both are worth understanding even if you are not adopting them immediately.
MCP Apps let a tool declare an interactive HTML interface ahead of time, which the host renders inside a sandboxed iframe rather than the agent describing options in a paragraph of prose. Because the UI template is declared in advance, a host can prefetch it, cache it, and put it through a security review before anything executes. Every action a user takes inside that rendered UI still goes back to the host over the same JSON-RPC channel the rest of MCP uses, so a click inside a calendar widget or a form goes through the same audit and consent path as a direct tool call. Treat this the way you would treat any third-party script rendered on your own product: useful, and worth exactly as much scrutiny as code you did not write yourself.
Tasks shipped as an experimental feature in the previous spec version to handle work that runs longer than a normal request-response cycle. Production use surfaced enough problems with that design that the maintainers pulled it out of the core specification and rebuilt it around the new stateless model. The mechanics now work as a poll rather than a wait: a tool call returns a task handle immediately, and the client drives it forward with tasks/get, tasks/update, or tasks/cancel. Task creation is now server-directed, meaning the client advertises support for the extension and the server decides which calls actually need to run as a task, and tasks/list is gone entirely because it cannot be scoped safely without a session to scope it to. Anyone who built against the old experimental Tasks API has real migration work here, not a drop-in replacement.
Six separate proposals tighten MCP's authorization model to match how OAuth 2.0 and OpenID Connect are deployed in practice, rather than the simplified version MCP originally specified. The one most teams will feel first is that clients must now validate the iss parameter on authorization responses per RFC 9207, a low-cost check that closes a class of mix-up attack that is more likely in MCP's pattern of one client talking to many independent servers. A future spec version is expected to require rejecting responses that omit iss outright, so authorization servers that do not supply it yet should start now.
application_type during dynamic client registration, which fixes the common failure where an authorization server defaults a desktop or CLI client to "web" and then rejects its localhost redirect URI.issuer and are expected to re-register if a resource migrates to a different authorization server.Separately, and shipped just ahead of this release, Enterprise-Managed Authorization gives an organization's identity provider central control over which MCP servers its people and agents can reach, without a consent click per person per server. If you operate MCP for more than one tenant, both changes are worth a dedicated audit pass rather than a quick read-through.
None of these will make a keynote slide, but each one is the kind of thing that fails silently until a customer hits it in production.
oneOf, anyOf, allOf, and $ref, so a tool can finally say "accept either a room ID or a room name" instead of forcing one rigid shape.-32002 to the standard JSON-RPC -32602. If any of your error handling matches on the literal old value, it will silently stop matching.The maintainers built guardrails so this release does not repeat itself: every feature now has an Active, Deprecated, and Removed lifecycle with a mandatory minimum runway, and new capabilities are expected to land as opt-in extensions rather than core changes. That is a meaningful commitment, but it does not help today. What helps today is working through the migration in order, rather than reacting to whichever error your team hits first in production.
_meta. Pull protocol version, client info, and capabilities from the request itself rather than from a cached initialize response.Mcp-Method and Mcp-Name on every client request, and confirm your gateway or load balancer actually routes on them.tasks/get, tasks/update, tasks/cancel lifecycle.iss, confirm your client declares the right application_type, and re-register credentials wherever a resource has moved between authorization servers.-32002 and replace it with -32602 wherever your client matches on it.None of this needs to land in a single sprint, and the deprecation policy in this release is specifically designed to give you room to sequence it. What it does need is someone who has actually read the spec deciding the order, rather than each team discovering a different piece of it in production over the next few months. That kind of protocol migration audit, mapping what is actually deployed against what changed and sequencing the fix, is the sort of engineering work our AI consultancy practice does for clients running MCP servers at scale. Get the stateless core and the handle pattern right first, since everything else in this release builds on top of that change.
Before we start, please share a few details so we can follow up with you.
End this conversation? Your chat will be emailed to us.