16 Months Apart: A Deprecation Notice and a Removal Clock Are Different Events

MCP first marked SSE (Server-Sent Events) transport as deprecated back in the 2025-03-26 spec, when Streamable HTTP arrived as its replacement. But a deprecation notice and a confirmed removal date are two different events. The spec finalized on July 28, 2026 is the first to lock in a "year-long offramp" — meaning the actual countdown to removal only started 16 months after the deprecation notice went out.

The gap shows up unevenly across SDKs, too. The TypeScript SDK already marks SSEClientTransport as @deprecated and steers users toward StreamableHTTPClientTransport. The Python SDK, per an issue (#2278) opened on 2026-03-11, still surfaces no warning at all. Even inside a single organization running the same protocol, how "deprecated" a transport feels depends on which language your service happens to use.

Two Endpoints vs. One: Why the Cutover Drags On

SSE split server-to-client streaming and client-to-server POSTs across separate endpoints, which meant extra connection-management and scaling overhead. Streamable HTTP collapses both into a single /mcp endpoint, removing that burden entirely — for anyone who can fully cut over. Servers that still need to serve legacy clients can't: the spec itself states that "servers wishing to support older clients SHOULD continue to host the SSE and POST endpoints... alongside the new 'MCP endpoint'." The longer that dual-hosting window runs, the more silently routing, auth, and logging costs pile up across two code paths instead of one.

From Design to Operations: A Checklist for the Legacy SSE Sunset

Start planning by carving the time left before the offramp closes (one year from the 2026-07-28 confirmation) into quarters, with a number attached to each. A reasonable target: cut SSE traffic share by 25 percentage points every quarter so it falls under 5% three months before the deadline, and treat 100% Streamable HTTP adoption for new client onboarding as a non-negotiable release gate.

Three failure patterns recur. First, teams miss that SDKs surface deprecation warnings on different timelines — a TypeScript service starts migrating while a Python service is still wiring up SSE as the default for new integrations. Second, dual-endpoint routing gets bolted onto the gateway as a one-off and never documented, so when the offramp deadline nears, nobody can say which clients still depend on SSE. Third, teams try to fold SSE removal into a single SDK major-version bump, and end up breaking legacy partner integrations that genuinely still needed backward compatibility.

Recovery starts with logging design. If every request carries transport type and client identifier as required fields, you can pull the list of unmigrated clients the moment the deadline approaches and notify them individually. For partners who genuinely need more time, keep their traffic on transport-based routing at the gateway while cutting the rest of the traffic over first — a partial rollout instead of an all-or-nothing cutover.

The operations checklist starts with pre-release verification: run smoke tests against both SSE and Streamable HTTP before every deploy, and surface each SDK's DeprecationWarning status on an internal dependency dashboard so the awareness gap between teams closes. Add transport type, SDK version, and client identifier as required log fields so you can count remaining SSE traffic in real time.

The improvement loop runs on weekly tracking. Tally SSE traffic share and the count of unmigrated clients every week; if the decline stalls, pin down the cause that same week — a legacy partner, an SDK version pinned somewhere — and build an individual response plan. Three months before the offramp closes, put a decision checkpoint on the calendar now for whether to force a hard cutoff even if some traffic remains.

Takeaways at a Glance

A transport deprecated 16 months ago only got its year-long removal clock with the 2026-07-28 spec — which is the signal that now is the time to deliberately close out dual-transport support. Close the SDK-warning awareness gap with a dashboard, log transport type as a required field to pin down unmigrated clients, and set quarterly SSE-traffic-reduction targets as numbers rather than good intentions — and the forced cutoff at the end of the offramp passes without an incident.

References

The 2026-07-28 Specification — Model Context Protocol Blog

Mark SSE transport as deprecated · Issue #2278 — modelcontextprotocol/python-sdk

MCP Without Sessions: A Review of the 2026-07-28 Specification — sunny34.com Research