The most useful thing in the final Model Context Protocol 2026-07-28 spec isn't the stateless core everyone wrote about. It's the boring governance document underneath it: a feature lifecycle policy that finally tells you, per feature, whether it's safe to build on. For two years, adopting MCP meant guessing which primitives would survive the next revision. That guessing is over. Here is the whole map on one screen.

The rule that changes the calculus#

The lifecycle policy (SEP-2596) puts every feature in one of three states — Active, Deprecated, Removed — and attaches a contract to the middle one. A feature must remain Deprecated for at least 12 months, measured from the revision that first marks it deprecated, before it can be removed. A security emergency can accelerate that, but even an expedited removal must leave at least 90 days. Translated for a builder: you now get a minimum of a year's warning before anything you depend on can vanish.

That single guarantee is what turns MCP from a moving target into a plannable dependency. You can adopt it in a product roadmap without budgeting for surprise rewrites.

Active — build on these freely#

These are the spec's forward-compatible path. Nothing here faces a forced migration for at least a year, and most of it is brand-new:

Adopting an Active feature is the cheapest insurance in the spec: even if it changes, you're guaranteed a year of runway before you have to move.

Deprecated — keep what you have, add nothing new#

These still work. They will keep working for at least 12 months. But they are on the clock, and new code should route around them:

The discipline here is simple and worth writing into your team's rules: stop writing new code against deprecated features today, and schedule the migration of existing dependencies inside the window rather than when a spec drop forces your hand.

Removed — already gone#

A couple of things didn't survive the stateless redesign, so don't reach for them:

The one-paragraph playbook#

Build every new MCP server on the Active set — stateless core, Tasks, Multi Round-Trip Requests, hardened auth — and you're on the supported path with a guaranteed year of runway. For anything Deprecated you already ship, don't panic and don't add more; put the migration on the calendar inside its 12-month window. And treat the lifecycle policy itself as the real headline: MCP just promised to stop breaking you without notice, which is worth more to a small team than any single feature.

If you're moving existing code, we wrote the step-by-step in how to migrate your MCP client to the 2026-07-28 stateless spec and how to migrate a server off Sampling, Roots, and Logging, and the async Tasks pattern is in how to run a long MCP tool call as a task. For the week's full context, see this week's Founder's Wire.