MCP 2026-07-28 drops SSE resume: re-send with Sume idempotency_key

A dropped MCP response stream now loses the in-flight request, so clients re-issue it. How Sume's idempotency_key stops a re-sent paid create billing twice.

4 min readSume
All posts

Under the 2026-07-28 MCP revision, if a response stream breaks, the in-flight request is lost and the client must send it again as a new request with a new request ID. The changelog, read on 2026-10-04, removes SSE resumability and Last-Event-ID, so the old trick of resuming a stream from the last event id is gone. For a paid tool call, the only safe way to re-send is a key that makes the retry the same operation: on Sume, that is idempotency_key.

What exactly changed?

The changelog states that clients MUST re-issue the request after a broken stream, with a new request ID. The request ID is therefore not an identity for the work. The same revision also removes sessions, so there is no session to resume either.

How does Sume make a re-send safe?

Sume's MCP tools and gates page requires an idempotency_key on every write and paid tool, described as a stable key for transport and de-duplication. Pick the key from the work, not from the request: a hash of the prompt and shot number, or a stable id from your own queue. When the client re-issues after a broken stream, send the same key.

Agent Completions state the rule explicitly for the HTTP API: sending a key again returns the original receipt with idempotency_hit: true, and the same key with a different payload returns 409 idempotency_conflict. See the Agent Completions page.

What is the retry procedure?

Steps based on the MCP 2026-07-28 changelog and Sume's tools and gates page, read 2026-10-04.
StepAction
1Build the idempotency_key from the work, such as a shot id.
2Call the create tool. If the stream breaks, you do not know the outcome.
3Re-issue with a new request ID and the same idempotency_key.
4Read the job with jobs_status or jobs_wait, never a second create.
5On a conflict, you changed the payload; fix it and keep the key.

What about scripts?

Inside script_run, each paid create needs its own distinct key, for example a prefix plus the loop index, and the script returns a calls[] journal and the child jobs[]. If the stream drops while a script was running, re-send the script with the same keys, so any create that registered a job returns it rather than starting a second one. The tool description says never to resubmit a create that already registered a job.

Keep the wait separate. jobs_wait is read-only, holds for up to 55 seconds per slice and takes up to 20 ids, so repeating it after a broken stream costs nothing. The Jobs and results page covers the status values.

Sources

Related posts

More in Developers

All Developers posts

Written by Sume