MCP publishes a feature lifecycle policy with a twelve-month minimum deprecation window
Alongside the 2026-07-28 revision, the MCP project published a written policy defining three feature states and a minimum period a feature must remain deprecated before it becomes eligible for removal. A standing registry page lists every deprecated feature with its migration path and earliest removal date, and Tier 1 SDKs are obligated to surface deprecations in-language.
The MCP project published a Feature Lifecycle and Deprecation Policy alongside the 2026-07-28 revision, adopted via SEP-2596. The policy defines exactly three feature states, Active, Deprecated, and Removed, and requires every deprecation to specify a minimum window of at least twelve months that the feature must remain Deprecated before becoming eligible for removal. The window is measured from the release of the specification revision in which the feature is first marked Deprecated, not from the date the SEP reaches Final.
Removal is not automatic. Once the window elapses, removal is executed at the discretion of the Core Maintainers, and Lead Maintainers retain veto authority over each approval. An expedited path exists only where a feature presents an active security risk, defined as a vulnerability with a published security advisory or documented in-the-wild exploitation with no in-place mitigation, and even then at least ninety days must separate deprecation from earliest removal.
The policy places obligations on Tier 1 SDKs: deprecated API surface
must be marked with the language's native mechanism (@Deprecated in
Java, [Obsolete] in .NET, @deprecated JSDoc in TypeScript, the
Deprecated: doc convention in Go) in the SDK's next release, and an
SDK that consistently fails to surface a deprecation is subject to the
Tier Relegation Process.
A standing registry page now lists every feature in a Deprecated or
Removed state. For 2026-07-28 it carries six rows. Newly deprecated in
this revision are Roots, Sampling, and Logging (all via SEP-2577) and
Dynamic Client Registration (PR #2858), each with an earliest removal of
the first revision released on or after 2027-07-28. The documented
migration paths are tool parameters, resource URIs, or server
configuration in place of Roots; direct LLM provider APIs in place of
Sampling; stderr plus OpenTelemetry in place of Logging; and Client ID
Metadata Documents in place of Dynamic Client Registration. Two
pre-existing deprecations were reclassified under the policy: the
includeContext: "thisServer" / "allServers" values on Sampling
(deprecated in 2025-11-25) and the HTTP+SSE transport (deprecated in
2025-03-26), whose earliest removal is three months after SEP-2596
reaches Final. The SEP page records Final status as of this writing, so
that clock is running. The Removed section states that no features have
been removed under the policy yet.
Related spec revisions
- MCP 2026-07-28 - current
How was this verified, and what are the sources?
Published · last verified · confidence 0.95.
- Spec site policy page "Feature Lifecycle and Deprecation Policy" - defines the Active/Deprecated/Removed states, the minimum window of "at least twelve" months measured from the release of the revision in which the feature is first marked Deprecated, the ninety-day floor for expedited removal, the Tier 1 SDK obligations with named language mechanisms, and the roles table; states "This policy was adopted via SEP-2596" - accessed
- Spec site "Deprecated Features" registry for revision 2026-07-28 - renders the six-row Deprecated table with deprecation SEP, deprecated-in revision, migration path, and earliest removal per row, plus a Removed section stating "No features have been removed under this policy yet" - accessed
- Spec site SEP page for SEP-2596 "Specification Feature Lifecycle and Deprecation Policy" - records Final status, described as "preserved as a historical record" - accessed