What is the SSE Transport?

In the HTTP+SSE design, the client first issued a GET request to open a long-lived SSE stream. The server's first event was an endpoint event telling the client which URL to POST its JSON-RPC messages to; all server messages then arrived over the SSE stream. This split-endpoint model had practical problems: it forced servers to hold a long-lived connection open for the entire session, made resuming after a dropped connection awkward, and complicated stateless and serverless deployments.

Spec revision 2025-03-26 replaced it with the Streamable HTTP transport, which uses a single MCP endpoint, makes SSE streaming optional per response, and adds session management and stream resumability via SSE event IDs and Last-Event-ID.

Backwards compatibility is explicitly described in the current spec:

• Servers supporting older clients can continue hosting the old SSE and POST endpoints alongside the new MCP endpoint.
• Clients supporting older servers POST an InitializeRequest to the server URL first; if that fails with 400, 404 or 405, they fall back to a GET expecting an endpoint event, which identifies an old HTTP+SSE server.

You will still encounter "SSE" as a label in client configuration files and older server documentation. For new deployments it should be read as legacy: current-spec servers expose Streamable HTTP, which may itself stream responses over SSE — the deprecated part is the two-endpoint transport, not Server-Sent Events as a technology.

PolicyLayer's catalogue at policylayer.com/tools includes servers built across spec generations, and transport choice is part of what a scan observes. The PolicyLayer gateway connects clients over Streamable HTTP, so fleets fronted by the gateway are not dependent on individual upstream servers' legacy transport behaviour.