Wiring alternatives

Wire your agent covers the default path: rcf init registers the MCP server in the project-root .mcp.json and writes a managed instructions block into CLAUDE.md and AGENTS.md, and a harness that reads those files at session start picks all of it up. Claude Code is the harness that path is verified against. If yours works differently, the wiring splits into two halves you can place by hand: the MCP server entry, and the instructions fragment. This page covers placing each, and is honest about where no supported path exists yet.

Start with:

rcf init --no-agent-setup

That scaffolds the tree only and prints the manual wiring steps, with the MCP server path already resolved for your machine. The two halves it names are the subjects of the next two sections.

An MCP client that does not read .mcp.json

The rcf MCP server is served over local stdio by the rcf mcp verb; there is no separate server binary. The entry init would have written is:

{
  "mcpServers": {
    "rcf": {
      "command": "node",
      "args": ["<path-to-installed-rcf-lite>/bin/rcf.js", "mcp"]
    }
  }
}

with the real path filled in, which is exactly what the --no-agent-setup output prints for you. Any client that can launch a local stdio MCP server can run this; put the same command and arguments wherever your client keeps its MCP server configuration, and consult your client's own documentation for where that is. We have not verified specific clients beyond the default path, so this page will not pretend to walk their settings screens.

Two limits, stated plainly. The server is stdio only: if your client only speaks to remote MCP servers over HTTP, there is no supported way to connect it today. And the server addresses the project in the working directory it is launched from, so launch it from the project root.

A harness that reads instructions from somewhere else

The instructions half is a markdown fragment, and the shipped package is its source of truth:

rcf guidance harness-template

Paste the fragment (the first ```markdown fence in that output) into whatever file your harness actually reads at session start. The content is identical to what init writes into CLAUDE.md and AGENTS.md, and the harness block publishes the same text if you want to read it first. Then restart the session so the harness re-reads both its MCP configuration and its instructions.

An agent with no MCP support at all

Every MCP tool mirrors a CLI verb with the same JSON envelope, so an agent that can run shell commands can run the method without MCP: rcf define validate, rcf build queue, rcf audit coverage and the rest of the CLI reference are the same contract the MCP tools expose. Wire the instructions fragment in as above, and the agent works the CLI directly.

What you lose without MCP is real: the two playbook prompts (rcf_elicit_requirements and rcf_execute_build_cycle) are MCP prompts, and the tree does not arrive as resources. The playbooks themselves are still readable, by you or your agent, via rcf guidance elicitation-playbook and rcf guidance build-cycle-playbook, but nothing hands them to the agent automatically. Expect to steer more.

CI

CI needs no agent wiring at all; it needs verbs with honest exit codes, and that is the CLI's native shape:

rcf define validate          # exit 3 when the tree is unsound
rcf audit coverage --strict  # exit 4 on any per-criterion coverage gap

Wire those into a pipeline and nothing structurally broken or unspecified gets merged. The full code table is in exit codes.

Where this leaves you

Whichever route you took, the test of the wiring is the same as on the default path: start a session and ask the agent to build. If it starts asking you elicitation questions rather than drafting documents, the wiring took.