arcane-mcp connects any MCP client — Claude Desktop, Claude Code, VS Code with GitHub Copilot and the rest — to an Arcane server, so you can ask “which containers are unhealthy on my NAS environment?”, “pull nginx:1.27 and redeploy the web project” or “show the last 50 log lines of the database container” and have it done through Arcane’s own API, with Arcane’s own permissions.
1:1 parity with Arcane
Every operation in Arcane v2.17.2’s OpenAPI document (442) and every route Arcane serves outside it — WebSocket logs and stats, the container terminal, pprof, the webhook trigger, the federated token exchange — maps to one catalog action: 461 actions in 52 domains. A CI audit fails the build if Arcane gains a route without an action.
Three tool surfaces, one catalog
dynamic (default): two tools, arcane_find_action and
arcane_execute_action. meta: one tool per domain (52).
individual: one tool per action (461). All three dispatch through the
same code, so they cannot drift apart.
Safe where it matters
Destructive actions — deletes, prunes, kills, restores, redeploys — need
confirm: true. Read-only mode removes every mutating action; safe mode
answers them with a preview of the request instead of sending it.
Validated against live Arcane
An end-to-end suite runs every scenario on all three surfaces against a disposable Docker-in-Docker estate of real Arcane v2.17.2 managers, direct and edge agents, a Swarm cluster and a Podman host, and a ledger records which actions it exercised.
Schemas straight from Arcane
Input schemas are derived from Arcane’s own OpenAPI document, which is generated from the code that routes requests, so the model sees exactly what Arcane validates against.
Streams become answers
Logs, stats, the event feed and the container terminal are bounded actions that listen for a few seconds and return what arrived; image pulls and project deploys are followed to the end and summarised.
