MCP SSE vs Streamable HTTP: which transport to use

SSE and Streamable HTTP are MCP's old and new ways to carry messages over HTTP. The HTTP+SSE transport from protocol version 2024-11-05 used two endpoints: a Server-Sent Events endpoint where the client connects and receives the server's messages, and a separate endpoint for the client's POSTs. Streamable HTTP replaced it with one MCP endpoint, where every client message is a new POST and the server answers with JSON or an SSE stream. HTTP+SSE is now deprecated, so choose Streamable HTTP whenever a server offers it.

The transport rules come from the MCP specification: the 2024-11-05, 2025-11-25, and 2026-07-28 Transports pages and the 2026-07-28 changelog. Client labels come from each client's own docs, and Sume's side from its MCP quickstart and current server code. All were read on 2026-09-28.

What is the difference between SSE and Streamable HTTP?

The old transport splits receiving and sending across two endpoints; the new one takes everything at one endpoint and streams only when the server chooses to. Both are HTTP transports; stdio, where the client launches the server as a subprocess, is compared in Local vs remote MCP server.

Is SSE deprecated in MCP?

Yes. The 2025-11-25 spec says Streamable HTTP replaces the HTTP+SSE transport from 2024-11-05, and the 2026-07-28 changelog reclassifies HTTP+SSE, deprecated since 2025-03-26, as Deprecated under MCP's feature lifecycle policy, with the instruction "Migrate to Streamable HTTP." A deprecated feature stays in the spec for at least twelve months, or ninety days under an expedited-removal exception, before it becomes eligible for removal, and new implementations should not adopt it.

Old and new can still meet. The spec's backward-compatibility steps have a client POST an initialize request to the URL first; if that fails with 400, 404, or 405, the client sends a GET and expects the old SSE stream, with an endpoint event first.

Does Streamable HTTP still use SSE?

Only when the server wants to stream. For each request a client POSTs, the server returns either Content-Type: application/json with one JSON object or text/event-stream to open an SSE stream, and clients must support both. Under 2025-11-25, a client may also GET the endpoint to open a stream for messages the server starts; a server that offers none answers 405 Method Not Allowed. The 2026-07-28 revision replaces that GET stream with a subscriptions/listen request, a long-lived stream for change notifications that the client opts into; every message is still a POST, and replies arrive as a JSON object or a request-scoped SSE stream.

How do MCP clients label the two transports?

Each client names them its own way, so check the label before you pick. From Claude Code v2.1.265, --transport http also reaches SSE-only servers: it tries HTTP first and switches to SSE when the server doesn't accept it.

Which transport does Sume's MCP server use?

Streamable HTTP only. Sume's quickstart says to point a streamable HTTP MCP client at https://mcp.sume.com/mcp, so pick your client's HTTP or Streamable HTTP option, never SSE. In AnythingLLM, set type explicitly, because a missing type means sse (AnythingLLM MCP server setup).

In current code, Sume's mcp_health tool reports transport as streamable_http, and the server answers each POSTed request with a single JSON response rather than an SSE stream. A GET on /mcp, which is how an SSE client connects, gets 401 without a credential; with a valid one it gets 405 and the message "Remote MCP uses POST JSON-RPC requests." So a client set to SSE never gets its event stream. To check a connection yourself, see how to test an MCP server.

Sume's basics page says hosted MCP still works but is not part of the primary path today. n8n's "SSE Endpoint" field label is covered in n8n MCP Client Tool with Sume.