It doesn't make headlines, but the quietest change in the 2026-07-28 MCP spec may be the most important for anyone betting a product on the protocol: a formal deprecation policy. Every feature now has a defined lifecycle — Active, Deprecated, Removed — with at least twelve months between deprecation and the earliest possible removal. That single guarantee changes how safe MCP is to build on.
Why this needed fixing
Early MCP moved fast and broke things, and the breakage was unpredictable. A transport could be deprecated and switched off on a timeline nobody could plan around — the HTTP+SSE retirement is the obvious example, where different vendors picked different hard dates and integrations simply stopped responding. When you can't tell whether a capability you depend on will exist next quarter, you either don't build on it or you build defensively and slowly. A protocol that wants to be infrastructure has to offer better than "it might vanish."
The three-stage lifecycle
The new model is simple. Active features are current and supported — build freely. Deprecated features still work, but they're on notice: the spec has signalled a replacement and started the clock. Removed features are gone from the spec. The crucial rule is the gap between the second and third stage: a minimum of twelve months. Deprecation is never a surprise switch-off; it's a year-plus warning with a documented successor, which is enough runway for even slow-moving enterprise teams to migrate on their own schedule.
What it means for server authors
If you maintain a server, the policy lets you make commitments you previously couldn't. You can depend on an Active feature without hedging, and when something you use is deprecated, you get a real migration window instead of a fire drill. It also sets expectations the other way: features that ship as opt-in extensions under the new Extensions framework are explicitly allowed to stabilise — or to be dropped — before they ever reach the core, so "experimental" now means something concrete rather than a vibe.
What it means if you just use MCP
For users and operators, the payoff is fewer mystery outages. A connector that breaks is no longer plausibly explained by "they removed that without warning" — removals now come with a year of notice and a published path forward. When a previously-working connector does fail, that makes the real cause easier to find: it's far more likely a connection-closed error or a missed transport switch like the SSE deprecation than a silent spec removal.
Going further
A deprecation policy is the unglamorous plumbing that lets the flashy parts — stateless servers, MCP Apps, the Tasks extension — be adopted without fear. Read it alongside the full 2026-07-28 spec rundown, and for how the ecosystem tracks trustworthy servers over time, see trusted MCP registry providers. More in the developer-tools category.