MCP surface

The rcf MCP server is registered by rcf init into your project-root .mcp.json, and served over stdio by the rcf mcp verb. A harness that reads .mcp.json at session start picks it up automatically; others can point at rcf mcp directly, and Wire your agent covers what to check when the wiring does not take. Where a tool mirrors a CLI verb, the verb is named; all of them are in the CLI reference.

Reading the tree

rcf_validate

Reports whether the tree is structurally sound: schema violations, broken references and stale Code Node pointers across every document. Issues come back as data, not as a tool error; the issues are the answer. The pack instructs the agent to run it first in any session and again after every tree edit. CLI: rcf define validate.

rcf_coverage

Reports which requirements have at least one complete chain down to a test case. A test case counts only when its pointer resolves to a real test in the working tree; a row whose pointer leads nowhere is reported as covered-unresolved, its own class, never as coverage. Strict mode demands per-criterion coverage; a PRD id scopes to its requirements, a REQ id to that requirement, and a US id to the requirement that owns that story. CLI: rcf audit coverage.

rcf_trace

Answers "what hangs off this document" (forward), "what does it hang off" (back), or both, from any document id. Given a source path instead of an id, it resolves through the matching Code Nodes and traces back up to the root, so "why does this file exist" is answerable from the code side too. CLI: rcf audit trace.

rcf_impact

The before-you-change-it query: fans out from one document to every ancestor and descendant a change would touch, each labelled with the action it needs (re-run, re-verify, review-scope and friends). The pack instructs the agent to run it before changing anything with dependents. CLI: rcf audit impact.

rcf_read

Returns one document's body, or a single field of it, by id, including inline acceptance criteria and test cases. The method note it carries: read the real document before editing it; updates patch what exists, never a remembered body. CLI: rcf define read.

Writing the tree

rcf_create

Creates a document of a given kind. Inline kinds (acceptance criteria, test cases) mutate their parent document; every other kind writes one new file. The description itself restates the method's first rule: chain content is elicited with the stakeholder, never fabricated in one shot. CLI: rcf define create.

rcf_update

Patches fields on an existing document, by dot-path or deep merge, and refuses to touch identity fields. CLI: rcf define update.

rcf_delete

Deletes a document. Refuses by default when anything depends on it; cascading and dry-run variants exist, and the tool's own advice is to run rcf_impact first when unsure what hangs off the target. CLI: rcf define delete.

rcf_link

Appends architecture component links to a user story, idempotently, returning the post-state. This is how the tech layer of the chain stays attached to the stories that depend on it. CLI: rcf define link.

rcf_unlink

The reverse of rcf_link, with the matching honesty note: unlink only what the stakeholder agreed no longer applies. CLI: rcf define unlink.

Driving the define loop

rcf_define_readiness

Computes the readiness verdict for the current tree: two levels (intent-complete and ready-to-build), per-stage D1 to D8 checks each tagged with a persona (product owner or engineer), blockers grouped by persona, and the next action for the current register. The compute is pure; it never writes under rcf/. CLI: rcf define readiness.

rcf_define_questions

Turns every failing product-owner check in the readiness result into one plain question carrying its exact write-back: the real create, define update and ledger brief resolve sequence that answers it. The harness drives the loop by writing back and reading rcf_define_readiness until levels.intentComplete.ok. CLI: rcf define questions.

rcf_define_ledger

Reads and writes the four DEFINE sidecar ledgers under rcf/define/: brief (D1 statements, kinded from the closed set), decisions (D7), concerns (D5) and probes (D6). Verbs are add, update, resolve and list; brief add --from <file> splits a statement file one per non-empty line and promotes the open-question shortcuts (?, TBC, TBD, Open:, Question:) to the openQuestion kind. CLI: rcf define ledger <name> <verb>.

Driving the build

rcf_build

Assembles the complete spec bundle for one work item: the work itself, queue and dependency context, acceptance criteria with their ancestry, architectural context, the existing test surface and the completion contract. Bundle assembly is mechanical; it projects what the tree says and leaves judging the item's quality to the review gates. CLI: rcf build bundle.

The seven prompts

rcf_execute_build_cycle

Serves the build-cycle playbook: per-stage guidance, referee commands, failure modes and escalation rules for the five-stage loop. The shipped guidance tells the agent to fetch it once per session, then drive the queue.

rcf_elicit_requirements

Serves the elicitation playbook: question frames for PRD, REQ, US and AC, guidance for TAC and ADR capture and BS/FBS queue construction, and the quality bar for a testable acceptance criterion. It tells the agent to write records as answers arrive and defines when elicitation is complete.

rcf_define_intent

Argument-free prompt that drives the product-owner intent-complete loop: start with --persona productOwner, call rcf_define_questions, answer each question through its carried write-back (rcf_create, rcf_update, rcf_define_ledger), and finish when levels.intentComplete.ok is true.

rcf_define_intake

Argument-free prompt that walks a document folder brief-first, writes one statement file per source with [kind] and (source: ...) markers, runs rcf define ledger brief add --from once per source, and reports the scan findings as open questions on the brief ledger.

rcf_define_draft_shapes

Argument-free prompt that runs the engineer's draft pass in parallel with the product-owner loop and reconciles when intent-complete is reached: pre-populates [draft] core entities per entity statement, [draft] TAC stubs per surface or external-system cluster, [draft] interfaces with real kinds inside each stub, and rcf discover req-classify over every REQ created in the loop.

rcf_define_litmus

Argument-free prompt that drives the D6 litmus pass: spawn n fresh-context readers at the current tree hash, have each read the elicitation prompts in isolation, and land their readings as probe-ledger entries whose finding begins litmus:<reader>: and whose text includes the current litmus hash. The paired flag --litmus <n> on rcf define readiness and rcf define freeze then passes only when n distinct readers have recorded a reading at that hash; the litmus hash is the tree hash computed with the probes ledger excluded, and readiness --json prints it. No process is spawned by the compute itself and no network call is made; the harness lands the readings through rcf define ledger probes add.

rcf_discover_prototype

Argument-free prompt that records a prototype in DISCOVERY as evidence: classification, brief statements with prototype:<name>:<observation> source spans, the single constraint that burns the code, and the salvage-by-re-derivation path. The shipped doctrine lives at guidance/discovery-prototypes.md.

Every prompt serves the same bytes as the matching page in the shipped pack; MCP and the public URLs are two routes to one shipped pack.

The verify server

Adversarial verification has its own MCP server, served over stdio by the rcf verify mcp verb. It is separate from the rcf server above: rcf init does not write it into .mcp.json, so a harness that wants it registers rcf verify mcp itself. It exposes one tool and no prompts.

rcf_verify_run

Launches a fresh-context adversarial verifier against a running app under a declared runtime profile and returns a structured verdict stamped with the runtime it ran against. It takes the chain source (repo), the runtime profile (deployed, ci or local-dev) and the app url, plus optional chain reference, parity assertion, provisioning file, persona and severity gate. Only a deployed profile, or a non-deployed one with the parity assertion, can yield a SHIP verdict. The report comes back inline, so no output file is needed over MCP; it is an independent ship-readiness signal, not a correctness guarantee. The Test-stage report that finalise ingests comes from the CLI (rcf verify run --fbs <fbs-id> --hand verifier), which Close the loop without a deploy walks. CLI: rcf verify run.

Pinned against: rcf-lite@0.36.1. Tool names, prompt names and every behaviour above are taken from that installed package's MCP server sources (build and verify) and guidance manifest.