post_v1_wallets_id_keys
Rolls one wallet's signing material through its own custody backend and answers the wallet with whatever address that produced.
Rolls one wallet's signing material through its own custody backend and answers the wallet with whatever address that produced. For KMS custody a fresh secp256k1 key is generated and sealed, which CHANGES the address — funds and approvals at the old address do not move. For a Safe the address is counterfactual and the owner shares are ring-managed, so rotation is a no-op and the address is unchanged. A backend that is not configured fails closed with 503 rather than leaving the wallet half-rotated.
| Tool | post_v1_wallets_id_keys |
| Door | https://api.hanzo.ai/v1/mcp |
| Method | tools/call (JSON-RPC 2.0) |
| Arguments | 0 |
| Operation | POST /v1/wallets/{id}/keys |
| Product | wallets |
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": "post_v1_wallets_id_keys",
"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
| Operation | Route | Product | Summary |
|---|---|---|---|
cloud_post_v1_wallets_id_keys | POST /v1/wallets/{id}/keys | wallets | Rolls one wallet's signing material through its own custody backend and answers the wallet |
The same capability over plain HTTP is in the wallets 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).
How is this guide?