MCP tool call ran twice in Claude Code: can Sume bill it twice?

Claude Code 2.1.287 fixed an MCP connector tool call that could occasionally run twice, or whose calls failed until restart, when its server changed which MCP protocol version it supports. For a paid Sume tool the protection is the idempotency_key that hosted MCP requires on every write and paid call, plus a read of jobs_list to see what actually exists.

The fix is from the Claude Code changelog, October 1, 2026 entry, read 2026-10-01. The changelog does not say how often it happened or which servers were affected, so this post only covers what to check on the Sume side.

What does idempotency_key do on a Sume MCP call?

Sume's tools and gates page says idempotency_key is required on write and paid tools and is a stable key for transport and dedup, not human approval. The Videos reference describes the REST equivalent: send an Idempotency-Key to make retries safe, and a replay returns the original job. A duplicate call that carries the same key is a replay, not a second charge.

When is a double run actually a double charge?

Only when the two calls carry different keys. A client that regenerates the argument object on its own would create a new key each time; a client that resends the same message would not. The table shows the cases to separate.

How do I check for a duplicate job?

Call jobs_list and look for two jobs created within seconds of each other with the same input. If a second job exists and has not started, jobs_cancel can stop it. The jobs page says cancellation succeeds only before generation work starts; after that the API returns 409 job_generation_already_started and the job runs to completion.

How do I keep it from happening on my side?

Pick the key per intent, not per attempt: derive it from the task, such as a ticket id and shot number, and reuse it on any retry. Do not resubmit a paid create because a tool call errored; read the job first. Sume's docs say the same for polling: do not resubmit the original paid request just because a local process timed out. Spend can also be capped per call with the optional max_spend_usd.