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.
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.
railcall binary. Install the CLI first with curl -fsSL https://railcall.ai/install.sh | bash.Configure your MCP client
For Cursor, Windsurf, and Zed (or if you prefer editing config files directly), the CLI prints a local stdio invocation. Only the Claude Desktop helper merges a configuration file automatically. Run the command for your client; you do not need all four.
railcall mcp config claude-desktop
railcall mcp config cursor
railcall mcp config windsurf
railcall mcp config zedClaude Desktop
railcall mcp config claude-desktopMerges a RailCall entry into the existing Claude Desktop configuration, preserving other servers and backing up an existing file. Restart the client afterward.
Cursor
railcall mcp config cursorPrints a configuration block to paste into your client settings. The CLI does not edit Cursor configuration.
Windsurf
railcall mcp config windsurfPrints the local stdio configuration to add manually in your client settings.
Zed
railcall mcp config zedPrints the invocation to adapt to your client’s context-server configuration. Check the schema supported by your installed client.
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.
The tool list depends on the installed station, modules, and discovery mode. Use the client's tool discovery rather than relying on a fixed tool count. The client's own model provider may receive tool results; a local MCP transport does not make a cloud-backed client offline. See data boundaries.
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.
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
# Print the stdio invocation without starting an interactive server:
railcall mcp config --stdio
# Reopen your configured client and inspect its available RailCall tools.If the client doesn't see the tools, run railcall doctor — inspect the dependency checks and the MCP client logs. A bare railcall mcp process speaks JSON-RPC over stdio and waits for a client; it does not print a human-readable tool catalogue.