adminCreateCreditGrant

Mints credit for one org. It is the ONE admin mint surface, and it does NOT mint in-process: it forwards the request to commerce's already-mint-gated POST /v1/billing/credit-grants, authenticated by the service token and scoped to the target org, then writes one tamper-evident compliance record. Commerce stays the sole credit ledger; this is a thin, audited relay so there is exactly one place credit is created.

The body is commerce's OWN CreateCreditGrant contract, forwarded whole — every field it carries reaches commerce. The only two this layer reads are the target org (org, or user as the org-pool alias), which selects the namespace commerce's EdgeAuth trusts, and idempotencyKey, which makes a double-clicked grant credit once.

A FAILED grant is audited too, with the request body attached: an attempted mint is exactly as interesting to a compliance auditor as a successful one.

Arguments

This tool declares no arguments. Call it with an empty arguments object.

Call it

A tools/call carries its arguments in one flat object. This tool declares none, so the object is empty.

curl -X POST https://api.hanzo.ai/v1/mcp \
  -H "Authorization: Bearer $HANZO_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
       "jsonrpc": "2.0",
       "id": 1,
       "method": "tools/call",
       "params": {
         "name": "adminCreateCreditGrant",
         "arguments": {}
       }
     }'

tools/list needs no credential; tools/call does — called without one the door answers HTTP 200 with a JSON-RPC result whose isError is set and whose text says what was missing. How to get a key →

The operation behind it

The same capability over plain HTTP is in the cloud API reference, on https://api.hanzo.ai.

All 834 tools · The door · API reference

Generated from tools/list on https://api.hanzo.ai/v1/mcp — 834 tools captured 2026-08-01 (this build read the vendored copy; the door was unreachable).