Is SSE better than WebSockets for MCP?

SSE is the recommended default because it is one-directional, plain HTTP, and needs no special proxy configuration. WebSockets add complexity that most MCP streaming use cases do not need.

What happens if the client disconnects mid-stream?

The server's close handler should remove the session from its connection map immediately so no tool handler tries to write to a dead connection.

Can stdio servers stream too?

Stdio can deliver notifications, but true concurrent multi-client streaming needs the HTTP/SSE transport since stdio is tied to a single client process.

advancedTechArticle

MCP Streaming and Real-Time Data

Stream long-running MCP tool progress and live updates to clients over Server-Sent Events instead of blocking on a single request-response cycle.

Quick Answer / TL;DR

MCP servers stream real-time updates over the HTTP/SSE transport: the client opens a persistent SSE connection, the server keeps a handle to that connection keyed by session, and long-running tools push incremental progress notifications through it instead of returning only a single final response.

Key Takeaways

SSE is the recommended streaming approach for MCP because it is plain HTTP and works through standard firewalls and load balancers.
Track each client's transport by session ID so a long-running tool can find the right connection to push updates to.
Clean up the session map when the connection closes to avoid leaking references to dead clients.

Serving SSE connections

Each client opens a long-lived GET connection that the server upgrades to SSE, and posts subsequent messages to a companion endpoint. Track the transport per session so tool handlers can find the right connection later.

typescript

const connections = new Map<string, SSEServerTransport>();

app.get("/sse", async (req, res) => {
  const transport = new SSEServerTransport("/messages", res);
  const sessionId = crypto.randomUUID();
  connections.set(sessionId, transport);

  res.on("close", () => connections.delete(sessionId));
  await server.connect(transport);
});

app.post("/messages", async (req, res) => {
  const transport = connections.get(req.query.sessionId as string);
  if (!transport) return res.status(404).json({ error: "Session not found" });
  await transport.handlePostMessage(req, res);
});

When to stream versus return a single response

Use streaming for operations with meaningful intermediate progress, such as processing a large dataset or a multi-step agent workflow. For a fast, single-shot lookup, a normal request-response tool call is simpler and has less to break.