Deprecation Windows

A protocol that removes things without warning is not a protocol; it's a moving target. MCP's discipline: any feature being removed lands first in a revision marked deprecated, with the replacement shipping in parallel, and is removed no sooner than the next next revision. That gives implementations at least one full revision cycle to migrate.

The 2025-11-25 deprecation of HTTP+SSE is the live example. The 2024 spec defined two endpoints (POST for requests, GET for SSE). The 2025-03-26 revision introduced Streamable HTTP. The 2025-11-25 revision marks HTTP+SSE deprecated and labels Streamable HTTP as the path forward; servers that don't migrate before whichever revision finally removes HTTP+SSE will eventually fail to handshake with new clients.

Deprecation also flows through capabilities. A capability that is being phased out is still advertised — so old clients can detect and use it — but the spec marks it with a sunset note and the SDK marks it deprecated in code. New code should not start consuming a capability that is already on the way out, even if it currently works.

Code

Reading deprecation in the spec — a real fragment·markdown

> The legacy HTTP+SSE transport (defined in revisions before 2025-03-26) is
> **DEPRECATED** as of revision 2025-11-25. New servers SHOULD implement
> Streamable HTTP. Existing HTTP+SSE servers SHOULD plan migration; clients
> SHOULD prefer Streamable HTTP when both are available.

Migration playbook for a deprecation·text

1. Read the deprecation note in the new revision.
2. Stand up the replacement next to the deprecated feature (no flag flip yet).
3. Migrate clients to advertise/prefer the new feature.
4. Wait one revision cycle. Watch logs for stragglers.
5. Remove the deprecated feature from your server's advertised capabilities.
6. Keep the spec section URL in your changelog so future-you can audit.

Code

External links

Exercise

Progress

Comments 0