rbs integrates with the Model Context Protocol in both directions:
- As a server —
rbs mcp serve exposes the agent’s tool surface (graph queries, build/test, search, skills) to any MCP client: Claude Desktop, Claude Code, ChatGPT, or your own tooling.
- As a client — MCP servers declared in your workspace give the rbs agent extra tools (a browser, a database, an internal API) for its sessions and for
ai_task targets.
Serving rbs as an MCP server
In stdio mode the server speaks MCP on stdin/stdout. In HTTP mode, point your client at http://localhost:3001/mcp.
A Claude Desktop configuration looks like:
Run it from (or configure the client to start it in) your workspace directory — the server loads the workspace so graph and authoring tools answer from your real target graph.
By default the server exposes a curated subset of the agent’s tools: file reading, search, the graph and knowledge-graph queries, build/test, dependency inspection, and skills. Several tool categories are excluded on purpose:
- Interactive tools that block waiting on the rbs UI (they would hang your client)
- Agent-loop internals (todo management, plan mode) that only make sense inside the rbs agent’s own loop
- Agent-spawning tools (delegation, background agents) that would issue LLM calls from inside the server
- Write tools that mutate the workspace or run commands — excluded unless you opt in
Adjust the surface with flags shared by serve and list:
--allow-write and --tools full let a connected client edit files and execute commands in your workspace. Only enable them for clients you trust, and prefer --exclude-tools to trim anything you don’t want reachable.
Previewing the surface
rbs mcp list prints exactly what a connected client would see, honoring the same flags — including which tools are excluded and why:
Skills as resources and prompts
Beyond tools, the server publishes the agent’s skill corpus:
- every skill is an MCP resource under
rbs://skills/<name> (for example rbs://skills/bootstrap-workspace, rbs://skills/using-go-rules)
- two composed prompts let a client bootstrap rbs context in one call:
rbs-onboarding (workspace bootstrap, monorepo conventions, verification discipline) and rbs-build-file-authoring (how rules and BUILD.rbs files work)
This is how an external agent working in your workspace gets the same maintained guidance the built-in agent runs on.
ReasonOS also exposes a project-work MCP service. It is separate from
rbs mcp serve: rbs tools work on the branch’s files/build graph and task
cards, while ReasonOS tools work on project issues and other platform records.
On a managed branch server, the built-in agent, Claude Code, Codex and Gemini
can use the ReasonOS service with the person’s session delegation, including
from agent-enabled terminals. The delegation is scoped to that node’s project;
tools enforce the same permissions and product access as the application’s
routes. Do not copy vendor tokens or a coworker’s credentials into the repo.
Useful issue tools include:
work_board and list_tasks: read statuses and issues in the project.get_task: read an issue by its project number, including its work context.create_task, update_task and move_task: create or edit an issue and
update its status.comment_on_task and link_task: record progress and connect related work.
Other tools cover cycles, labels, initiatives and proposals. Ask the agent to
read its available tools rather than assuming the standalone rbs task tools
refer to project issues. For example:
Read issue 42 in this project, move it to In Progress, and add a comment
describing your plan. Keep the issue updated as you work.
Read the resulting issue activity to verify what the agent actually did.
An agent can only take actions your delegated identity is allowed to take.
Delegating an issue to another branch
delegate_issue_to_branch takes a project, issue number, linked branch and
the id of an existing instruction comment written by you. An agent’s own
comment is not a substitute for that human instruction. The target must
already be linked to the issue.
With no target server running, the operation refuses unless start_server
is explicitly true. Starting one consumes a server slot and remains subject
to the project’s permissions and capacity limits.
The result distinguishes admitted, refused and unknown. Admitted
means the target accepted the instruction, not that it completed the work.
Unknown means delivery may have happened without a readable acknowledgment.
The tool does not automatically replay a request; check the issue activity
before asking again. The target agent reports its result on the issue.
This does not run git checkout on the requesting shared server or give an
agent unrestricted access to other projects.
Connecting external MCP servers to the agent
Declare MCP servers in your WORKSPACE.rbs with native.define_mcp_server(). The agent connects to them at session start and their tools appear alongside the built-ins.
One of command (stdio) or url (HTTP) is required. The optional toolchain names a registered rbs toolchain whose runtime should resolve the command — so npx above runs from the workspace’s hermetic Node toolchain rather than whatever is on PATH.
Skip connecting for a session with rbs agent --no-mcp.
For browser automation, rbs bundles a helper that registers a Chrome DevTools MCP server — this is what powers ai_qa_test browser tests:
MCP in ai_task targets
Headless agent tasks name the servers they need with the mcp attribute; only those servers are connected for the run:
MCP and the external engines
When a session runs on an external engine, rbs
configures the agent with the workspace’s declared MCP servers and rbs’s own
tools. Managed branch sessions also receive the scoped ReasonOS Work service
described above. These services have different permissions and purposes;
enabling a standalone rbs MCP server alone does not connect it to ReasonOS
project issues. 
