Five gates between a Sume MCP write session and your wallet

A write session on hosted Sume MCP has five checks between a prompt and a charge, and only two of them are mandatory every time. The scope grant and the idempotency_key are required. dry_run and max_spend_usd are optional and do nothing unless the agent or your hook supplies them. The fifth, wallet admission, always applies but is a floor, not a budget.

Knowing which gate is which tells you where to add your own control. If a paid tool call has no max_spend_usd, Sume does not invent a ceiling for that call. Put the cap in the prompt template, in a client-side hook, or in the account's balance.

The five gates

From the Sume tools-and-gates and admission pages, read 2026-10-09.

What each gate cannot do

The idempotency key does not ask anyone's permission. A model can generate a fresh key for every loop iteration and Sume will treat each as a new job. It protects against double charges on one retry, not against a model deciding to buy ten more clips.

Admission is not a budget either. It checks that the estimated cost can be reserved and that the workspace has capacity. An agent that stays within the balance and the queue can still spend all of it. The legacy allow_write and allow_paid arguments are accepted for back compatibility, are not required, and cannot bypass a missing mcp:write scope.

Where to put your own cap

Pick one layer you control and make it fail closed.

• Template: require max_spend_usd in every paid tool call your prompt describes.
• Hook: in clients that support pre-tool hooks, refuse paid calls that lack the field.
• Batching: for three or more same-shape calls, script_run has max_calls and max_paid_calls limits inside the run.
• Account: keep the wallet balance only as large as you would accept losing in one bad loop.

A concrete sequence

Picture an agent asked for three product stills. It calls tools_list to confirm it has generate_image, runs generation_admission_preview to see the estimate and the balance, then submits each image with its own idempotency_key and a max_spend_usd that you wrote into the instructions. If the network drops after one submit, it resends that call with the same key and gets the original job back instead of a second charge.

Every step in that sequence is something the agent or your template chooses to do. The server enforces the scope, the key requirement and admission; the rest is discipline you build. Treat the optional gates as defaults you add to your prompts, and test them by asking the agent for something over the cap and checking that the call is refused or never made.