MCP SSE vs Streamable HTTP

MCP SSE and Streamable HTTP are the two HTTP transports the Model Context Protocol has defined for remote servers. The HTTP+SSE transport from revision 2024-11-05 split each client across a long-lived GET stream and a separate POST endpoint; Streamable HTTP, which replaced it in revision 2025-03-26, sends every message as a POST to one endpoint and streams a reply only when a request needs it.

The comparison matters because the HTTP+SSE transport is now formally deprecated and eligible for removal, and the current specification revision, 2026-07-28, changed Streamable HTTP again: no sessions, no GET stream, no stream resumption. Both transports sit under the same JSON-RPC messages described in the Model Context Protocol overview, so the choice affects deployment, not tools.

Bifrost, the open-source AI gateway, connects to upstream servers over either transport and gives clients one endpoint in front of them.

How MCP SSE differs from Streamable HTTP

MCP SSE differs from Streamable HTTP in where responses travel. Under HTTP+SSE, a client holds one server-sent events (SSE) stream open, and every response to every POST comes back on that stream. Under Streamable HTTP, each request is its own POST, and the response comes back on that same HTTP exchange as JSON or as a short SSE stream.

Removing the held-open connection means a simple mcp server on Streamable HTTP behaves like any request-response web service, opening an SSE stream only to send progress before a final result. The MCP endpoint is the one URL that takes all of those POSTs.

MCP SSE vs Streamable HTTP at a glance

The MCP SSE vs Streamable HTTP comparison has three columns, not two, because Streamable HTTP itself changed shape in 2026. The table compares the HTTP+SSE transport, the Streamable HTTP revisions from 2025-03-26 to 2025-11-25, and the current 2026-07-28 revision.

How each transport works on the wire

On the wire, HTTP+SSE starts with a GET that never finishes, while Streamable HTTP starts with a POST that finishes as soon as the result is ready.

Figure 1: HTTP+SSE ties every response to one long-lived stream; Streamable HTTP returns each response on the request that asked for it.

Under HTTP+SSE, the server's first SSE event, named endpoint, gives the client its POST URL, and each result later arrives as an SSE message event on the open stream:

GET /sse HTTP/1.1
Accept: text/event-stream

event: endpoint
data: /messages?session_id=9f1c2a

POST /messages?session_id=9f1c2a HTTP/1.1
Content-Type: application/json

Under Streamable HTTP, one POST carries the request and the result returns on the same exchange:

POST /mcp HTTP/1.1
Accept: application/json, text/event-stream
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: get_weather

How one endpoint serves POST and GET

In the 2025 revisions, one MCP endpoint accepted both methods: POST carried client messages, and an optional GET opened a standalone SSE stream for server-initiated messages, or returned 405 when the server offered none. Revision 2026-07-28 dropped the GET stream; clients that want change notifications such as notifications/tools/list_changed send a subscriptions/listen POST whose response stream stays open.

When a response becomes an SSE stream

A Streamable HTTP server upgrades a response to Content-Type: text/event-stream when it has something to send before the final result, such as notifications/progress or log messages for a long tool call. Otherwise it returns application/json. Clients must accept both on every POST, because the server chooses per request.

Why was the HTTP+SSE transport deprecated?

The HTTP+SSE transport was deprecated because it forced every client to hold a connection open and forced the server to route each response to the right stream. The 2025-03-26 changelog replaced it with Streamable HTTP, and the 2026-07-28 changelog reclassified it as Deprecated under the feature lifecycle policy, eligible for removal.

The design created four operational problems:

• Split request and response. A POST could land on server instance B while the client's stream lived on instance A, so instances needed shared messaging, or the load balancer had to pin both connections to one instance.
• Connection count. Every idle client still consumed a held-open connection, which collides with proxy idle timeouts and serverless platforms that end a request when it returns.
• No recovery. A dropped stream lost any responses in flight; the 2024-11-05 revision defined no resume mechanism.
• Awkward authentication. The browser EventSource API, defined in the WHATWG server-sent events specification, cannot set an Authorization header, which pushed browser-based clients toward cookies or tokens in the URL, a pattern current MCP authentication rules forbid.

The article on MCP transports and the message lifecycle maps these messages onto JSON-RPC.

Sessions and resumability in Streamable HTTP

Sessions and resumability existed in Streamable HTTP from 2025-03-26 through 2025-11-25 and were removed in revision 2026-07-28. A server built for the current revision ignores both, so check which revision each side negotiates.

In the 2025 revisions, a server could return an Mcp-Session-Id header with its initialize response. The client sent that header on every later request, a server answered an expired session with 404, and the client ended a session with DELETE. To resume a dropped stream, the client issued a GET carrying Last-Event-ID, and the server replayed events from that stream only.

Revision 2026-07-28 has no initialize handshake and no protocol sessions; protocol version and capabilities travel in each request's _meta. Servers that need state across calls mint explicit handles and pass them as ordinary tool arguments. A broken response stream loses the in-flight request, and the client re-issues it with a new request ID. The MCP specification topic explains how the revisions negotiate with each other.

Load balancers, proxies and API gateways

A Streamable HTTP server on revision 2026-07-28 scales behind a load balancer like any stateless HTTP service: any instance can answer any POST, so sticky routing is no longer required. HTTP+SSE, and session-based 2025 deployments, need session affinity or shared state, because later requests must reach the instance that holds the stream or session.

