Skip to main content
CTRLRun works with MCP in four ways. The gateway sits in front of any MCP server and applies your policy to every tools/call, with no change to the agent or the server. The operator server lets the person who has to answer an approval answer it from the assistant they are already talking to. This documentation is itself an MCP server your coding tool can search. And the gateway is listed where MCP servers are discovered.

​
Enforcement: the gateway

ctrlrun gateway is a process between the agent and the tool server. Every tools/call becomes an action named mcp.<alias>.<tool>, decided by the same ctrlrun.yaml the decorator uses, bound to a human’s approval where the policy says so, reserved by effect key so the same consequence runs once across retries and workers, relayed, and recorded. Everything else on the wire is relayed untouched.
  • No code changes: the agent and the server are untouched.
  • Works in any language: the gateway fronts an HTTP endpoint.
  • Approvals bound to the exact tool call, arguments included.
  • Every call that reaches a decision leaves a receipt, denied ones included. A call still waiting on a human has not been decided yet and has none until it is.
  • Measure first with observe mode, in the same policy file.
The gateway in five minutes is the page for someone who already runs an MCP server.

​
Learning: this site is an MCP server

Every page here is reachable through an MCP server hosted with the site, with one tool, a search across the documentation. Add it to Cursor, VS Code or any MCP client and the assistant answers from these pages rather than from memory. Use the docs from your editor has the configuration.

​
Discovery: the registries

The gateway is what you run to put CTRLRun in front of an MCP server, and it is listed in the MCP registries as such once the listing is live. Until then this section carries no link rather than a placeholder; the registry entry is a launch-day item.

​
Answering: the operator server

ctrlrun mcp-operator is an MCP server that exposes the operator’s own commands as tools. An approver asks their assistant what is waiting, reads the action and its arguments, and answers — without a checkout, a shell or a store path.
  • Read tools — list_pending_approvals, inspect_action, receipts, effects, stats.
  • Write tools — approve, deny, resolve. Each needs a credential that names a human, from the identity provider you configured; never a name the client asserts.
  • Every answer is recorded under that person’s name, and the name reaches the receipt the action leaves.
  • It is not a second approval path: approve and deny are the two store calls ctrlrun approve and ctrlrun deny make, against the same record, with the same hash binding, single use and expiry.
  • Nothing here can make an agent act. There is no tool that proposes or executes an action, and no auto-approve.
  • It binds loopback and has no flag that changes that, because its read tools answer without a credential.
Approve from your assistant is the page with the configuration and a transcript.

​
What MCP does not change

The guarantees are the same three ways in. A refund refused by the gateway is refused for the same reason, recorded in the same receipt shape, and verified by the same ctrlrun verify as one refused by the decorator. An agent that calls a CTRLRun tool to check its own actions would not be enforcement, because a tool the agent chooses to call is a tool it can choose not to; the gateway is in the path whether the agent likes it or not.

​
Next

Related topics

The gateway in five minutesApprove from your assistantUse the docs from your editorCTRLRunCTRLRun and framework human-in-the-loop