Desktop app MCP server

The axiom.ai desktop app ships with an MCP server, axiom-mcp, bundled alongside the app. Point any MCP-aware client at it — Claude Desktop, Claude Code, Cursor, or anything else that speaks the Model Context Protocol — and the LLM can call axiom.ai tools in conversation.

The server speaks MCP over stdio: your MCP client launches it as a subprocess and talks to it over standard input/output. It opens no ports and is not reachable from the network. It uses the axiom.ai API key you give it, and acts only on the account that owns that key.

Two ways to set it up

Whichever route you take, the result is the same: an axiom entry in your MCP client's own config, carrying the path to the server and your API key.

• Claude Desktop, Claude Code and Cursor — the desktop app configures these for you, from a panel or from the command line. Start with Set it up from the desktop app.
• Any other MCP client — edit its config yourself. See Configure another client by hand.

Before you begin

You need:

• A paid axiom.ai account. API access is gated to paid plans. See the pricing page for plans that include the API.
• The axiom.ai desktop app, installed. Download it from the desktop app page. The app supplies the axiom-mcp binary; you don't need to install anything else.
• An axiom.ai API key, generated from the Dashboard. See Authentication.

Set it up from the desktop app

Open the app's tray menu and choose Set up Claude MCP…. Paste your API key into the card, and click Save and activate.

The app configures every supported client it finds installed:

Clients you don't have are skipped, and the card names the ones it configured. Restart those clients — they read their MCP config only at startup.

To change your key later, reopen the card, type the new key and click Update key. To remove the server, turn the toggle off; this also deletes the key, which is stored nowhere else.

Set it up from the command line

The axiom-mcp binary configures MCP clients as well as serving them. Run it with the setup subcommand, using the path for your platform:

save-key reads the key from standard input rather than from an argument, so it stays out of your shell history and the process list:

pbpaste | /Applications/AxiomDesktop.app/Contents/MacOS/axiom-mcp setup save-key

It covers the same three clients as the panel, and likewise skips any that aren't installed. Restart the clients it reports.

Find the server binary

The installer places axiom-mcp next to the app's main executable. You need this path to run setup by hand, or to configure a client the app doesn't cover.

Configure another client by hand

For an MCP client the app doesn't configure, add the server to that client's own MCP config: the binary path as the command, and your API key in env. Most clients use this shape:

{
  "mcpServers": {
    "axiom": {
      "command": "/Applications/AxiomDesktop.app/Contents/MacOS/axiom-mcp",
      "args": [],
      "env": { "AXIOM_API_KEY": "your-api-key-here" }
    }
  }
}

Use the absolute path — a client launches the server from its own working directory, so a relative path won't resolve. Restart the client once you've saved.

Register with Claude clients lists where each client keeps that file.

The server identifies itself as axiom-local, so that's the name you'll see in your client's tool list.

What it gives you

The server exposes axiom.ai's tool catalog. Ask your client "what tools do you have available?" and it will list them.

Run the automations you already have:

• list_bots — the names of every automation saved on your account. Names must match exactly, so the LLM lists them before triggering.
• trigger_bot — starts a cloud run of a saved automation by name, with an optional input payload. Returns a viewer URL — a live view of the cloud browser you can watch or share. If no concurrency slot is free the run is queued instead, and an unknown name comes back as an error.
• get_run_status — whether the automation is running, plus any data it wrote out. Identified by the automation's name, the same one you triggered — not a run id. The status is Running or Finished; Finished only means no cloud pod is executing it, so it covers a run that failed or was stopped as well as one that succeeded. See Check run status.
• stop_run — cancels an in-flight run. It takes the run's pid and pw, both derived from the viewer URL that trigger_bot returned (see Stop a run).
• remaining_runtime — your cloud runtime allowance and usage for the billing period, in minutes. Worth checking before long or batched runs.

Author new automations:

• list_actions — every automation action available (go to a page, click, enter text, extract data, loop, and so on), with a description of each. The LLM calls this to discover what it can build with.
• compile_ir — takes an automation definition and compiles it into a runnable axiom.ai automation, validating the result.

Each tool acts on the account that owns the API key you supplied, and runs count against your normal allowance. Saving compiled automations, reading full run reports, and driving a live cloud browser step by step are still on the way; until then, whether a run succeeded or failed comes from the run reports API. Because the LLM discovers tools at runtime, new ones appear when you update the desktop app — no config change needed.

Check it worked

After restarting your client, ask:

What tools do you have available?

The axiom.ai tools should be listed. If they aren't:

• Restart the client. Most clients read their MCP config only at startup.
• Check what's registered. Run axiom-mcp setup status — it reports each client, whether the server is registered there, and whether a key is set.
• Check the API key. Most failures are a missing or mistyped AXIOM_API_KEY. See If a tool says your key is missing or rejected below.
• Use an absolute path, if you configured the client by hand. The client launches the server from its own working directory, so a relative path won't resolve.
• Check the client's MCP logs. The server writes diagnostics to stderr, which your client captures.

If a tool says your key is missing or rejected

Your API key reaches the server only from the env block of your MCP client's config — that's the one channel MCP gives a local server. So a key is fixed where it is stored: in the app's card, with axiom-mcp setup save-key, or by editing the config. Either way, restart the client afterwards. There's no point pasting your key into the chat: the running server has no way to receive it, and it would sit in your conversation history.

The authoring tools (list_actions, compile_ir) work with no key at all — they run locally and never call the API. So a key problem only shows up when you use the tools that operate your automations.

Notes

• No port, no network exposure. The server talks over stdin/stdout to the client that launched it. Nothing listens on a port.
• The desktop app doesn't need to be running. Your MCP client launches the axiom-mcp binary itself when it needs it; the app is simply how the binary gets onto your machine.
• Work runs on axiom.ai's cloud browsers using the API key you supplied, so calls count against the standard rate limits and runtime allowance.
• Your API key sits in the client's config file in plain text. Don't commit it to a repo, and rotate it if it's exposed.
• Want your own tool surface, or a headless setup? See Build your own (TypeScript) or Python.