MCP server

The platform ships a Model Context Protocol server, so an assistant — Claude, an in-house bot, something you wrote — can manage your infrastructure conversationally.

The design rule

The MCP server calls the public HTTP API and nothing else. No database access, no job queue access, no privileged path.

That constraint is what keeps a claim structurally true rather than aspirational: the panel, the API and the assistant share one intent layer. It is not possible to give the assistant a capability the API does not have, because there is nowhere else for it to get one. A new capability is added to the API first, and the assistant inherits it.

Connecting

{
  "mcpServers": {
    "zone9": {
      "command": "pnpm",
      "args": ["--filter", "@zone9/mcp", "start"],
      "env": {
        "ZONE9_API_URL": "https://panel.example.com/api/v1",
        "ZONE9_API_TOKEN": "z9_live_…"
      }
    }
  }
}

The token carries a role, so the assistant can do exactly what that role allows. Give it a viewer token if you want it to answer questions but not change anything — that is a real, enforced boundary, not a prompt instruction.

Tools

Tool names mirror the intents: servers_list, server_get, servers_create, networks_list, and so on. Read-only tools are marked as such, so a client can run them without asking you to confirm each one, while anything that changes infrastructure asks.

Because tools are the API’s intents, everything on this documentation site applies unchanged — including the asynchronous behaviour. A create tool returns a job; the assistant has to wait for it exactly as your scripts do.

What to tell your assistant

Point it at Reading order for agents. It states the invariants compactly: 202 is not done, do not retry a 409, do not invent identifiers, respect the ordering constraints between products.