MCP stream dropped: re-issue with the same idempotency_key

The new JSON-RPC request ID and the Sume idempotency_key are different things. When a stream drops, the MCP spec has you send a new request with a new request ID. On a paid Sume tool, put the same idempotency_key in that request, as long as it is the same operation and payload. Do not mint a fresh key.

The protocol rule is from the MCP 2026-07-28 changelog, read 2026-09-30. Key behavior is from Sume's MCP tools and gates and Jobs and results.

What changed in the MCP spec?

Major change 9 in the changelog removes SSE stream resumability, meaning the Last-Event-ID header and SSE event IDs, from the Streamable HTTP transport. It states that a broken response stream loses the in-flight request, and clients must re-issue it as a new request with a new request ID. The server will not replay the lost response for you.

Is a re-issued request a second job on Sume?

Not if the key stays the same. Paid and write tools require an idempotency_key, described as a stable key for transport and dedup, not human approval. On the REST path, the docs say a retry with the same Idempotency-Key returns the original job instead of billing a second one. The MCP docs I read do not spell out the replay result for each tool, so treat the key as the dedup handle and confirm with jobs_status if unsure.

When must the key change?

Reuse the same key only for the same operation and payload. A different payload on the same key returns 409 idempotency_conflict. So edit the prompt and you need a new key; lose the stream and you keep the old one.

What if the wait dropped but the job was already created?

A transport failure on jobs_wait is never a job outcome. Re-issue jobs_wait on the same ids, or read jobs_status once, and do not resubmit the paid create. Store the job id from the first response whenever you got one. See idempotency keys for AI video APIs for the general pattern.