Is MCP SSE Deprecated? Yes. Here Is What Replaced It

Yes. The HTTP+SSE transport from the original 2024-11-05 MCP spec was deprecated in spec revision 2025-03-26 and replaced by Streamable HTTP. The current 2026-07-28 spec formally lists it as Deprecated under the new feature lifecycle policy. It can be removed three months after that policy is finalized. New servers should use Streamable HTTP, while existing SSE servers keep working with most clients during the transition.

One distinction matters: SSE as a format is not going away. Streamable HTTP still uses Server-Sent Events to stream a response when a server needs to. What's deprecated is the old transport design built around a long-lived SSE connection and a second POST endpoint.

Old vs new at a glance

Why it was replaced

The SSE design was hard to run in production. Each client kept a connection open for as long as it was connected. Replies to a POST came back on a different connection, so a load balancer had to send both to the same instance. Serverless platforms with short request timeouts couldn't host it reliably. Streamable HTTP fixed this with one endpoint and ordinary request/response semantics. The server upgrades to SSE only when it needs to stream progress or notifications before the final result.

What changed since 2025-03-26

Streamable HTTP itself has changed since it was introduced:

• 2025-03-26: Streamable HTTP introduced. It had optional sessions (Mcp-Session-Id), an optional standalone GET stream for server-initiated messages, and resumable streams via Last-Event-ID.
• 2025-06-18 and 2025-11-25: added the MCP-Protocol-Version header and tightened the authorization rules. The transport shape stayed the same.
• 2026-07-28 (changelog): MCP became stateless. The initialize handshake and protocol-level sessions were removed. The GET stream was replaced by a subscriptions/listen request. Resumability was removed. POSTs must carry Mcp-Method and Mcp-Name headers so gateways can route without parsing bodies. The same release reclassified HTTP+SSE as formally Deprecated (SEP-2596).

In practice, a "Streamable HTTP" server written in mid-2025 and one written today look a little different on the wire. The current SDKs handle both.

Backwards compatibility: how old and new talk to each other

The spec defines a fallback, so clients and servers from different eras can still talk:

• Clients that support both POST to the URL first. If that fails with 400, 404 or 405, they try a GET. If the server answers with an SSE endpoint event, they continue on the old transport.
• Servers that want to keep serving old clients host the old /sse and /messages endpoints next to the new /mcp endpoint.
• 2026-07-28 servers that receive 2025-era Streamable HTTP traffic answer GET/DELETE with 405 and ignore Mcp-Session-Id and Last-Event-ID. A client that gets a 400 without a recognized modern error falls back to initialize.

The official SDKs v2 put this into code:

• TypeScript (@modelcontextprotocol/server 2.x): the server no longer serves HTTP+SSE at all. createMcpHandler serves Streamable HTTP and answers 2025-era clients statelessly by default. For a deployment that can't move yet, a frozen copy ships in @modelcontextprotocol/server-legacy/sse. It's deprecated and planned for removal in v3. The client still includes SSEClientTransport.
• Python (mcp 2.x): mcp.run(transport="sse") still works for old clients, but the docs say not to build anything new on it. The client can still connect with sse_client(...).

Do clients still support SSE servers?

Mostly yes, for now. As of October 2026:

The "deprecated" label tells you where things are going. New clients and gateways may support only Streamable HTTP. Once the spec removes the transport, the SDKs will drop it too.

What this means for you

It depends on which side of the connection you are on:

• You use MCP servers. Nothing breaks today. If a server's docs offer both a /sse and a /mcp URL, pick /mcp and set the client's transport to HTTP. Keep the /sse URL only for servers that offer nothing else, and expect those to move or disappear.
• You maintain an SSE server. Plan the migration now, while clients still support both transports. You can run the old and new endpoints side by side, so there is no flag day for your users.
• You build a client or gateway. Implement Streamable HTTP first. Keep the SSE fallback only as long as your users still connect to legacy servers, and log when it gets used so you know when you can remove it.

How to tell which one a server uses

• URLs ending in /sse are almost always the legacy transport. /mcp usually means Streamable HTTP.
• Quick probe: POST an MCP request with Accept: application/json, text/event-stream. A Streamable HTTP server returns JSON or an SSE message event. A legacy-only server typically returns 404/405 on POST and only opens a stream on GET.
• Or let the MCP Inspector connect with --transport http and see if it succeeds.

Migration steps for server authors

1. Upgrade the SDK. TypeScript: move from @modelcontextprotocol/sdk 1.x to @modelcontextprotocol/server 2.x (the upgrade guide includes a codemod). Python: mcp 2.x, where FastMCP became MCPServer.
2. Replace the transport wiring. TypeScript: drop SSEServerTransport and the /sse and /messages routes, and serve createMcpHandler(factory) on one route such as /mcp. Python: change transport="sse" to transport="streamable-http".
3. Move state out of the connection. Anything you kept per SSE session (a logged-in user, a cursor, a cache) belongs in your own storage, keyed by the authenticated user or by IDs passed as tool arguments.
4. Keep the old endpoints for a while. Serve the frozen SSE transport next to /mcp so existing configs keep working, and log how much traffic still hits /sse.
5. Update the published URL. Change the README, your registry server.json ("type": "streamable-http" in remotes) and your MCP.so listing to point to /mcp.
6. Test both eras. Use the Inspector with --transport http against the new endpoint and --transport sse against the old one. Then remove /sse once traffic reaches zero, or before the spec removes it.
7. Recheck your proxy settings. Streamable HTTP still streams some responses, so turn off response buffering for text/event-stream on nginx and other proxies, and allow reasonable timeouts.

For hosting the migrated server, see how to deploy an MCP server. For a refresher on the protocol, see how MCP works.

Next steps

Browse servers that already offer Streamable HTTP endpoints in the MCP server directory. Official remote servers such as Sentry, Notion and GitHub are good references for the current setup.