MCP Integration

Attach Claude Desktop, Cursor, Windsurf, or Zed to the local RailCall MCP server. The agent uses the same airlock every human uses — no separate trust path.

Airlock, not a bypass
The MCP server is the airlock wearing an MCP hat. An agent asking to send a live message still hits the same approval and receipt path as railcall workflow run --live from the shell.

One-shot wiring

Pick your client — the CLI writes the right config file, points it at the local stdio server, and prints the next step.

shell
railcall mcp config claude-desktop
railcall mcp config cursor
railcall mcp config windsurf
railcall mcp config zed
Client

Claude Desktop

railcall mcp config claude-desktop

Rewrites ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or the platform equivalent. Restart Claude Desktop after.

Client

Cursor

railcall mcp config cursor

Writes the RailCall entry under Cursor's MCP config. Reload the workspace after configuring.

Client

Windsurf

railcall mcp config windsurf

Configures Windsurf's MCP registry so the airlock tools are reachable from the assistant panel.

Client

Zed

railcall mcp config zed

Registers RailCall as a context server for Zed's assistant. Take a look at Zed's assistant settings once configured.

Tools an agent gets

The MCP server exposes workflow-shaped tools first, then every airlock command auto-registers as an MCP tool so an agent can drive any local governed action the CLI can.

Workflow tools

railcall_workflow_listEnumerate every plan installed on this machine — id, title, providers, approval mode.
railcall_workflow_runExecute a workflow by id. Dry-run by default; live sends still require the airlock's approval step.
railcall_workflow_composeDraft a new plan from a natural-language intent — returns a workflow CSV, does not execute it.
railcall_pending_listShow approvals waiting on a human — what the airlock is holding, and why.

Airlock tools (auto-registered)

Every command from the CLI reference is also an MCP tool, prefixed with the same name shape. Agents can call railcall_audit, railcall_verify, railcall_receipts, and railcall_market_list the same way they call the workflow tools. See CLI Reference for the full set — the MCP surface is one-to-one.

Example agent prompt

A short, honest prompt for a paying customer running Claude Desktop with RailCall attached. Every tool call still flows through the airlock — the agent can't sneak past approval.

text
You are the ops assistant for our team. RailCall is attached as an
MCP server. Use it as the ONLY way to touch live systems.

When asked to do anything consequential:
  1. railcall_workflow_list to find or confirm the plan
  2. railcall_workflow_compose if no plan matches — return the CSV
     to the human for review, don't run it
  3. railcall_workflow_run in dry-run first, share the receipt
  4. Ask for explicit approval before switching to live

Never claim an action succeeded without a signed receipt returned by
the tool call. If railcall_pending_list has an entry, tell the human
what's waiting — do not try to auto-approve.

Verify the wiring

shell
# Run the MCP server directly to confirm it starts and lists tools.
railcall mcp

# Then reopen your client and check the tool list surfaces railcall_*.

If the client doesn't see the tools, run railcall doctor — it prints PASS / WARN / FAIL for the MCP config path, the loopback daemon, and the signing key.