Cloud MCP

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 121 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 2026-07-28, naming itself cloud version 2026-07-28, 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 account op=get_appearance with no credential it answered sign in to read your appearance. 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 — the document's bearer scheme: The caller's credential, sent as Authorization: Bearer <token>. It is either an access token minted by Hanzo IAM or an API key (pk-/sk-). X-Authorization, and HTTP Basic carrying the token as the password, are accepted spellings of the same header for clients that cannot set Authorization; a browser presents the session cookie instead. Every operation requires it unless it says security: []. Send it in an Authorization header on the request:

export HANZO_API_KEY=sk-...
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 — where keys come from →

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. 80 of the 121 tools resolve to an operation in it, across 80 products; 41 do not, and are listed as such rather than left out.

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

How a tool page is built

Each argument is declared twice, and neither declaration is whole. tools/list names a field and gives it a type and usually a description — across the whole catalogue it marks nothing required, carries no default and enumerates no value set. The operation the tool dispatches to declares the rest, because that is what the API validates against. So a tool page takes its shape from the door and its constraints from the document, and says on every table which column came from which. A — means neither source constrains the field; it is never a guess, and where the two cannot be joined the page says that instead.

The door is read live at build time; the document is a pinned snapshot (pinned at 67bd9d9cb). They can disagree, and where they do the page reports it rather than smoothing it over.

Add your org's own servers

The OpenAPI document declares no route for registering external MCP servers, so there is nothing to document here yet.

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 — 121 tools captured 2026-08-16.