Run your Hatchbox account from any MCP client

One question, two systems, one answer

Checking whether production is running the latest code is a four-window job. It doesn't have to be.

This is the part a status-check bot or a CLI can't do. Your agent already has your repository open and your other tools connected in the same session. Hatchbox is just the other half of the picture — and once it's there, the answer and the fix are the same step.

Things to ask it

Real prompts, and the tools your agent reaches for to answer them.

• “Which of my apps haven't deployed in the last month?”

  list_account_apps, get_app

• “Why did last night's deploy fail?”

  get_log

• “Restart the worker process on staging.”

  list_processes, restart_process

• “Back up the production database and tell me when it's finished.”

  create_backup, get_log

• “Add BUGSNAG_API_KEY to all three of my apps.”

  create_env_vars

• “Point app.example.com at my Rails app.”

  create_domain

• “Run the nightly report at 2am every day.”

  create_cron_job

• “Reboot the server that's been up the longest.”

  list_servers, get_server, reboot_server

• “Is auto-deploy on for everything in my staging cluster?”

  list_account_clusters, list_account_apps

What customers say

Applications deployed

24,000+

Deployments run

2 million+

Deploying since

2016

Read more customer stories

What your agent can do

One tool per API operation, across everything the Hatchbox API exposes.

The annotations are standard MCP, so your agent — and the approval prompt in whichever client you use — can tell a read from a write before anything runs. That holds for every write tool, including ones added after you set this up.

Which MCP clients it works with

Anything that can launch a local stdio server and set two environment variables. That covers most of them. Here's where the config lives, and how far we've tested.

We're only claiming what we've actually run. Claude Code is verified end-to-end; everywhere else the server is doing the same ordinary thing — a local process on stdio, reading two environment variables — so it should behave the same. If you get it working somewhere that isn't listed, or it breaks somewhere that is, we'd like to know.

How to install the Hatchbox MCP server

Three steps, about five minutes, and all three are configuration — npx fetches and runs the package itself, so there's no package to install.

1. 1

   Create an API token

   Go to API Tokens in Hatchbox, click New API Token, name it, and copy the value.

2. 2

   Register it with your client

   One command, or one block of config. The command is npx -y @hatchbox/hatchbox-mcp in every client.

3. 3

   Set two environment variables

   HATCHBOX_BASE_URL and HATCHBOX_API_TOKEN. Then ask your agent what it can see.

# Claude Code
claude mcp add hatchbox -- npx -y @hatchbox/hatchbox-mcp

# Codex
codex mcp add hatchbox \
  --env HATCHBOX_BASE_URL=https://hatchbox.io/api/v1 \
  --env HATCHBOX_API_TOKEN=your-token-here \
  -- npx -y @hatchbox/hatchbox-mcp

{
  "mcpServers": {
    "hatchbox": {
      "command": "npx",
      "args": ["-y", "@hatchbox/hatchbox-mcp"],
      "env": {
        "HATCHBOX_BASE_URL": "https://hatchbox.io/api/v1",
        "HATCHBOX_API_TOKEN": "your-token-here"
      }
    }
  }
}

[mcp_servers.hatchbox]
command = "npx"
args = ["-y", "@hatchbox/hatchbox-mcp"]

[mcp_servers.hatchbox.env]
HATCHBOX_BASE_URL = "https://hatchbox.io/api/v1"
HATCHBOX_API_TOKEN = "your-token-here"

About that API token

Your Hatchbox API token has no scoping. It's effectively full access across your accounts, gated only by your subscription status. Treat it like a password.

If unscoped tokens are a blocker for how your team works, tell us. That's exactly the kind of thing the beta is for.

This is a beta