Is an idempotency_key an approval step on Sume MCP? No, it is dedup

No. Sume's docs describe the idempotency_key as a stable key for transport and dedup, 'not human approval'. It is required on write and paid tools, so a retry of the same call returns the original job instead of billing twice. It does not ask anyone whether the spend is wanted. If you need a person in the loop, you have to build that check somewhere else.

What each gate does

The rows come from the gates table on the tools and gates page and the OAuth page. The legacy allow_write and allow_paid arguments are accepted but cannot bypass a missing mcp:write scope.

Where a human check can live

The cleanest one is the OAuth consent page: leave Write off, and the paid tools are not even listed, so no prompt can reach them. After that, your client's own confirmation prompts are the next layer, and which tools they cover depends on the client's settings.

For unattended agents, replace the human with a cap: pass max_spend_usd on every paid call, run dry_run before a burst, and keep the wallet balance small enough that the worst case is acceptable.

• Do not describe an idempotency_key to a user as 'safety'; it is retry safety only.
• Generate a new key for each intended create, and reuse the key only for a retry of that same create.
• Ask the user in chat before expensive or destructive actions, as Sume's server instructions say.

The tradeoff

Keeping approval out of the server means Sume does not slow down automated pipelines with prompts nobody will answer. The cost is that the server will accept a well-formed paid call from a confused agent, so the controls have to be set up front, by you, at connection time.