# MCP tools

Documented against OpenRig 0.5.14. Help text uses "node" where these pages say **seat**, for a seat's position in the running rig.

## What it is for

An agent that speaks the Model Context Protocol rather than a shell can drive OpenRig through `rig mcp serve`, which starts an MCP server over stdio and exposes a set of tools that mirror the CLI's main operations: boot and stop rigs, list them, snapshot and restore, discover and bind sessions, validate specs, inspect bundles, send to a seat's terminal, capture output, and use the rig chatroom. The tools return structured JSON. Where a tool changes something, it carries the same guards as the verb it mirrors.

## The three things you will do first

**Start the server for your agent.** Configure the agent's MCP settings to run this command; `--port` overrides the daemon port.

```
rig mcp serve
rig mcp serve --port 7433
```

**Discover the tool list from the server itself**, not from a page. The list on 0.5.14 has 18 tools; an earlier page said 17 and missed `rig_add`.

**Follow the same loop as the CLI.** Boot with `rig_up`, inspect with `rig_ps` and `rig_rig_nodes`, talk with `rig_send` and `rig_capture`, snapshot with `rig_snapshot_create`, stop with `rig_down`, restore with `rig_up` again.

## Every tool, with its input schema

Generated from the server's own `tools/list` on 0.5.14, without invoking any tool: **see generated/mcp-tools.md** (18 tools; required inputs marked; full JSON schemas retained).

## The mcp family

[//]: # (table:start)
| Command | What it does (from help) | Help source |
|---|---|---|
| `rig mcp` | MCP server for agent integration | mcp.txt |
| `rig mcp serve` | Start MCP server (stdio transport) | mcp.serve.txt |

[//]: # (table:end)

## What it does not do

- Tools were listed, not called, to produce the reference. Return shapes on the older site page (a dashboard URL from `rig_up`, for example) are not confirmed; trust the schema.
- The MCP server is hosted by the CLI and needs the daemon running for anything that touches a rig.
- It is not a second control plane. Every tool is a thin call into the same daemon routes the CLI uses.

## Where it goes next

- [Messaging](/docs/messaging): what `rig_send` and `rig_capture` mean, and what verify does and does not prove.
- [Lifecycle](/docs/lifecycle): what `rig_up`, `rig_down` and `rig_add` mirror.