In MCP, what does the Deprecated status guarantee about a feature's removal?

## Deprecated versus removed MCP evolves by dated revisions, and a revision date marks a backwards-incompatible change. Deprecation is the mechanism that stops those breaks from arriving without warning. A feature that is going away is first marked **Deprecated**: it still works, it is still fully specified, and implementations that use it are still conformant — but the specification has announced its end and named what replaces it. Removal is a separate, later event that lands in some future revision. ## The guarantee Three commitments come with the Deprecated label: 1. **Minimum lifetime.** The feature stays in the specification for at least twelve months after it is marked. 2. **New implementations SHOULD NOT adopt it.** This is aimed at anyone starting work today. Building on a deprecated feature means buying a migration you already know about. 3. **A migration path is documented.** Deprecation without a replacement would just be a countdown to breakage, so each entry says what to use instead. Applying the clock to the current batch: features deprecated in revision 2026-07-28 cannot be removed before the first revision released on or after **2027-07-28**. Note the shape of that rule — it is not "removed on 2027-07-28". The date is a floor, and removal happens in whatever revision comes after it, which may be considerably later. A well-behaved implementer reads it as "you have at least a year, and you will not be surprised inside that year". ## The registry The specification maintains a registry of deprecated features so you can see the whole surface at once instead of grepping revision notes. Reading it is the practical first step when planning an upgrade, because it tells you which parts of your implementation have a countdown attached. At revision 2026-07-28 it includes: - **Roots** — migrate by passing directories or files through tool parameters, resource URIs, or server configuration. - **Sampling** — migrate by integrating directly with an LLM provider's own API. - **Logging** — migrate by writing to `stderr` on stdio, and using OpenTelemetry for real observability. - **Dynamic Client Registration (RFC 7591)** — migrate to OAuth Client ID Metadata Documents. - The `includeContext` values `"thisServer"` and `"allServers"` — omit the field or use `"none"`. - **The HTTP+SSE transport**, deprecated since revision 2025-03-26 — migrate to Streamable HTTP. Elicitation is **not** deprecated, which is worth knowing because it is frequently lumped in with the client-side features that are. That last entry is instructive on its own: HTTP+SSE has been deprecated since 2025-03-26 and is still in the specification. Deprecation in MCP has been a long, well-signposted ramp in practice, not a euphemism for imminent removal. ## Deprecation is not the same as removal-in-2026-07-28 A common confusion in interviews is to blur the deprecated list with the **removed** list. Revision 2026-07-28 also removed things outright — the `initialize` handshake, protocol-level sessions, `ping`, `resources/subscribe` and `resources/unsubscribe`, server-initiated requests — and those got no twelve-month ramp because their removal *is* the backwards-incompatible change that the revision date announces. Deprecated features are the ones that survived the revision with a countdown attached; removed features are simply gone. If you say "Roots was removed in 2026-07-28" you have conflated the two, and it is exactly the slip an interviewer is listening for. ## How to use the policy in practice - **Starting a new implementation:** consult the registry before you design. Anything on it should not appear in your plan; take the documented replacement instead. This is cheapest at the start and expensive after you have shipped. - **Maintaining an existing one:** treat each deprecated feature you use as scheduled work with a known deadline. The twelve-month floor gives you a planning horizon that is realistic to fit into a normal roadmap, which is the whole point of publishing a floor rather than removing on the spot. - **Reading a new revision:** check three things — what the date breaks, what moved onto the deprecated registry, and what was removed outright. Those are three different classes of work with three different urgencies. - **Talking to your users:** if you operate a server, your own consumers care about the same clock. Publishing which deprecated features you still rely on, and when you will drop them, is the server-side mirror of what the specification does for you. ## What a strong answer sounds like State the twelve-month minimum, the SHOULD NOT-adopt rule for new implementations, and the concrete earliest-removal date for the 2026-07-28 batch. Mention that the registry exists and that each entry names its replacement. Then separate deprecated from removed with an example of each — that distinction is what demonstrates you have actually read a revision rather than a summary of one.