Why was HTTP+SSE deprecated as an MCP transport in 2025 and what does Streamable HTTP improve?

The original remote transport for MCP was called **HTTP+SSE**, and it split communication across two channels. To send a message, the client made a normal HTTP POST. To receive messages back, the client opened a separate, long-lived Server-Sent Events stream that the server pushed data down. That split caused problems. You now had two connection types with two different failure modes. If the SSE stream dropped, the client had to reconnect and somehow prove it was the same session. If a POST failed, that was a separate recovery path. Keeping the two sides correlated was fiddly, especially on hosting that does not like long-lived connections. Serverless platforms make this worse. Functions on AWS Lambda or Cloudflare Workers are short-lived and stateless, so holding an SSE stream open for a whole session fights the platform. Streamable HTTP replaced it in 2025. The client uses a single endpoint with one HTTP POST per message. The server can optionally stream its reply back in chunks when a response takes a while. One channel, stateless-friendly, and it supports resuming a session after a disconnect.

HTTP+SSE was deprecated because it forced two mismatched channels onto one logical session. The server pushed messages over a long-lived **Server-Sent Events** stream. The client sent messages over ordinary HTTP POST on a separate endpoint. That asymmetry was the core problem. You ran one persistent streaming connection plus a stateless request channel, and each could fail on its own. Reconnection logic, session-ID correlation, and split error handling all got complicated. The long-lived stream also fought serverless runtimes, where holding a connection open per client is awkward and load balancers can route the two channels to different instances. Streamable HTTP fixes this with one endpoint. The client sends every message as an HTTP POST. The server replies with either a plain JSON response or, when it needs to stream, an event-stream chunked body on that same POST. There is no separate always-open channel to keep alive. The wins are concrete. It runs cleanly on Cloudflare Workers and AWS Lambda. A session-ID header lets a client resume after a disconnect rather than starting over. Load balancing is simpler because most requests are ordinary POSTs. Streaming stays available but is now optional per response.