Server-Sent Events (SSE)
Also written SSE
Server-Sent Events is a one-way streaming format where a server pushes text events over a held-open HTTP response. MCP uses it inside the Streamable HTTP transport when a server needs to send several messages for one request. The older standalone HTTP+SSE transport it also named is deprecated.
Updated
Is SSE deprecated in MCP?
The HTTP+SSE transport is. SSE itself is not.
Streamable HTTP replaced the two-endpoint HTTP+SSE transport in the 2025-03-26 revision. The 2026-07-28 revision then listed HTTP+SSE in the specification's registry of deprecated features, with Streamable HTTP as the migration path. Deprecated means it is still in the specification but scheduled for removal: new implementations should not adopt it, and existing ones should move. The registry puts its earliest removal at three months after the lifecycle policy that reclassified it (SEP-2596) reaches Final.
SSE as a format is still how Streamable HTTP streams a response. What 2026-07-28 removed is resuming a broken stream: the Last-Event-ID header and event IDs are gone, so a client re-sends an interrupted request as a new one.
What is SSE?
Server-Sent Events is a standard web format for streaming. The server holds an HTTP response open and writes discrete text events down it, and the client reads them as they arrive. It is one-directional: the server pushes, the client listens.
It predates MCP and is used far beyond it.
What does SSE do in MCP today?
It is the streaming half of Streamable HTTP. When a server has more than one message to send in response to a single POST, it answers with Content-Type: text/event-stream and writes the messages as events instead of returning one JSON body.
A client therefore has to handle both response shapes from the same endpoint. Reading only JSON and treating an event stream as a parse failure is a common implementation mistake.
Why is the acronym confusing?
Because it also names an entire transport, and that transport is on its way out. The earlier HTTP+SSE transport used two endpoints, a held-open SSE connection plus a separate POST URL, and it is deprecated in favour of the single-endpoint design.
So "SSE" in an older tutorial usually means that two-endpoint transport, while "SSE" in a current one usually means the streaming response mode inside Streamable HTTP. The words are identical and the architectures are not.
Example
A server answering a tools/list POST can reply two ways: Content-Type: application/json with one body, or Content-Type: text/event-stream with the same JSON-RPC response delivered as an event. Both are correct under the current transport, and a client that only anticipated the first will report a working server as broken.