The dev MCP server
aircloud mcp serves a Model Context Protocol server over standard input and output, for your coding agent to
launch. aircloud skill install registers it with the agent; you never run it by hand. The registration names an
absolute path to the aircloud that ran the install, so the agent finds it whatever its own PATH holds. When your
PATH finds that same aircloud through a package manager's link (Homebrew, npm), the link is what is registered, so
an upgrade keeps working; if you install aircloud somewhere else, run the install again.
What it offers
Its tools read the product directory and the platform, and run a function. It never writes: creating, generating, releasing and setting secrets stay CLI commands.
| tool | what it does |
|---|---|
check |
validates the product directory, as aircloud check |
routes |
the resolved route table, as aircloud routes |
agents_map |
the product's AGENTS.md |
capabilities_list, capabilities_diagnostics |
the platform capabilities the product uses, and their diagnostics |
releases_list, release_show |
the product's releases, as aircloud release list and aircloud release show |
authz_check |
why a member may or may not act at a node, as aircloud authz explain: the decision, the rule and the layer that decided, the membership and its roles there — read with your authority, over the nodes at or below yours (How authorization works) |
invocations |
function invocations, as aircloud logs, with the same filters (response_status included) and the same refusals |
cli_changelog |
this CLI against the latest signed release, as aircloud changelog --json: every newer release's notes and date, and the upgrade command — your agent calls it before writing code |
feedback_preview, feedback_submit |
drafts a platform feedback report and shows exactly what it sends, then sends that report, as aircloud feedback |
function_invoke |
runs a function, as aircloud functions invoke, with the request method, path and headers it names — in production unless you name another environment, with your authority: whatever the function does takes effect, and it may be billed |
It also serves the product's AGENTS.md and the skill's files as resources. Every tool but function_invoke and
feedback_submit is marked read-only; function_invoke is marked destructive, open-world and not idempotent, and
feedback_submit not destructive, not open-world and not idempotent (each call sends a report). The server adds no tool to
the agent's auto-approve list, function_invoke least of all: your agent asks before running one.
Whose authority it acts with
Each tool call acts with this CLI's session, resolved anew on every call; the server holds no token and no identity
of its own, and never starts a login. Log in first with aircloud login. With no session, a tool fails and names the
command that fixes it. When you hold several memberships in the product, launch it as aircloud mcp --membership <id>
to act through one of them (Members, roles and registration).
Headless Linux and CI
A machine without a keychain keeps no refresh token (see Logging in), so a human login there lasts only as long as its access token. Do not work around that: on such a machine, and in CI, the durable credential is a service account of the product.
The product's Builder creates the service account and its key file with
aircloud service-accounts create: the private key never reaches the platform, and every key expires (see
Logging in). Then, on the machine:
aircloud login --service-account ci-key.json
The CLI reads the key file where it is and never copies it, and the MCP server acts with that session. Alternatively,
a tenant-scoped bearer token in AIRCLOUD_TOKEN, with the API origin in AIRCLOUD_API, overrides the session.