The MCP 2026-07-28 release gives teams a template for addressing a production failure most people have not connected it to yet, and it is not the part of the spec anyone is talking about. It is a template the protocol built for itself and almost nobody has thought to copy. I want to start with the failure, because it is the one that made me care about this.
An agent calls a tool. The tool answers. Nothing errors, nothing pages, nothing turns red on a dashboard. But the tool that answered is not the tool the agent thinks it is calling. Someone shipped a newer version three weeks ago, left the old one running so nothing would break, and moved on. The old one still responds. It just responds a little wrong, in a way nobody notices until a customer does. There was no deprecation notice, because there was nowhere to put one. There was no owner to ask, because nobody wrote one down. There was no sunset date, because sunsetting was never part of how the tool got added in the first place.
That is not a bug. I have stopped calling things like this bugs. It is a missing lifecycle, and it is the single most common thing I see go wrong once an MCP estate has been in production long enough to accumulate history.
Here is what changed my mind about how solvable it is. The 2026-07-28 revision of MCP did not just move the transport around. It quietly shipped something most people are reading straight past because it is not the headline: a real deprecation policy for the protocol itself.
How the protocol gave itself a lifecycle
The mechanics are short, so I will keep them short. Every feature in the spec now moves through a defined lifecycle, Active to Deprecated to Removed, with at least twelve months between the moment something is deprecated and the earliest it can be removed. Deprecations come with a documented migration path, or an explicit statement that no migration is needed, so a deprecation is never just a tombstone with no guidance attached. And a standards-track change cannot reach Final without a matching conformance scenario that proves it actually behaves the way the spec says.
That is the entire WHAT, and I am done with it. Because the interesting part is not that the protocol has a deprecation policy. The interesting part, the one I promised you at the top, is that almost nobody runs their own connectors this way, and the template for doing it is now sitting in plain sight.
If you have ever deprecated a public API endpoint properly, you already have the instinct for this. Hold that thought, because it is the whole back half of this post.
Now look at how we actually run our own tools
I have never met an MCP estate that deprecates its internal tools the way 7-28 deprecates protocol features. I have met plenty that intend to. What actually happens is this.
A tool gets added because someone needed it for a demo, or a launch, or a Friday. It works, so it stays. A better version shows up later and gets added next to it, because ripping out the old one felt risky and nobody had time to prove it was safe. So now there are two. The old one has no owner, because the person who added it changed teams. It has no version anyone tracks, because it was never versioned in a place that mattered. It has no sunset date, because it was never going to be sunset, it was just going to exist until it quietly stopped being right.
Multiply that by an estate a year and a half into adoption and you do not have a tool catalog. You have sediment. And the agents calling into that sediment have no way to know which layer they are standing on.
I want to be clear that I am not describing a security failure or an incompetence failure. This is what happens to every system that grows faster than its governance. I have run infrastructure long enough to know that the drift is not the sign of a bad team. The absence of a deprecation discipline is just the default state, and defaults win unless you replace them on purpose.
So run your connectors the way the protocol runs itself
This is the part I actually care about, and it is less work than it sounds, because the migration is already making you touch everything.
Figure: The lifecycle the protocol now guarantees itself, and the one most connector estates actually run.
Give every tool an owner. Not a team name on a wiki page that went stale in 2025, an actual person or rotation who is accountable for the thing existing. If you cannot name the owner, that is not a tool, that is a liability with an endpoint.
Give every tool a version you track somewhere real, and record which spec and extension versions it supports. When you cannot answer "which version of this is the agent calling," you have already lost the thread.
If this feels like microservice ownership wearing new clothes, good. It is. We spent a decade learning that a service without an owner and a version is an incident waiting for a date, and MCP tools are services. The only new thing here is that the caller is an agent instead of another service, and the agent is even less forgiving about a tool that quietly changed underneath it.
And then the part everyone skips: give every tool a deprecation contract. When you replace a tool, you do not leave the old one running as a courtesy. You deprecate it, on a published clock, with a named replacement or a clear note that nothing replaces it, and you tell the consumers. You give them a window. You do not remove it under them on a Tuesday because you finally got around to cleanup.
If that sounds familiar, it should. It is exactly what you already do for a public API. You would never delete an endpoint that other teams depend on without a version bump, a deprecation header, and a runway. You built that muscle years ago. I am not asking you to learn a new discipline. I am asking you to point the one you already have at a surface you have not been pointing it at.
The migration is the opening. If it is already making you enumerate your connectors, and for most teams it will, you are holding the most expensive part of adopting a lifecycle. That inventory is the hard, tedious work, and the migration is handing you a reason to finally do it. Do not waste it by building an inventory and then walking away. Turn the inventory into a registry, put a lifecycle state next to every entry, and you are most of the way there for free.
The consumers you keep forgetting
Here is the reframe I keep coming back to. When you complain that a provider deprecated something under you without warning, you know exactly how that feels. The protocol just promised you it will handle this with discipline: a twelve-month floor in the normal case, a documented migration path or a clear statement that none is needed, and even the expedited security route holding to at least ninety days with maintainer sign-off.
Your agents are on the other end of that same promise, and right now most of them do not have it. The authors wiring agents into your tools are depending on those tools the way you depend on the protocol, and you are giving them none of the guarantees you just got handed. That asymmetry is the whole problem, and it is the whole fix. The protocol decided to treat the people who build on it with a specific kind of respect. The question 7-28 is really asking is whether you will extend the same respect one layer down, to the agents and the engineers who build on you.
I think the teams that do will come out of this migration with an estate that is smaller, legible, and calm. The teams that treat the lifecycle as someone else's paperwork will come out with the same sediment they went in with, now running statelessly at higher volume. Same mess, faster.
I know which side of that I want to be on.
Share