The current revision adds three details that matter for infrastructure:

• Proxy buffering. Servers should send X-Accel-Buffering: no when opening an SSE stream so reverse proxies such as nginx forward events immediately, and long-lived subscriptions/listen streams should emit SSE comment lines as keep-alives.
• Routing without parsing JSON. Every POST mirrors body fields into MCP-Protocol-Version, Mcp-Method and Mcp-Name headers, so an api gateway can apply rate limiting, logging or role-based access control (RBAC) per MCP tool. The server rejects any header that does not match the body with 400 and error -32020.
• Standard authentication. Every request is an ordinary POST, so an OAuth bearer token rides in the Authorization header on each call.

Intermediaries that enforce policy on mirrored headers should reject versions older than 2026-07-28, which did not validate headers against the body. An MCP gateway applies these controls once for many servers, and the post on the protocol, the plumbing and the gateway traces one request through one.

Choosing stdio, SSE or Streamable HTTP

MCP transports compare to stdio by where the server runs: choose stdio for local servers on the client's machine, Streamable HTTP for any server reached over a network, and HTTP+SSE only to talk to a server that has not migrated. Under stdio, the client starts the server as a subprocess, exchanging newline-delimited JSON-RPC over standard input and output, so there is no URL, port or network authentication. The MCP architecture of hosts, clients and servers is the same on every transport.

Migrating an SSE server to Streamable HTTP

The specification's backward-compatibility rules let both transports run during a migration:

1. Keep the old endpoints. Continue serving the SSE and POST endpoints alongside the new MCP endpoint until clients move.
2. Pick a target revision. Implement 2026-07-28 for new clients, and the 2025-11-25 behavior if older Streamable HTTP clients still connect.
3. Update clients to probe. A client POSTs to the server URL first; on 400, 404 or 405 without a recognized modern JSON-RPC error, it issues a GET and treats an endpoint event as a legacy server.
4. Remove the SSE endpoints once traffic logs show no legacy clients.

How an MCP server works covers what sits behind either transport, and the Model Context Protocol overview places transports in the protocol.

MCP SSE and Streamable HTTP with Bifrost

Bifrost, the open-source AI gateway built by Maxim AI, takes the MCP SSE vs Streamable HTTP choice away from clients. As an MCP gateway, Bifrost connects to upstream MCP servers over STDIO, HTTP or SSE per server, and exposes their combined tools at one /mcp endpoint that accepts JSON-RPC over POST and serves an SSE stream on GET.

Figure 2: The transport choice moves to the gateway, so clients keep one URL while upstream servers migrate at their own pace.

Each upstream connection type behaves differently:

• HTTP connections default to per-call mode: Bifrost opens a fresh connection for each tool call and closes it, so a failed upstream credential affects only the calls made while it is broken. Session stickiness reuses one shared connection with a health-checked reconnect.
• SSE and stdio connections are always sticky, because an SSE session is bound to its open stream and stdio needs a persistent subprocess.
• Protocol version. A max protocol version setting, auto (currently 2026-07-28) by default on fresh installs, can cap one server at 2025-11-25 or 2025-06-18 when it misbehaves on the latest revision.

Bifrost health-checks every connection every 10 seconds with ping or tools/list, and retries transient failures up to 5 times with exponential backoff from 1 to 30 seconds.

On the client side, gateway authentication accepts virtual keys or OAuth 2.1, and tool filtering limits what each key can list and call.

To put one endpoint in front of your SSE and Streamable HTTP servers, follow the gateway quickstart and add each server with its connection type.

Frequently asked questions

Is MCP SSE deprecated?

Yes. The HTTP+SSE transport from revision 2024-11-05 has been deprecated since revision 2025-03-26, and revision 2026-07-28 classifies it as Deprecated under the MCP feature lifecycle policy, eligible for removal in a future revision. New servers should not adopt it; existing servers should migrate to Streamable HTTP and can keep the old endpoints running during the transition.

Is MCP Streamable HTTP actually streaming?

MCP Streamable HTTP streams only when the server chooses to. For each request, the server returns either a single application/json object or a text/event-stream response that carries progress notifications before the final result. Short tool calls usually return plain JSON.

Does Streamable HTTP use WebSockets or require HTTP/2?

Streamable HTTP uses neither WebSockets nor any HTTP/2 feature. It is defined entirely with HTTP methods, headers and server-sent events, so it runs over HTTP/1.1 or HTTP/2 through ordinary proxies. Server-sent events are a one-way text stream from server to client, which is why every client message is a separate POST.

Can one MCP server support both SSE and Streamable HTTP?

One MCP server can support both by hosting the legacy SSE and POST endpoints alongside the new MCP endpoint. Clients detect which transport a URL speaks by POSTing first and falling back to a GET that expects an endpoint event.

What replaced the GET stream in Streamable HTTP?

The subscriptions/listen request replaced the GET stream in revision 2026-07-28. The client POSTs subscriptions/listen with the notification types it wants, such as tool list changes or resource updates, and the server keeps that response stream open to deliver them. Progress notifications still flow only on the response stream of the request they belong to.

• sse vs streamable http
• streamable http vs sse
• mcp sse
• mcp streamable http
• mcp transport
• mcp stdio