Streamable HTTP carries long-running results and notifications over an SSE stream. SSE is robust to reconnects by design: each event has an optional id field, and a client that disconnects can reconnect with a Last-Event-Id header asking for everything since that id.
MCP builds on this with explicit resumability: a server that supports it issues monotonically increasing event ids, retains a window of recent events in memory, and on reconnect re-emits everything since the client's Last-Event-Id. From the client's view, a network hiccup looks like a brief stall instead of a lost result.
Resumability is how long-running tools survive flaky networks. Without it, a 10-minute build that streams progress notifications turns into a 10-minute lost connection if the client's wifi drops at minute 7. With it, the client reconnects at minute 7-and-a-half and gets the missed events plus the eventual completion.
The cost is a buffer the server has to hold. Most production servers cap the buffer at something like 5,000 events or 5 minutes — enough for a typical reconnect, not enough to memory-leak. Buffer eviction policy and limits are server choices the client cannot control; clients should be prepared to receive a fresh-start signal if they wait too long to reconnect.