The MCP server & the apprelay CLI
Put AppRelay inside Claude: 25 tools that let an agent read your projects, work out what a release would do, bump versions, build, test, and ship — plus the headless apprelay CLI for your own scripts and CI.
Last updated 2026-07-25
AppRelay ships an MCP server — a small bridge that lets an AI agent like Claude see and drive your projects directly. Instead of you copying build output into a chat window, the agent can list your projects, read versions and git status, check that a machine has the right tools, and kick off builds, tests, and releases itself.
serve, the headless host that keeps schedules and watchers running with no window open.What it needs
- AppRelay installed — the server drives the CLI inside the app, so the app is both the engine and where the bridge lives. It doesn't need to be open.
- Node.js 18 or newer — the bridge is a single dependency-free script.
- An MCP client — Claude Code or Claude Desktop.
Setting it up
In Claude Code, register it once and it's available in that project. The path is fixed, because the bridge ships inside the app:
# macOS
claude mcp add apprelay -- node "/Applications/AppRelay.app/Contents/Resources/apprelay-mcp.mjs"
# Windows
claude mcp add apprelay -- node "C:\Program Files\AppRelay\apprelay-mcp.mjs"In Claude Desktop, add an entry to mcpServers in claude_desktop_config.json pointing at the same path, then restart the app:
{
"mcpServers": {
"apprelay": {
"command": "node",
"args": ["/Applications/AppRelay.app/Contents/Resources/apprelay-mcp.mjs"]
}
}
}/Applications, then your own Applications folder, then a local build; on Windows, the standard install folder, then a per-user install. To point it somewhere else — a beta build, a non-standard location — set APPRELAY_BIN to the binary's path and it'll use that ahead of everything else.What the agent can do
Twenty-five tools. Nineteen only ever read; four do something on your machine; two can reach the outside world and refuse to act without an explicit confirmation.
Read your workspace
| Tool | What it answers |
|---|---|
list_projects | Every project in your workspace, with its tags and suite |
project_status | One project in full — lanes, recipes, distributions, test suites |
list_groups | Your suites and tags, so “the whole X suite” means actual projects |
doctor | Install health, and what would block a build right now |
license_status | Your plan, and how much free-tier build and publish budget is left |
Read a project’s state
| Tool | What it answers |
|---|---|
versions | The version and build of each lane |
version_state | One lane’s version, the file it lives in, and whether that format can be written |
git_status | Branch, upstream, ahead/behind, and dirty state per repo |
requirements | Which required tools are installed, and their versions |
list_recipes | The actual commands behind build, run and ship |
list_environments | Your deploy environments — variables in full, secrets by name only |
list_secrets | Which credential fields are filled in. Never a value |
list_targets | The simulators, devices and emulators you can run on right now |
Read what shipping would do
| Tool | What it answers |
|---|---|
channels | Where a lane ships, what’s live there, and whether this version already went out |
deployments | What actually shipped — version, when, by whom, health, artifact |
rollback_plan | Whether a channel can be rolled back, and what that would take |
runs | Recent runs across every project, newest first |
run_log | One run in full — every step, its exit code, and where it stopped |
list_triggers | The triggers you’ve configured |
Do something on your machine
| Tool | What it does | Effect |
|---|---|---|
bump_version | Write a new version to the lane’s version file | Edits a file in your repo |
build | Build a lane | Produces a local artifact |
run | Build a lane and launch it, optionally on a chosen device | Runs it on your machine |
run_tests | Run a test suite | Runs your tests |
Reach the outside world
| Tool | What it does | Effect |
|---|---|---|
run_trigger | Fire one of your triggers now | May publish — needs confirmation |
release | Ship a lane to a channel | Publishes — irreversible |
Anywhere a project is named, the agent can use its slug, its id, its exact name, or its position in the list — the same way the CLI resolves one. Lanes work the same way, by label or position. A release can also name a deployment environment, so the agent ships against Staging or Production with that environment’s variables and secrets.
Four ready-made workflows
As well as tools, the bridge ships prompts — guided workflows your client surfaces as slash commands, with your own project and lane names auto-completing as you type.
| Command | What it does |
|---|---|
/release | Walks a project from where it is to a shipped release — checks first, then bump, build, test, and ship on your say-so |
/readiness | A read-only pre-release audit: everything that would block or spoil a release, with nothing run and nothing changed |
/diagnose | Reads the run log, finds the step that actually failed, and works out why |
/whats_live | What’s currently deployed across your projects, and anything stale or unhealthy |
release, and run_trigger for a trigger whose action is a ship — and both refuse to run unless called with an explicit confirmation flag: “refused: set confirm=true to ship a release.” An agent that merely decides to release still has to say so deliberately, and for a release the app refuses a second time at the CLI if the confirmation didn't reach it. Everything else is either read-only or stays on your machine. A channel that requires production approval can't be shipped this way at all — that one only happens in the app, where the approver is recorded.The apprelay CLI
The MCP server is a thin wrapper over a headless CLI that you can also drive yourself, from a terminal or from CI. It reads the same workspace and prints JSON, which makes it easy to pipe into your own scripts:
| Command | What it does |
|---|---|
apprelay projects | List projects |
apprelay build <project> [lane] | Build a lane |
apprelay run <project> [lane] [--target <id>] | Build a lane and launch it |
apprelay test <project> [suite] | Run tests |
apprelay release <project> <lane> <channel> --confirm [--env <name>] | Ship a release |
apprelay version <project> [lane] | One lane's version and the file it lives in |
apprelay bump <project> <major|minor|patch|build|set> [lane] | Write a new version |
apprelay channels <project> [lane] | Where the lane ships, and what's live there |
apprelay deployments <project> [N] | What actually shipped, newest first |
apprelay rollback <project> <lane> <channel> | Whether that channel can be rolled back |
apprelay secrets <project> | Which credential fields are filled in |
apprelay targets <project> [lane] | Devices and simulators you can run on |
apprelay recipes [project] | The steps behind build, run and ship |
apprelay license | Your plan and remaining free-tier budget |
apprelay doctor | Install health and configuration problems |
apprelay runs [N] | The most recent run records, newest first |
apprelay run-log <id|latest> | One run in full, step by step |
apprelay trigger list | Every configured trigger |
apprelay trigger run <id> | Fire one trigger now |
apprelay trigger add … | Add a schedule, watch, or webhook trigger |
apprelay trigger rm <id> | Remove a trigger |
apprelay serve [--webhook] | Run schedules and watchers headlessly, with no window open. Blocks until you stop it. (macOS only.) |
An agent can see your triggers and fire one (with confirmation), but it can't create or delete them, and it can't run serve — adding a webhook trigger stores a shared secret, and serve runs until you stop it, so both belong in your hands rather than an agent's. See Triggers for what they automate.
Rolling back works the same way. An agent can tell you whether a channel can be rolled back and what it would take — some, like the App Store or npm, genuinely can't be un-published — but performing one rebuilds an old tag and re-ships it, so that happens in the app, where the run is recorded against you. See Cutting a release.
trigger run, and serve need AppRelay Studio. Listing projects, reading status, building, and testing work on the free tier within its usual caps — a build started by an agent spends a build credit exactly like one you click yourself.What it means for your secrets
The bridge runs on your machine and shells out to your own AppRelay install; nothing about your projects is uploaded by it. The agent sees what the CLI prints — project names, versions, git status, tool availability, deploy history, run logs, and build output.
No tool returns a secret value, on any path. list_secrets answers which credential fields have been filled in — a list of field names and yes/no — so an agent can tell you the App Store Connect credential is missing its key id without the key ever existing in the conversation. Your signing credentials and API keys stay in the secret store, are substituted at run time, are handed to a command through its environment rather than its command line, and are masked out of everything printed.
Bear in mind that whatever the agent does read becomes part of its conversation with Anthropic, under your own account — the same as if you'd pasted it yourself. See Security & privacy.
Next steps
- AI assistance with Claude — the Claude features built into the app
- Scheduled, watch & webhook triggers — what
servekeeps running - Security & privacy — what leaves your machine