MCP Removed Stream Resumability. What Happens When Your Bot's Call Drops?

What MCP actually removed

Editorial correction (October 14, 2026): an earlier version treated every dropped request as definitely stopped, described older stream replay as guaranteed, and said the current transport has no long-lived SSE stream. The specification supports narrower claims: response replay was removed, cancellation asks a server to stop as soon as practical, and subscriptions/listen still uses a long-lived response stream.

The 2026-07-28 MCP changelog removes SSE stream resumability and message redelivery from Streamable HTTP, including Last-Event-ID and SSE event IDs. A broken response stream loses that in-flight request; a client that wants to try again must send a new request with a new JSON-RPC ID. This is a change in transport recovery, not a guarantee about whether a tool already wrote a record or sent an email.

The current transport still permits an SSE response for each POST. It also has subscriptions/listen, whose POST response can stay open for opted-in change notifications. What disappeared is replaying a broken response from an event ID, along with the old GET endpoint and protocol-level sessions. Do not turn “no resumability” into “no SSE” or “no long-lived streams.”

Sources: Key Changes - Model Context Protocol, Streamable HTTP - Model Context Protocol.

What a disconnect tells the client

When the client closes an SSE response stream, the 2026-07-28 Streamable HTTP specification says the server must treat that as cancellation, should stop work as soon as practical, and must send no further messages on that stream. “Should stop as soon as practical” is not an atomic rollback. Work may already have finished, or an external side effect may have committed before the disconnect was noticed.

The client therefore knows that it cannot recover the missing response through Last-Event-ID. It does not know from the transport alone whether the requested operation completed, partially completed, or stopped before doing anything. A proxy timeout, lost Wi-Fi connection, or server restart can all leave the client without a final result; the observable failure and the durable business outcome are different facts.

For a read-only tool, a fresh request is often a straightforward recovery. For a write, first query the operation state if the service exposes one. If it does not, surface the outcome as unknown and require reconciliation. Retrying a payment, email, or mutation merely because the stream vanished can duplicate work. The specification tells the client how to retry the protocol request; it does not grant exactly-once execution to the underlying tool.

Sources: Streamable HTTP - Model Context Protocol, Key Changes - Model Context Protocol.

Worked example: a report tool loses its response

Imagine a bot calls generate_quarterly_report to build a document and email it to a team. Twenty seconds into an illustrative run, Wi-Fi drops. The client has not received the final tools/call result. Perhaps the server noticed the disconnect before sending the email. Perhaps the email provider already accepted the send. The missing SSE response cannot distinguish those cases.

Give the report job a stable business key such as report:2026-Q3:team-42, generated by the application and reused on a retry. The tool records that key and its state durably before starting the expensive work. When the client reconnects, it first reads that state: completed returns the existing report; in progress waits or polls; absent may start a new operation. The new MCP request has a new JSON-RPC ID, while the application key stays the same. A request ID is for protocol correlation, not business deduplication.

A server might honor cancellation quickly, but it cannot retract an email already accepted by another service. If the tool cannot expose durable state or enforce a unique business key, the safe client behavior after an ambiguous disconnect is to stop automatic retries and ask a human to reconcile the send. That is slower than blind retry, but it avoids turning uncertainty into duplicate mail.

On older Streamable HTTP revisions, a server could support Last-Event-ID replay if it issued event IDs and retained the messages. That was an optional capability with server-side storage, not a guarantee that every 2025-11-25 deployment could resume a call or undo side effects. Check the actual negotiated version and server behavior before relying on either recovery path.

Sources: Streamable HTTP - Model Context Protocol, Key Changes - Model Context Protocol, Streamable HTTP transport (2025-11-25).

A safer retry checklist

Start by logging the negotiated MCP version, the tool name, the new request ID, the application operation key, and whether a final response arrived. Keep secrets and full tool payloads out of these logs. A cluster of disconnects at a fixed duration points to an idle timeout worth inspecting, but timing alone does not tell you whether the side effect happened.

For 2026-07-28, remove code that assumes a Last-Event-ID can replay a broken tools/call response. Send a new request only after classifying the tool as read-only, idempotent with a stable key, or unsafe to retry without readback. If a long-running operation needs durable progress, evaluate the optional Tasks extension and its polling model, but verify that both client and server implement it. The transport change alone does not install task persistence for you.

• Confirm the negotiated protocol version and the server’s actual capabilities; older resumability was optional.
• For read-only calls, issue a fresh request with a new JSON-RPC ID when retry policy allows.
• For writes, look up the durable outcome first or reuse a server-enforced business idempotency key.
• Treat an interrupted call to an uncontrolled write tool as unknown; reconcile before retrying.
• Test disconnects before and after side effects, including proxy timeouts and replica restarts.

Sources: Key Changes - Model Context Protocol, Streamable HTTP - Model Context Protocol, Versioning - Model Context Protocol.