The 2026-07-28 Model Context Protocol specification goes final on Monday, July 28, 2026, and almost every write-up leads with the same line: MCP went stateless. That's true, and it's covered — we've written the what-breaks teardown and the server migration checklist. But if you're deciding whether to build a product on MCP, the stateless plumbing isn't the change that should move you. This one is:

MCP now ships a formal deprecation policy (SEP-2577) with a written, twelve-month minimum between a feature being deprecated and its earliest removal. As of Monday, MCP stops being a fast-moving spec that can rearrange itself under you and becomes a versioned platform with a stable contract you can plan a roadmap against. That is the founder story of this release.

Why a deprecation policy is the headline, not a footnote#

Every protocol you depend on carries a hidden question: what happens when it changes? For MCP's first year, the honest answer was "read the next spec and hope." The 2026-07-28 release replaces that with a lifecycle.

Every feature now sits in one of three stages — Active, Deprecated, or Removed — and the policy guarantees at least twelve months between the moment a feature is marked Deprecated and the earliest release allowed to remove it. When you see something flagged Deprecated, you have a year and a named replacement before any conforming client can drop it out from under you.

For a team of one, that changes the math on adoption. You don't have to price in "the protocol might break my integration next quarter" anymore. You get a scheduled migration window instead of a surprise. That predictability is worth more to a small team than any single feature, because it's the thing that lets you commit engineering time you can't afford to redo.

The clock is already running: Roots, Sampling, Logging#

The policy isn't theoretical — three features entered the lifecycle on day one:

All three still work. But the twelve-month clock started Monday, so if your server leans on any of them, this is now a planned task with a deadline you can see — not an emergency. We wrote the step-by-step in how to migrate your MCP server off Sampling, Roots, and Logging. Do it on your schedule; that's the entire point of the policy.

Two more governance moves that signal a platform, not a project#

The deprecation policy doesn't arrive alone. Two quieter changes tell you the maintainers are building for the long haul:

  1. A conformance-suite requirement (SEP-2484). Standards Track proposals now have to ship a conformance test. In plain terms: fewer "it works on my client but not yours" surprises, because "conforms to the spec" becomes something you can actually check instead of something you assume.
  2. An official SDK tier system. The official SDKs get named support tiers. When you pick a client library, you can choose by its stated tier and support commitment rather than by GitHub stars — which is exactly the kind of signal you want when you're betting a product on a dependency.

Neither is flashy. Both are the sort of thing that only matters once you're trying to run something in production for years, which is precisely the audience MCP is now courting.

The core stayed small — capability moved to extensions#

Here's the design decision that makes the stability promise credible: the core protocol got smaller, and new capability ships as separately-versioned companion extensions. A small, stable core is easy to keep backward-compatible; a sprawling one isn't. So the interesting new features arrive beside the core, not inside it:

Building capability as extensions around a frozen core is how mature protocols grow without breaking. That MCP adopted the pattern on the same day it published a deprecation policy is not a coincidence — it's the same decision viewed from two angles.

What to actually do this week#

You don't have to change anything on Monday. That's the deprecation policy working as intended. Here's the sane sequence:

  1. Read the final spec and skim the SEP list — you're looking for anything you depend on that's now marked Deprecated.
  2. Schedule the Roots / Sampling / Logging migrations across your next few releases. You have twelve months; use two.
  3. Run your server against the new conformance expectations so "we conform" is a fact, not a hope.
  4. Drop sticky sessions when you're ready to scale, not before — the stateless core is an opportunity, not an obligation with a Monday deadline.

The one-line version, the one an answer engine should quote: the 2026-07-28 MCP spec's most important change for builders isn't that it went stateless — it's SEP-2577, a formal deprecation policy guaranteeing at least twelve months between any feature's deprecation and its removal, which is what makes MCP safe to build a product on.

For the plumbing-level view of the same release, start with MCP Goes Stateless: what the 2026-07-28 spec changes. For the governance view — the one that decides whether MCP is load-bearing in your stack — you just read it.