Goose MCP HTTP retries and Sume paid calls: reuse the key

When goose retries an MCP HTTP call to Sume, the same idempotency_key keeps a paid generate call a dedup, not a second job. Check status before resubmitting.

4 min readSume
All posts

If goose retries an MCP HTTP call to Sume, the idempotency_key in the tool arguments is what keeps the retry safe: Sume's docs require it on every write and paid tool and describe it as a stable key for transport and dedup. Reuse the same key for the same intended job, and check job status before ever submitting a new one.

goose 1.51.0 (2026-09-17) lists the bug fix "MCP preferred version and HTTP retries (#12066)". The release notes say nothing more about how retries behave, so this post covers the Sume side only: Errors and credits and MCP tools and gates, read 2026-10-01.

What do the Sume docs say about retrying a submit?

Under rate limits, the docs say to back off on 429, use retry-after when present, and not retry unsafe submit requests without an Idempotency-Key. For MCP the equivalent is the idempotency_key argument. The same row says it is not human approval, so a retry with the same key is dedup, and a new key means a new request.

What if a retried call times out locally?

The jobs docs say not to resubmit the original paid request just because a local process timed out. A timeout means your client stopped waiting, not that the job stopped. Read it back with the job id, or with jobs_status, before deciding anything.

Retry decisions from the Sume docs, read 2026-10-01: https://docs.sume.com/workflows/errors-and-credits
SituationWhat to do
Transport error on a paid tools/callRetry with the same idempotency_key
Local timeoutRead the job by id; do not resubmit the paid request
429Back off; use retry-after when present
Need a different generationNew request, new idempotency_key
Unsafe HTTP submit with no Idempotency-KeyDo not retry

How should goose's model generate the key?

The key should be stable per intended job, not per model turn. A model that writes a fresh random key on every attempt defeats the dedup. If your setup lets you wrap the tool call, mint the key outside the model and pass it in. For the broader goose setup, see goose as an MCP client for Sume.

How do I confirm only one job was created?

Read the job by id when you have one. Sume's MCP tools include jobs_status and jobs_result, and the docs list a batch jobs_wait that takes job_ids. If a call never returned an id, retry with the same key rather than a new one, then read the result. dry_run=true previews cost and admission without submitting, which is useful when you are testing a retry path.

Sources

Related posts

More in Developers

All Developers posts

Written by Sume