Streaming Replies with SSE

Some tools take time: a long search or a slow API call. Instead of making the client wait in silence, the server can stream updates as they happen. ⏳

Streamable HTTP streams using Server-Sent Events, or SSE. It is a simple, web-native way for a server to push a sequence of messages over one open connection.

SSE flows in a single direction: server to client. The server keeps the connection open and pushes events down it whenever it has something new to say.

You know a reply is a stream by its Content-Type. When the server sets it to text/event-stream, the client reads events instead of one final body.

Each SSE event is just text. Lines starting with data: carry the payload, and a blank line marks the end of one event before the next begins.

Inside each event sits a familiar JSON-RPC message. Streaming does not invent a new format; it just delivers the same messages over time.

A streaming reply can send progress notifications first, then the final result last. The user sees the tool is working instead of staring at a spinner.

Streaming is optional. For a fast tool, the server can just return a single JSON response and close, with no event stream needed at all.

SSE lets the server tag events with an id. That tiny detail becomes important later: it is how a client can resume a stream after a dropped connection.

You rarely write raw SSE by hand. The MCP SDK formats events for you; you simply send progress and results, and it streams them correctly.

Streaming does not change what a tool returns, only how it feels. The final answer is identical; the user just gets a smoother, more responsive experience. ✨

How does a server signal that a reply is a live stream?

SSE lets the server push JSON-RPC events down one open connection: progress first, result last. It is optional, web-native, and makes slow tools feel fast. 🎉