SSE (Server-Sent Events) Transport

SSE transport is the original mechanism the Model Context Protocol used for remote servers. The client opened a persistent Server-Sent Events connection to receive messages from the server, while sending its own JSON-RPC messages through separate HTTP POST requests to a companion endpoint.

Server-Sent Events itself is a long-standing web standard: a one-directional HTTP stream where the server pushes text events to a connected client. MCP borrowed it to give remote servers a way to push responses and notifications back to clients, since plain HTTP request/response has no native server-push channel.

An MCP client connecting over SSE transport first issued a GET request to the server's SSE endpoint, establishing the event stream. The server's first event told the client which URL to POST its messages to. From then on, the client POSTed JSON-RPC requests to that URL and read responses off the SSE stream.

Splitting the conversation across two endpoints worked, but it created operational friction: the long-lived GET connection had to survive proxies, load balancers, and serverless platforms that dislike held-open requests, and the server had to correlate POSTed requests with the right open stream.

The MCP specification replaced HTTP+SSE with Streamable HTTP transport, which collapses both directions into a single endpoint. The client POSTs a JSON-RPC message and the server replies with either a plain JSON response or, when it needs to stream, a server-sent event stream on that same response — no separate standing connection required.

The single-endpoint model is friendlier to standard web infrastructure: stateless deployments, CDNs, and middleware all see ordinary HTTP requests. That includes payment middleware — a Streamable HTTP server can return an HTTP 402 challenge per request, which is awkward to retrofit onto a held-open SSE stream.

SSE transport is deprecated but far from gone. Many remote MCP servers deployed before the transition still expose an SSE endpoint, and most major clients retain backward-compatible support, often falling back to SSE when a Streamable HTTP connection attempt fails.

If you operate a remote server that only speaks SSE, migrating to Streamable HTTP is worth scheduling: new clients increasingly assume it, the spec treats it as the current standard, and monetization tooling targets it. If you are choosing a transport for a new server in mid-2026, there is no reason to start with SSE.

The Loomal Index lists remote MCP servers across both transports, and the distinction matters when a listing is claimed for monetization. Loomal's x402 payment flow gates each tool call with an HTTP 402 response before the handler runs — a per-request pattern that maps cleanly onto Streamable HTTP.

Server owners still running legacy SSE endpoints typically migrate transports as part of claiming and pricing their listing, which also future-proofs the server for clients that have dropped SSE fallback.