Skip to main content
The Public API MCP server (@gavai/mcp-server) generates its tool list directly from the platform’s OpenAPI spec. Every operation tagged x-mcp-tool: true becomes a callable tool, so the AI surface tracks the REST API automatically — rotate a key, mint a domain, query logs, list deployments, all without the Builder MCP’s curated 14. By the end of this page you will know how to install and authenticate the server, how tools are generated, and which scopes you should put on the API key it runs with.

​
At a glance

Package@gavai/mcp-server (published to npm)
Transportstdio (JSON-RPC)
Commandbunx @gavai/mcp-server
AuthGAVAI_TOKEN env var (workspace API key)
Base URLGAVAI_PUBLIC_API_URL env var (defaults to https://api.gavai.app)
ToolsOne per OpenAPI operation tagged x-mcp-tool: true

​
Install

bunx fetches and runs the latest published version. No global install: 
bunx @gavai/mcp-server
You will not run this command by hand once you are set up — Claude Desktop spawns it as a subprocess at startup.

​
Configure

The server needs two environment variables: a workspace API key and the API base URL. Both go in the Claude Desktop config: 
{
  "mcpServers": {
    "gavai-api": {
      "command": "bunx",
      "args": ["@gavai/mcp-server"],
      "env": {
        "GAVAI_TOKEN": "gak_live_...",
        "GAVAI_PUBLIC_API_URL": "https://api.gavai.app"
      }
    }
  }
}
Replace gak_live_... with the workspace API key you mint in Settings → API keys. Use a gak_test_* key against a test workspace while you are figuring out which tool calls your assistant will make. Restart Claude Desktop after saving the file.

​
How the tool list is built

The server reads the OpenAPI spec at startup and registers one tool per operation tagged x-mcp-tool: true. The mapping is deterministic: You do not configure individual tools. Add or remove the tag on the spec and the next server start picks up the change — there is no per-tool config to drift.

​
Coverage

Every endpoint tagged with x-mcp-tool: true is reachable. The 15 public resources documented at API reference map one-to-one to operations, covering workspaces, tokens, pages, theme, forms, agents, secrets, domains, logs, deployments, billing, monetization, and approvals. If you need to know exactly which operations are tagged, ask the connected client for tools/list after restart — the response is the canonical answer for the running server.

​
Worked example: AI rotates an API key

Here is what happens when a user says “Rotate the deploy bot’s API key on the acme workspace”: Three points worth pulling out:
  • Tool names mirror OpenAPI operation IDs. listWorkspaceTokens dispatches to and rotateWorkspaceToken dispatches to . Same operationIds you would call from the REST SDK.
  • The bearer token never leaves the server process. The MCP server reads GAVAI_TOKEN from its env, attaches Authorization: Bearer, and the AI client only ever sees the response body.
  • The new secret is returned exactly once. The chain ends with the client surfacing it to the user; if they don’t capture it, they rotate again.

​
Pinning scopes

Mint a separate API key for MCP use and grant only the scopes your AI workflow needs. AI assistants chain tool calls across multiple operations — a broad-scope key gives them broad reach. Apply least-privilege so an unintended call cannot cause damage. See API tokens for how to create and scope keys.
A practical default: start with read-only scopes (workspaces:read, logs:read, deployments:read), watch what the assistant tries to call for a session, and add the specific write scopes you decide to allow.

​
Where to next