I built an MCP server for the Arcane API — 125 tools for AI-driven Docker management

[MikeCase]

Been using Arcane for a while to manage Docker on my homelab. Great piece of kit. I wanted my AI coding agent to be able to interact with the same Docker host directly — deploy services, check logs, manage volumes — without me having to context-switch.

So I put together an MCP server wrapper around the Arcane API. It exposes 125 tools across 14 categories — containers, images, volumes, networks, Compose projects, registries, vulnerability scanning, etc. Any MCP-compatible agent (OpenCode, Claude Desktop, Cursor) can use it.

Quick example flow:

# Agent stops a container
stop_container("my-app")

# Agent needs to remove it — gets a token, doesn't execute
remove_container("my-app")
→ {"warning": "...", "confirmation_token": "a1b2c3"}

# Agent calls back to confirm
confirm_operation(token="a1b2c3")
→ container removed, logged to audit trail

Every destructive operation uses a two-step confirmation token pattern (with a 120s TTL), so an agent can't blast through a safety gate in one call. Prune operations default to dry-run. All actions are logged to a structured audit file.

The server is a thin Python layer (FastMCP + httpx) that just proxies to the Arcane API with proper error handling and auth. No state, no database, no daemon.

Would love feedback, especially from anyone else experimenting with AI agents managing infrastructure. What guardrails are you using?

Repo: https://github.com/MikeCase/arcane-mcp
Install: pip install git+https://github.com/MikeCase/arcane-mcp.git

[armorer-labs]

I like the two-step token pattern for destructive operations. For infrastructure tools, I would add a few guardrails around that boundary so the confirmation token is not the only control.

The checks I would want are:

• classify every tool into read, reversible write, destructive write, and credential/network-sensitive write;
• bind the confirmation token to the exact operation, resource id, normalized arguments, caller/session id, and a short policy version;
• require the confirm call to re-submit the normalized operation hash, not just the token;
• make dry-run output structured enough that an agent can show a diff or impact summary before asking for approval;
• emit an audit record for the proposed operation, the approval decision, and the final API result as three separate events;
• deny confirmation if the underlying resource changed after the proposal was generated, especially for volumes, networks, registries, and compose projects;
• keep log reads separate from secret-bearing config reads, since container logs and env/config inspection have very different leakage profiles.

The most useful negative tests are usually simple: token reuse fails, token for container A cannot confirm deletion of container B, changed arguments invalidate the token, expired token does not execute, failed Arcane API call still produces a terminal audit event, and a dry-run prune cannot be silently upgraded to execute.

For agents managing Docker hosts, I would also treat compose project changes as a higher-risk class than single-container restarts. A compose update can mutate networks, volumes, env, images, and restart policy in one action, so it deserves a compact plan/receipt before execution.

Disclosure: I work on Armorer Labs.