Claude Code hooks on Sume tool calls: check the top-level guards

If you run a Claude Code hook that inspects Sume tool calls, read the top-level arguments idempotency_key, dry_run and max_spend_usd, and deny when you cannot read them. The job body, such as the prompt and model, sits in the nested payload, which a spend guard does not need to parse.

Where do Sume's gates sit?

Per the MCP docs, paid and write tools require idempotency_key. dry_run=true returns an admission and cost preview without submitting. max_spend_usd is optional and enforced only when you provide it. These are top-level tool arguments. The request body for the job goes in the nested payload.

What should a spend hook check?

A hook that blocks spend should read only the top level and fail closed:

• Deny a paid tool call when idempotency_key is missing.
• Deny it when max_spend_usd is missing, if your policy requires a cap. Sume itself does not.
• Treat an unreadable or empty input as a deny, never an allow.
• Do not parse payload to guess a price. Use dry_run or generation_admission_preview.

Is a hook enough?

No. A hook runs on the client. The scope is the server-side limit: OAuth mcp:read hides write and paid tools entirely, and there is no mcp:paid scope. See Safe automation for the split.