Hanzo
OpenapiTools

Runs one of the caller's activated tools and answers with its output.

Runs one of the caller's activated tools and answers with its output.

POST /v1/tools/call

Addresshttps://api.hanzo.ai/v1/tools/call
MethodPOST
Operationpost_tools_call
AuthAuthorization: Bearer $HANZO_API_KEY

Runs one of the caller's activated tools and answers with its output.

This is the door onto the tool plane's DYNAMIC half — the half no build-time catalogue can hold, because it is per-tenant: an org's connected connector actions, its authored skills, its agents and functions, and the tools of every external MCP server it registered. A tool's existence, its price and its activation are all rows, not code, so they cannot be known until the caller is.

One policy, the registry's: resolve by precedence, refuse an unactivated tool 403, settle a priced one through the x402 seam or fail closed 402, then dispatch to the winning source bound to the caller's own (org, project). One metered unit, one audit record. A caller can only ever dispatch its own tools.

Discovery is GET /v1/tools — ?activated=true for the callable set.

Request

3 fields, body application/json (required).

FieldInTypeRequiredDescription
argumentsbodyobjectArguments is the tool's own input object, passed through verbatim to whichever source owns it.
arguments.*bodyobject
namebodystringName is the tool to run, exactly as GET /v1/tools reports it.

Response

StatusBodyMeaning
200toolResultok

200 body — 2 fields.

FieldInTypeAlwaysDescription
namebodystringName is the tool that ran.
resultbodyobjectResult is the tool's own output, verbatim — its shape is the tool's, not this plane's.

Failure carries the platform error shape — see Errors.

Examples

hanzo tools call

Tools API · All Hanzo APIs · Interactive reference

How is this guide?

On this page