Wiring alternatives

Wire your agent covers the default setup, verified against Claude Code. rcf init registers the MCP server in the project-root .mcp.json and writes a managed instructions block into your agent instructions file (CLAUDE.md if it exists; otherwise AGENTS.md if that exists; both are created only when neither is present). A harness reads those files at session start. For other harnesses, you can place the MCP server entry and instructions fragment manually. This guide explains both and identifies configurations that are not yet supported.

Start by asking your agent, or run it yourself:

AIScaffold the RCF document tree in this repo without touching any agent config, and print the manual wiring steps for me.

Terminalrcf init --no-agent-setup

That scaffolds the tree only and prints the manual wiring steps, with the MCP server registration snippet already resolved. 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, and the one --no-agent-setup prints for you, is the portable form:

{
  "mcpServers": {
    "rcf": {
      "command": "npx",
      "args": ["rcf-lite", "mcp"]
    }
  }
}

That way the entry keeps working across upgrades and does not bake an install path into the config file. If you would rather pin a specific installed copy (a monorepo tool cache, a hermetic CI image), the pinned-install alternative uses the resolved absolute path:

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

Any client that can launch a local stdio MCP server can run either shape; 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 resolves the project root by looking for the nearest rcf/manifest.json from its working directory or its ancestors, so launching it from anywhere inside a project tree is fine; if you need to point it at a specific project (a monorepo, a nested tool workspace), pass --project-root <path> on the rcf mcp command.

A harness that reads instructions from somewhere else

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

AIShow me the RCF instructions I paste into my agent's setup.

Terminalrcf 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 or 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

An agent that can run shell commands can run the method without MCP. The full CLI surface is available (see the CLI reference); of that, eleven core document, query and bundle operations have direct MCP twins. JSON-envelope parity holds for a specific subset of those twins: rcf define validate under --json, the query family under --format json, and rcf build bundle <fbs-id> --format json. The read and write MCP tools (create, read, update, delete) each return their own stable envelope that mirrors the same underlying operation but is not byte-identical to a plain CLI text output; use --format json where the CLI verb offers it. The wider CLI (workflow verbs like rcf build queue, wiring verbs like rcf init, and the doctor) remains CLI-only. As a rule of thumb: to fetch the same JSON an MCP client would see for a build item, use rcf build bundle <fbs-id> --format json, not rcf build queue; the two do different jobs.

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 the mechanical failures they cover are gated at merge time: schema violations, broken references between documents, Code Node source drift, companion-pin failures, and per-AC test-coverage gaps under strict mode. What the gates do not do is prove semantic completeness: they cannot tell you whether the chain describes the right product, whether an acceptance criterion states the right behaviour, or whether a test asserts the outcome that matters. Judge those separately (see what the referee guarantees). 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 stops to ask elicitation questions before authoring, and only writes each level of the chain from your elicited answers rather than jumping straight to a full draft, the wiring took. Incremental drafting during an elicitation is expected; jumping past the elicitation altogether is the failure mode.