Claude Code mcp_tool hook on PreToolUse for a spend check

An mcp_tool hook runs an MCP tool as a Claude Code hook. As of Claude Code 2.1.282, such a hook on a blocking event like PreToolUse waits for its MCP server to connect instead of being skipped. For a spend check against Sume, the tool worth wiring there is a cost preview: generation_admission_preview, or the paid tool itself with dry_run=true.

What changed in 2.1.282?

The changelog says mcp_tool hooks on blocking events (PreToolUse and similar) were being skipped while their MCP server was still connecting, and that they now wait for it, up to the MCP connect timeout. Before the fix, a guard hook could silently not run at session start, which is the worst failure for a spending check.

Which Sume calls preview cost without spending?

Sume's gates table describes dry_run=true as an admission and cost preview only, with the job not submitted. The docs also say to prefer generation_admission_preview and/or dry_run before expensive bursts, and that ordinary single creates do not need admission theater.

Why not rely on idempotency_key as the approval?

Because the docs say it is not human approval. It only dedups a submit. A hook that previews cost and lets a person decide supplies the approval step the gate does not. If you also want a hard ceiling, max_spend_usd caps spend, but only when you pass it.

Does the hook need a write session?

Paid tools are hidden until the session has mcp:write or an API key, per the tools and gates page. A read-only OAuth session cannot see generate_image to preview it, so grant Write at consent or use an API key before building the hook around a paid tool. generation_admission_preview is listed under account and catalog tools.

What should the hook do with the preview?

Have the hook call the preview, show the estimate to the person, and only allow the real tool call after a yes. The playbook in Sume's docs is written the same way: review the preview first, then repeat the call without dry_run to submit, and only when the user explicitly confirms spend.

Keep the real call's idempotency_key stable between the preview and the submit, since the docs describe it as a key for transport and dedup. After the submit, poll with jobs_status or jobs_wait and read jobs_result, as the playbook lists.