Everyone read the 2026-07-28 MCP release candidate for the statelessness, or the three primitives it deprecates, or the shiny new Tasks and Apps extensions. The change that actually decides whether you can build a company on this protocol is none of those. It's a governance document — SEP-2596, the feature lifecycle policy — and it's the first time MCP has told you, in writing, how long its promises last.

The policy, in one sentence#

Every core feature is now in one of three states — Active, Deprecated, or Removed — and there must be at least twelve months between the release that deprecates a feature and the earliest release that may remove it.

That's it. It sounds like paperwork. It's the single most important line in the spec for anyone shipping MCP servers to real users, because before it, MCP had no published answer to the only question that matters when you commit a codebase to a protocol: if I build on this today, how much warning do I get before it breaks?

The honest previous answer was "none guaranteed." Tasks is the proof. It landed as an experimental core feature in the 2025-11-25 spec, and by this release it had been redesigned into an extension — a full reshaping of an API that early adopters had already written against, with no runway because none was owed. SEP-2596 exists so that the core never does that to you again.

"Deprecated" does not mean "gone"#

The subtlety people will get wrong: this release deprecates Sampling, Roots, and Logging — and all three still work. MCP calls these annotation-only deprecations. The method and its capability flag keep functioning in the release that deprecates them and in every spec version published within a year of it. Nothing you shipped last month stops working the day you read the changelog.

A deprecation used to be a warning shot. Now it's a countdown you can actually read — and plan a migration against, instead of discovering the breakage in an incident channel.

So the correct reading of "MCP deprecated Sampling" is not rip it out. It's you have a year of runway and, for the first time, a clock you can see. The policy's real product isn't the three deprecations. It's predictability — the difference between planning a migration and reacting to one.

Where the guarantee quietly ends#

Here's the part the release-note enthusiasm skips. The 12-month lifecycle is a property of the core specification. Extensions are a different country.

Extensions — the framework's whole point — carry reverse-DNS identifiers like io.modelcontextprotocol/tasks, live in their own ext-* repositories with delegated maintainers, negotiate through capability maps at connect time, and version independently of the specification, on their own SemVer. That independence is a feature: it's how a capability can ship, iterate fast, and stabilize as an opt-in before anyone argues about promoting it into core. The Extensions Track in the SEP process is designed around exactly that path.

But independence cuts both ways. If an extension versions on its own SemVer, then the core's 12-month deprecation guarantee is not something it inherits. And look at which capabilities are extensions in this release: Tasks (async, long-running tool calls) and MCP Apps (interactive HTML UIs in a sandboxed iframe) — the two most useful new things in 2026-07-28. The features you actually want to build on are precisely the ones sitting outside the promise that makes the core safe to build on.

The stability question inverts#

Put the two halves together and the intuition most people carry about MCP flips.

The instinct is that the deprecation-heavy, session-less, primitive-cutting core is the churny part, and the fresh extensions are the future. The policy says the opposite. The core just became the most stable surface MCP has ever had — three deprecations, yes, but each with a published year of runway and a lifecycle you can plan against. The extensions are where the version movement now lives: each on its own release cadence, its own maintainer, its own breaking-change calculus, its own attack surface.

That's not an argument against extensions. It's an argument for reading them as what they are — pinned, tracked dependencies, not spec-blessed guarantees. Build your foundation on core primitives, where the 12-month clock protects you. Adopt Tasks or Apps deliberately, pin the extension version, and watch its changelog the way you'd watch any third-party library, because as far as the stability policy is concerned, that's exactly what it is.

MCP grew up in this release. But maturity isn't the statelessness or the deprecations. It's that the protocol finally tells you where its guarantees stop — and the useful move is to notice that the line runs right between the core you should stand on and the extensions you should merely lean on.