Hanzo
Cloud MCP

Cloud MCP

One JSON-RPC endpoint that gives any MCP client 834 tools over the Hanzo cloud, plus the external servers your org registers.

POST https://api.hanzo.ai/v1/mcp is the agent-facing surface of the Hanzo cloud: one JSON-RPC 2.0 endpoint that answers tools/list with 834 tools and tools/call to run them. It is the same cloud the REST API serves — a tool here is an operation there, so an agent and a program reach identical behaviour.

Point a client at it

The door speaks streamable HTTP, so a client needs the URL and nothing else:

claude mcp add --transport http hanzo-cloud https://api.hanzo.ai/v1/mcp

Any client that reads an MCP config file takes the same two facts:

{
  "mcpServers": {
    "hanzo-cloud": {
      "type": "http",
      "url": "https://api.hanzo.ai/v1/mcp"
    }
  }
}

The door answers initialize with protocol 2025-06-18, naming itself cloud with no version string, and advertises {"tools":{"listChanged":false}}.

Credentials

tools/list is answered without a credential — that is how this reference is generated. tools/call is not: the door replies HTTP 200 with a JSON-RPC result whose isError is set, and whose text names what was missing — asked for get_v1_ads_campaigns with no credential it answered X-Org-Id required. Each tool refuses in its own terms, so treat that as the shape of the answer, not the wording.

The door takes the same bearer credential as the REST API — a Hanzo IAM JWT or an hk- key from console.hanzo.ai — in an Authorization header on the request:

export HANZO_API_KEY=hk-...
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/list"}'

Set that header however your client sets request headers for an HTTP MCP server. One credential reaches every tool, because one credential reaches every product.

What is behind the tools

Every tool is a projection of the same OpenAPI document that generates the REST reference, the SDKs and the CLI. 827 of the 834 tools resolve to an operation in it, across 93 products; 7 do not, and are listed as such rather than left out.

The door exposes a subset of the document, not all of it: 834 tools against 2454 operations. Whether an operation has a tool is a question only the door answers, so every page here asks it rather than assuming.

Add your org's own servers

An org is not limited to the tools above. Register an external MCP server and its tools join the same surface for everyone in the org — one connection for a client, whatever it is wired to behind the door.

RouteOperationWhat it does
GET /v1/mcp/serverscloud_get_v1_mcp_serversListServers lists the external MCP servers the caller's org has registered.
POST /v1/mcp/serverscloud_post_v1_mcp_serversCreateServer gives the caller's org one more external MCP server, so its tools join the org's tool plane and the fleet's
DELETE /v1/mcp/servers/{id}cloud_delete_v1_mcp_servers_idDeleteServer deregisters one of the caller org's external MCP servers, so its tools leave the registry.
curl -X POST https://api.hanzo.ai/v1/mcp/servers \
  -H "Authorization: Bearer $HANZO_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
       "authHeader": "<authHeader>",
       "listing": "<listing>",
       "name": "<name>",
       "secret": "<secret>",
       "url": "<url>"
     }'

Fields, types and prose for these routes are enumerated in the cloud API reference.

The local server is a different thing

This page is the cloud door — a URL, no install, your org's data. The Hanzo MCP server is the one that runs beside your editor and reaches your filesystem, shell and git. They compose: a client can hold both connections at once.


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?

On this page