> ## Documentation Index > Fetch the complete documentation index at: https://modelcontextprotocol.io/llms.txt > Use this file to discover all available pages before exploring further. # Feature Lifecycle and Deprecation Policy > How individual MCP specification features move through Active, Deprecated, and Removed states, and the timeline implementers can plan against. This policy defines a lifecycle for individual features within the Model Context Protocol specification. It defines three feature states (Active, Deprecated, Removed), the criteria and procedure for moving between them, a minimum window between deprecation and removal, and the documentation required at each transition. This policy was adopted via [SEP-2596](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2596). ## Scope This policy governs **features** of the MCP core specification: protocol messages, capabilities, transports, schema types, and normative behavioral requirements. The revision lifecycle of the specification document itself (Draft, Current, Final) is defined in the [versioning guide](/docs/learn/versioning). ## Feature States A specification feature is in exactly one of three states: | State | Meaning | Implementer expectation | | -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------- | | **Active** | The feature is part of the Current specification revision. | Implement per the feature's normative requirements. | | **Deprecated** | The feature remains in the specification but is scheduled for removal. A migration path is documented (see below). | New implementations should not adopt the feature. Existing implementations should migrate before the earliest removal date. | | **Removed** | The feature has been deleted from `draft` and will be absent from the next Current revision. It remains documented in the Final revision it last appeared in. | Implementations targeting that next Current revision must not depend on the feature. | A Deprecated feature MAY be restored to Active by a SEP that supersedes the deprecation SEP and documents the changed circumstances. Restoration follows the same approval path as deprecation. If the feature is later deprecated again, the minimum deprecation window in [Deprecating a feature](#deprecating-a-feature) is measured afresh from the revision in which the new deprecation takes effect. ### SDKs Removal from the specification does not oblige an SDK to drop the feature from releases. That timeline is governed by the SDK's own revision-support policy. ## Deprecating a Feature A feature may be proposed for deprecation when: * it has been superseded by another feature that covers the same use cases, * it presents a security, privacy, or interoperability risk that cannot be mitigated in place, * ecosystem telemetry or SDK maintainer consensus indicates negligible adoption relative to its maintenance cost, * or any other reasons the Core Maintainers deem appropriate. Deprecation is a specification change and therefore requires a SEP per the [SEP guidelines](/community/sep-guidelines). The deprecation SEP must: 1. Identify the feature by name and link to its definition in `schema.ts` (where applicable) and the specification prose. 2. State the rationale against the criteria above. 3. Document the migration path, or state explicitly that none is required. If the migration path names a replacement feature, that feature must be Active in the revision in which the deprecation takes effect; the replacement and the deprecation may land in the same revision. 4. Specify the **minimum deprecation window**: the number of months, at least twelve, that the feature must remain Deprecated before it is 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. The feature becomes eligible for removal in the first specification revision released as Current on or after the window elapses; that point is the feature's **earliest removal**. When the deprecation SEP is accepted and reaches Final, the deprecation is scheduled. * The feature's entry in `schema.ts` gains a `@deprecated` JSDoc tag referencing the deprecation SEP and the revision in which the deprecation takes effect. * The specification prose for the feature gains a deprecation notice with the same information. * The `changelog.mdx` for that revision gains an entry under a "Deprecated" heading. "Deprecated" and "Removed" are standing changelog headings alongside the existing Major/Minor/Other groupings. * The feature is added to the [deprecated registry](#the-deprecated-registry) with its deprecation SEP, the revision in which it became Deprecated, its migration path, and its earliest removal. The feature becomes Deprecated when the revision carrying these changes is released and becomes the new Current revision (see [versioning guide](/docs/learn/versioning)). The minimum deprecation window is counted from that release. ## The Deprecated Registry [`docs/specification/draft/deprecated.mdx`](/specification/draft/deprecated) is a single page listing every feature in a Deprecated or Removed state. It is the canonical answer to "what is on its way out, and by when," so that an implementer does not have to reconstruct that picture from deprecation entries spread across revision changelogs. ## Tier 1 SDK Obligations Once the revision in which a feature becomes Deprecated is released as Current, Tier 1 SDKs: * Must mark the corresponding API surface deprecated using the language's native mechanism (for example `@Deprecated` in Java, `[Obsolete]` in .NET, `@deprecated` JSDoc in TypeScript, the `Deprecated:` doc convention in Go) in their next release, referencing the deprecation SEP and the earliest removal date where the mechanism permits. * Should emit a runtime warning when a deprecated feature is exercised, using the language's idiomatic mechanism (for example Python's `DeprecationWarning`, Node.js's `process.emitWarning`, or a configurable logger). A Tier 1 SDK that consistently fails to surface a Deprecated feature is subject to the [Tier Relegation Process](/community/sdk-tiers#tier-relegation). ## Removing a Feature 1. Once a feature is set for removal, the removal is executed at the discretion of the Core Maintainers after the minimum deprecation window has elapsed. 2. The removal needs to be documented in the `changelog.mdx` and [registry](#the-deprecated-registry). 3. A SEP is required for any change to the original deprecation or removal SEP, for example extending or shortening the timeline ([Expedited removal](#expedited-removal)) or restoring the feature to Active ([Feature states](#feature-states)). Features may remain Deprecated, without removal, for much longer than the minimum deprecation window. ## Expedited Removal The twelve-month floor may be shortened when the feature presents an active security risk, meaning a vulnerability with a published security advisory or documented in-the-wild exploitation for which no in-place mitigation exists. Shortening the window requires Core Maintainer approval under the [governance decision process](/community/governance#decision-process), recorded in the deprecation SEP or, where the risk surfaces after that SEP is already Final, in a short expedited-removal SEP that references it. The shortened window must still provide at least ninety days between the feature becoming Deprecated and its earliest removal. ## Roles | Action | Who | | ---------------------------------------------- | ----------------------------------------------------------------------------------------------- | | Propose deprecation, extension, or restoration | Any contributor, per the SEP process | | Sponsor | A Maintainer or Core Maintainer, per the SEP process | | Approve a deprecation SEP | Core Maintainers, per the [governance decision process](/community/governance#decision-process) | | Decide a removal during release preparation | Core Maintainers, per the [governance decision process](/community/governance#decision-process) | | Approve an extension or restoration SEP | Core Maintainers, per the [governance decision process](/community/governance#decision-process) | | Approve expedited removal | Core Maintainers, per the [governance decision process](/community/governance#decision-process) | Lead Maintainers retain veto authority over each of the approvals above, per the [governance roles](/community/governance#roles) definition.