Appcircle MCP

1What it does

Appcircle's own MCP server — a first-party bridge between a mobile CI/CD platform and MCP-capable agents. It exposes Appcircle's API surface as tools: trigger builds, check build status and logs, manage distribution and testing profiles, inspect signing identities, and pull artifacts — so the agent can answer "did the last build pass?" or "send this build to the beta testers" without a dashboard round-trip. The README ships install blocks for a long list of clients (Cursor, Windsurf, Claude, Gemini CLI, and Antigravity among them), making it one of the better-documented vendor MCPs for this line. Runs as an stdio server via npx — appcircle-mcp launches per session with your API token in environment variables — or through the mcp-remote bridge pattern for clients that only accept HTTP transports.

2When to use it

Reach for it when mobile release work is part of the codebase — an agent that can read the failing Appcircle log, retrigger the build, and ship the artifact to the right testing group closes a loop that otherwise lives outside the editor. It fits teams whose CI/CD is already on Appcircle; if your pipeline is GitHub Actions, Fastlane or Codemagic, this server is the wrong tool for the same job. The audience is narrow by design — worth installing only when mobile delivery is a real part of the project's daily work, not for a repo that builds an app twice a quarter.

3How to get started

Two install shapes are documented. For Antigravity's stdio path, add an entry to mcp_config.json running npx -y @appcircle/mcp (exact package name in the README) with APPCIRCLE_API_TOKEN in the env block — generate the token in Appcircle's IAM settings and scope it to the projects the agent should touch. The README's Antigravity section shows the complete JSON; after restarting the agent, verify the server registers by listing available MCP tools. For hosts that only accept remote servers, the mcp-remote wrapper converts a local stdio server into an HTTP endpoint — the README covers that path too.

4Configuration

Everything lives in mcp_config.json — command, args, and the env block carrying the API token and optional organization scoping. Treat the token like any production credential: fine-grained scope, readable only where the agent needs it, and rotated on the same schedule as dashboard credentials. If multiple Appcircle organizations are in play, the env scoping keeps the agent inside the right boundary — one mcp_config.json entry per org is cleaner than a broad token. The server is stdio-launched per session; startup latency is negligible but the process dies with the agent session, so stateful work should live in Appcircle itself, not in server assumptions.

5Things to know

• Vendor-maintained — it is Appcircle's own server, so API drift is their problem to fix, not a community fork's lag.
• Token-in-env is the standard pattern but still a plaintext secret in mcp_config.json on disk — file permissions are the only boundary.
• npx-cached binary: npx -y pins to latest — pin a version in args if you want reproducibility across a team.
• Tool surface is broad (the whole API); review which calls the agent actually uses before leaving it always-on — an agent that only reads build status doesn't need distribution write tools in scope. - The npx distribution means the server binary updates when npm does — a team that wants a frozen tool version pins the package version in args rather than riding latest.
• Mobile-release actions are user-visible by design — pushing a build to a testing group is a real distribution event, so the sensible scope grants read + build-trigger and leaves store submission to humans.
• The README's client matrix is unusually complete — Gemini CLI, Codex and Claude install blocks ship alongside Antigravity's, so one MCP decision travels across agent hosts if your team mixes tools.

6Related on the map

References

• Repository
• Appcircle MCP documentation