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.

Claude Desktop extension (one-click)

The fastest way to wire Claude Desktop to your local RailCall install: download the .dxt extension and double-click it. Claude Desktop registers the extension, prompts you for the workspace path, and RailCall's airlock tools appear in every new chat.

↓ Download railcall.dxtv0.1 · macOS / Windows / Linux · requires RailCall CLI + station installed
Requires the CLI first
The extension is a thin wrapper — it tells Claude Desktop how to spawn your locally installed railcall binary. Install the CLI first with curl -fsSL https://railcall.ai/install.sh | bash.

Other clients — one-shot wiring

For Cursor, Windsurf, and Zed (or if you prefer editing config files directly) the CLI writes the right 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.

Token-efficient by design

Every tool call an agent makes is paid for in context tokens. The MCP surface is engineered to make the governed path the CHEAP path — measured, not projected (station-v0.95+):

railcall_tool_resolveDescribe the intent, get back the single best tool WITH its schema, approval mode, and a confidence score — one round trip instead of search-then-read. Ambiguous intents refuse honestly toward the index; a resolved write can only ever reach its stage surface.
railcall_tools_indexA one-line map of every tool — name and purpose, no schemas. Browse cheap, fetch full schemas only for what you'll call.
railcall_git_diffA filtered git diff: the complete per-file stat, actual hunks for the highest-churn files within a line budget, and an explicit list of every dropped noise file (lockfiles, minified, dist/). Measured on a real repo: ~28k tokens raw → ~4k filtered, an 85% cut.
railcall_git_logOne line per commit, ~8 tokens each. Read-only, local.

Connector tools list ONCE per connector — calling without a consent_token stages a signed dry-run plan, calling again with the returned token executes it after approval. Same two-gate write contract, 25% less listing. Successful governed reads echo a compact rcpt_ handle that railcall_receipt_verify accepts directly; failures keep full detail.

Nothing is silently truncated
Every filtered result names what it dropped and marks what it cut at budget — an agent can always fetch the excluded piece explicitly. Filtered never masquerades as complete.

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.