Cadora · MCP server
cadora mcp runs the audit-grade conductor as an MCP server, so another agent — Claude Desktop, Claude Code, the Codex CLI — can start gated runs, watch them, pull artifacts, and service the human-review gate, all over five tools. It is the programmatic control plane, and the review tools are the same fail-closed / fail-soft HITL surface Cadora enforces everywhere — now reachable by an MCP client.
A client launches Cadora as a local stdio server. Drop this block into the client's MCP config — the same mcpServers shape Claude Code, Claude Desktop, and the Codex CLI all read. One command, one args list: no port, no network, nothing to expose.
Or register it in one line — claude mcp add cadora -- cadora mcp --transport stdio. The server needs the optional extra: pip install 'cadora[mcp]'.
The client spawns cadora mcp. The default transport is stdio and the default bind is loopback — the server talks only to the one client that started it, and nothing on the network can reach it. It registers five tools: start a run, watch it, read its artifacts, and service the review gate.
stdio is the local path for Claude Desktop / Code and the Codex CLI; --transport http is the remote path (step 05). The default is the safe one.
The whole control plane is five tools: two drive the run, one reads its output, two service the human gate. Each ships with a guardrail — the review gate fails closed on timeout, submit_review fails soft on bad input, and get_artifact refuses to read outside the run's workspace.
| Tool | Returns | Fail-mode |
|---|---|---|
| start_run | {run_id, status: "started"} | fail-closed timeout |
| run_status | {running, result_path, error} | read-only |
| review_gate | {pending, node_id, docs_dir, artifacts} | read-only |
| submit_review | {submitted} | {error} | fail-soft |
| get_artifact | <text> | error: … | traversal-safe |
Signatures and defaults — start_run(…, review_timeout=3600.0), submit_review(run_id, decision, comments="") — are spelled out in the design spec and manual.
Here is the round trip. The client calls start_run, polls run_status, and finds the requirements node waiting at its review gate — Cadora hands back the node id and the artifacts it produced. The client reads one with get_artifact, approves, and the run proceeds to design and construction.
A request_changes instead of approve re-runs the same node with the reviewer's comments (up to three revisions); an abort stops the run. Poll run_status until running is false — result_path points at the run manifest.
To let a remote agent connect, switch to the http transport. It still binds loopback by default; an --auth-token (or CADORA_MCP_TOKEN) requires Authorization: Bearer <token> on every request — and only a present token lets you bind a routable host. A non-loopback bind with no auth is refused unless you pass --i-understand-no-auth. Either way, front it with TLS.
Bearer auth is transport auth, not a substitute for TLS — a wrong or missing token gets 401 {"error":"unauthorized"}; the token itself still crosses the wire in the clear unless a TLS-terminating proxy sits in front.
The review tools exposed here are the exact HITL surface Cadora enforces on the CLI — no weaker for being driven by a remote agent. Four guardrails travel with the seam, so an MCP client can automate a run without automating away its safety.
Same conductor, same gates, same evidence — the MCP server only changes who holds the controls, not what the controls enforce.
The frames above reproduce real cadora mcp behavior — the stdio startup, the client config, the five-tool table, the tool-call round trip, and the HTTP auth guard — rendered as editable HTML rather than raster captures, so you can lift them into Figma or iterate directly. This is Cadora's control plane: another agent drives the audit-grade conductor, and the gates hold on the other side of the seam.