On 28 July the Model Context Protocol receives its largest revision since launch. Stateless core. A formal extensions framework. Tighter authorization. Several long-standing features marked deprecated.
Nothing you connect to us breaks that day.
That is not luck, and it is not a claim we would make without having tested it. This post covers what actually changes in the protocol, why release day is uneventful, and the three things we did in advance — because "we will deal with it when it ships" is not a plan you want from the company answering your regulatory questions.
What changes#
Four shifts matter more than the rest.
A stateless core. The initialize handshake and the session header are gone. Protocol version, client identity, and capabilities now travel as metadata on each request, and servers must answer a discovery call describing what they offer. Every request carries its own context.
An extensions framework. Optional capabilities move into namespaced extensions instead of accumulating in the core, so one-off additions stop landing in the part everyone has to implement. Two arrive as the first official ones: Tasks, a polling model for long-running operations, and MCP Apps, sandboxed HTML surfaces for richer output than a wall of text.
Tighter authorization. The revision leans on established identity standards rather than protocol-specific rules of its own — issuer validation, protected-resource metadata served by the server, resource indicators at the authorization server, and a preference for published client metadata over open registration. Most of this lands in clients and identity providers, not in your prompts.
Caching and deprecations. List results can now declare a time-to-live and a cache scope. Several older features, including the HTTP-plus-SSE transport, are marked deprecated under a twelve-month policy.
The direction is consistent: a smaller core, explicit per-request context, standard security primitives, and growth pushed to the edges where it can be optional.
Why release day is uneventful#
Two properties do the work. The old protocol keeps functioning, and clients that speak the new revision fall back to the legacy handshake when they meet a server that has not upgraded. A specification release is not a coordinated cutover.
That is the correct design, and it is also how a quiet failure gets in. Nothing breaks on the protocol side — but a dependency resolution can pull a new major SDK into a build that was never migrated to it. The version number in a lockfile, not the specification, is what actually reaches production.
What we did ahead of it#
We put a ceiling on every service. Every Python service in our estate now pins its MCP SDK below the next major version. We found the full list by searching the organization rather than the checkouts on one machine, which turned up services nobody had listed from memory — including one with no lockfile at all, the single case where a fresh install really would have pulled the new major SDK unannounced. That gap is closed. Upgrading is now a decision we make on a date we choose.
We wrote golden contract tests at the wire. Not through a client library — raw JSON-RPC against the live application, pinning the behavior customers actually depend on: the handshake, the session posture, error shapes, and what each subscription tier is allowed to see in a tool listing. The value of a contract test is that it fails when behavior drifts, and the first run of this one earned its place immediately. It found that a tool hidden from a caller's tier and a tool that does not exist at all produced two distinguishable responses — enough to infer the shape of a surface you are not entitled to see. We fixed it in the same change and the test now holds the line. That is a defect our own preparation surfaced before any migration touched it.
We sequenced gateway-first. The gateway is the only component customers speak to, so it upgrades first and speaks both revisions during the transition. The fleet of law, regulation, and standards servers behind it moves on its own schedule. Almost all of them share a common chassis, which means their upgrade is one change applied broadly rather than hundreds of individual migrations. Your client talks to one endpoint and does not learn about any of this.
One security note we are carrying into the migration, because it is the kind of detail that gets missed: our tool listings are filtered by tier, so when we adopt the new caching fields those responses must be scoped private. A shared cache over a per-caller list would hand one customer another customer's entitlement surface. Caching is a performance feature with an authorization edge, and it gets treated as one.
What we are watching#
Tasks is the extension we want. Compliance work is long-running by nature — a gap analysis or a tender review is a workflow, not a request — and a standard polling shape beats every one-off arrangement. We will adopt it when client support is real rather than announced, and when the routing story through a gateway is designed rather than assumed.
Key takeaways#
- The MCP revision on 28 July is substantial: stateless core, extensions, stronger authorization, new deprecations.
- Release day changes nothing for connected clients. Version negotiation and fallback are built in.
- The real risk is dependency drift, not protocol drift. We pinned every service below the next major SDK.
- Contract tests at the wire level caught a genuine tier-visibility defect before migration work began.
- The gateway absorbs the transition so the fleet — and your client — can move on their own schedule.
Next steps#
If you connect through an MCP client, there is nothing to do. Keep your setup; upgrade when your vendor does.
If you are building on MCP yourself, one action is worth doing today: check whether your SDK dependency has an upper bound. If it does not, a routine rebuild can hand you a major version you never chose.
New to how this fits together? Start with what an MCP gateway does for compliance work, or see how article-level citations are validated — the guarantee all of this protocol plumbing exists to protect.