MCP tools

Tool reference documented against OpenRig 0.7.2; the release notes below cover 0.7.4. Help text uses "node" where these pages say seat, for a seat's position in the running rig.

What it is for

An assistant that speaks the Model Context Protocol rather than a shell, such as Claude Desktop, can work with an OpenRig team through rig mcp serve. The server's tools mirror the CLI's main operations: start and stop rigs, list seats, snapshot and restore, send to a seat's terminal and read its screen, use the rig chatroom, and hand work to the team through the queue. The tools return structured JSON. Where a tool changes something, it carries the same guards as the verb it mirrors.

The server reaches the team as one seat: the one named by OPENRIG_SESSION_NAME where it was configured, or, over HTTP with a grant, the grant's seat. The daemon records the server's writes as that seat's.

The three things you will do first

Add the server to your assistant. For a client that starts a local process, the command is rig mcp serve (stdio). In Claude Desktop's claude_desktop_config.json:

{
  "mcpServers": {
    "openrig": {
      "command": "rig",
      "args": ["mcp", "serve"],
      "env": { "OPENRIG_SESSION_NAME": "assistant@my-rig" }
    }
  }
}

Use the full path to rig if the client can't find it, and name the seat the assistant acts as. --port points the server at a daemon on another port. In Claude Code the same server is claude mcp add openrig -- rig mcp serve.

Check who it is. rig_whoami says which seat the server acts as and whether the caller is authenticated; rig_team shows a rig's seats and its lead. Discover the tools from the server's own tools/list, not from a page.

Hand work over through the queue. rig_queue_create gives a seat a task and returns its qitemId; rig_queue_show reads the answer later and names the next item when the work was handed on. To pass on work this seat holds, use rig_queue_handoff rather than closing it and creating another; rig_queue_unclaim puts a claim back. An ordinary chat app sees work when it checks. The experimental hosted-member webhook described below is a trigger for a compatible runner, not proof that the assistant woke.

An assistant on another machine

Internet-facing MCP and hosted members are experimental, unsupported and off by default. Use at your own risk. Nothing listens on the internet unless you set it up yourself. Put rig mcp serve --http behind your own TLS tunnel or proxy and issue a token. This is like opening a port in your firewall: anyone with the URL and a valid token can act as the member within its grant. Treat the token like a password, give the narrowest grant and revoke it when you're done with rig mcp token revoke <name>. OpenRig does not support or take responsibility for an internet-reachable server. Only Grok was tried.

rig mcp serve --http serves the same tools over Streamable HTTP at /mcp, by default on 127.0.0.1:7437; --bind <host:port> changes that.

• With no grants, it stays on loopback and acts as OPENRIG_SESSION_NAME, declared and not authenticated, like stdio.
• Add a grant before anything reaches the port, including through a tunnel or proxy, which arrives on loopback too: rig mcp token add <name> --seat <session> --rig <rig> prints a token once and keeps only its hash. The client sends it as Authorization: Bearer <token>.
• Once a grant exists, every request needs a valid token, loopback included, and each caller acts as its own grant's seat. A grant reaches the work tools within its rigs; --root adds shared file roots it may read, --workspace the work tree and context tools, and --owner every tool. rig mcp token list shows grants (never their tokens) and rig mcp token revoke <name> refuses that caller's next request.
• TLS comes from the tunnel or proxy, not from this server.

What 0.7.4 adds

The local MCP route already works. For a cloud-hosted assistant, 0.7.4 adds hosted members: a roster entry marked "hosted": true, with an inbox, work it can claim and answer, and a grant you can revoke. Hosted members are experimental, unsupported and off by default; use at your own risk. Only Grok was tried: it claimed work, returned a useful result, came back in a new conversation and was refused after revocation, with its work kept.

A compatible runner can declare a webhook trigger using secret names. A successful ring means the endpoint accepted it, not that the member woke. If it does not claim the work in time, its person is told. No webhook consumer was shown waking from a ring, and the notice to a hosted member's person was not shown with a registered person. rig_team and rig roster show show its last MCP call; rig_team also shows its latest ring.

For advanced remote setups, --grant-service <url> checks each request's key without caching. --oauth-resource and --oauth-issuer add OAuth sign-in discovery; the key and grant still decide what the caller can do. Internet-facing use is experimental, unsupported, off by default and at your own risk, with the token and TLS precautions above.

MCP clients on protocol revision 2026-07-28, which has no initialize handshake, work alongside 2025 clients over stdio or HTTP. An SDK 2.x client was shown at installed scope. See the 0.7.4 release notes for the complete verification limits.

Every tool, with its input schema

Generated from the current release's server, its own tools/list, without calling any tool: the full tool list (required inputs marked; full JSON schemas kept; the list's first line names the release). The server grew from 18 tools to 23 in 0.6.12 (queue tools), to 34 in 0.7.1 (identity, restore status, a rig's team and lead, following a handoff, reading a result, deciding in a person's decision room, and --http), to 36 in 0.7.2 (rig_queue_handoff, rig_queue_unclaim), and to 37 in 0.7.8 (rig_environment_export, part of the OpenShell reference, which isn't usable in 0.7.8). 0.7.3 to 0.7.7 serve the same 36.

The mcp family

What it does not do

• It is not a second control plane. Every tool is a thin call into the same daemon routes the CLI uses, and anything that touches a rig needs the daemon running.
• Without a grant, the seat is declared, not proven: anything that can start the server can name any seat.
• A question reserved for a person stays theirs. rig_queue_decide records a decision only inside the decision room of the mode the person has on, beside their answers and never as one.
• Tools were listed, not called, to produce the reference; trust the schema over any example.

Where it goes next

• Messaging: what rig_send and rig_capture mean, and what verify does and does not prove.
• Lifecycle: what rig_up, rig_down and rig_add mirror.