Tool

Everything your org can call, in one list: connector actions, functions, agents, skills and your own MCP servers.

Also for this capability: API · CLI · MCP · SDKs

Everything your org can call, in one list: connector actions, functions, agents, skills and your own MCP servers.

Base URL	`https://api.hanzo.ai`
Operations	19
Auth	`Authorization: Bearer $HANZO_API_KEY`

Specification

Specification pending — no HIP in hanzoai/hips declares capability: tool yet. What this capability serves is below, from the API document; what it is — the store it owns, how it meters, what it publishes — is written as a HIP under HIP-0139.

Four surfaces

Surface	Reaches this capability as	Coverage
REST	`tool` at its own prefix	19 operations
CLI	`hanzo tool …`	17 of 19 — the CLI pins the document on its own clock
SDK	`ToolApi` in every published client	19 methods
MCP	tool `tool` on `https://api.hanzo.ai/v1/mcp`	17 operations, 3 under the document's own id — ask `describe` for the rest

Quickstart

export HANZO_API_KEY=sk-...   # console.hanzo.ai → API keys

Then the first call — a read that needs nothing but the key. GET /v1/tool, operation get_tool:

CLI

SDK

HTTP

MCP

hanzo tool get

.ts

.py

.go

.rs

.java

import { Configuration, ToolApi } from 'hanzoai';

const api = new ToolApi(new Configuration({ accessToken: process.env.HANZO_API_KEY }));
const { data } = await api.getTool();

from hanzoai.cloud import ApiClient, Configuration
from hanzoai.cloud.api import ToolApi

client = ApiClient(Configuration(access_token=os.environ["HANZO_API_KEY"]))
result = ToolApi(client).get_tool()

cfg := hanzoai.NewConfiguration()
cfg.AddDefaultHeader("Authorization", "Bearer "+os.Getenv("HANZO_API_KEY"))
client := hanzoai.NewAPIClient(cfg)

resp, _, err := client.ToolAPI.GetTool(context.Background()).Execute()
if err != nil {
	return err
}

use hanzo_client::apis::{configuration::Configuration, tool_api};

let mut cfg = Configuration::new();
cfg.bearer_access_token = std::env::var("HANZO_API_KEY").ok();

let result = tool_api::get_tool(&cfg, Default::default()).await?;

import ai.hanzo.cloud.ApiClient;
import ai.hanzo.cloud.api.ToolApi;

ApiClient client = new ApiClient();
client.setBearerToken(System.getenv("HANZO_API_KEY"));

var result = new ToolApi(client).getTool();

curl https://api.hanzo.ai/v1/tool \
  -H "Authorization: Bearer $HANZO_API_KEY"

MCP reaches tool through the tool tool, which names its 17 operations with its own verbs — this one among them, under a name only MCP declares. describe explains any of them:

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

Answers 200 with object — ok.

Endpoints

Endpoint	What it does
`GET /v1/tool/activation`	Reports which tools are switched on for the caller's org and project.
`PUT /v1/tool/activation`	Switches tools on and off for the caller's org and project, and answers with the resulting activated set.
`POST /v1/tool/call`	Runs one of the caller's activated tools and answers with its output.
`GET /v1/tool/catalog/{id}`	Returns one catalog entry in full: the publisher's description, its repository and site, every package form with the runtime that launches it, and every hosted endpoint.
`GET /v1/tool/catalog`	Lists the MCP servers the public registries publish, as we hold them: our canonical copy of registry.modelcontextprotocol.io, plus what we decided about each entry.
`GET /v1/tool/kit`	Answers the caller's kit: what their coding runs carry of the org's tool plane.
`PUT /v1/tool/kit`	Mutes and unmutes names of the org's kit for the caller's own runs, and answers the caller's kit after.
`DELETE /v1/tool/mcp/servers/{id}`	Deregisters one of the caller org's external MCP servers, so its tools leave the registry.
`GET /v1/tool/mcp/servers`	Lists the external MCP servers the caller's org has registered.
`POST /v1/tool/mcp/servers`	Gives the caller's org one more external MCP server, so its tools join the org's tool plane and the fleet's MCP server.
`DELETE /v1/tool/plugins/authored/{id}`	Removes one of the caller org's built plugins, so the runtime can no longer load it.
`GET /v1/tool/plugins/authored`	Lists the plugins the caller's org BUILT, newest first, each with the TypeScript as authored.
`POST /v1/tool/plugins/build`	Builds and stores one plugin for the caller's org.
`GET /v1/tool/plugins`	Reports what this deployment actually mounted: every subsystem the composition root declared and whether it is switched on.
`DELETE /v1/tool/skills/{id}`	Removes one of the caller org's authored skills.
`GET /v1/tool/skills/authored`	Lists the caller org's OWN skills with their SKILL.md bodies.
`GET /v1/tool/skills`	Lists the skills the caller's org can reach — the brand's embedded catalogue plus the org's own authored ones — with each one's activation flag.
`POST /v1/tool/skills`	Adds or revises one of the caller org's own skills, and answers 201 with the stored record.
`GET /v1/tool`	Lists every tool the caller's org and project can reach, from every source, each flagged with whether it is activated.

All Hanzo APIs · Interactive reference

Was this page useful?

PreviousSandbox NextAsk