Provides setup steps, an MCP entry, and an AGENTS.md snippet for GitHub Copilot's coding agent and other agents, enabling access to RepoPilot's local scan and review tools.
Local, deterministic review for Git changes.
RepoPilot helps developers and teams inspect a change before merge. It reports structural evidence about security boundaries, behavior, local imports and exports, and the files affected through the dependency graph. The same review can run from a terminal, in CI, or through an agent integration.
The analysis runs on the machine or CI runner that invokes it. It does not send source to a hosted service or call an embedded language model. Findings point to code and explain what to check; reviewers still decide whether a change is safe for their application.
This change drops a range check from applyDiscount. The same change skips the
test that would now fail, removes an assertion from another test, and lets the
CI test step fail without failing the job. Every check that still runs passes.
repopilot review . lists them right after its decision:
Decision: REVIEW (Change Proof: REVIEW)
...
Checks this change weakened (details under Review signals):
⚑ check gate relaxed — .github/workflows/ci.yml:10
⚑ assertions removed — src/pricing.test.ts:5
⚑ test skipped — src/pricing.test.ts:9Further down, each signal explains itself:
⚑ check gate relaxed — .github/workflows/ci.yml:10 check step `npm test` in job `test` now has `continue-on-error: true`
⚑ assertions removed — src/pricing.test.ts:5 "applyDiscount > takes a percentage off the total": assertions 2 → 1
⚑ test skipped — src/pricing.test.ts:9 `it.skip` added on "rejects a discount above 100%"; its result no longer fails the runThese are excerpts of one run (recording). Replay it with
scripts/demo-weakened-tests.sh <empty-dir>, then run repopilot review <empty-dir>.
Related MCP server: FixMap
cargo install repopilot
# or
npm install -g repopilot
repopilot review . --base origin/mainFor uncommitted work, run repopilot review .. The first screen gives one
PASS, REVIEW, BLOCK, or NOT ASSESSED decision, its reasons, coverage
limits, and a next action.
A review can surface:
changes to authentication, request trust, deployment, dependencies, or secret configuration;
added or removed behavior such as network calls, subprocesses, filesystem writes, SQL, or error handling;
changed input-to-sink paths, algorithmic structure, or local import/export contracts;
tests the change stopped running or weakened: committed focus markers such as
it.only, newly skipped tests (it.skip, @pytest.mark.skip, t.Skip,
#[ignore]), removed or substituted test cases, tests that lost assertions,
new lint, type, or coverage suppressions, and relaxed CI or tool gates
(continue-on-error, || true, lowered coverage thresholds, strict mode
off), so a green run cannot hide them;
direct dependents and the wider impact of changed files.
Signals are advisory evidence. For example, a taint-lite signal shows that a recognized input can reach a recognized sink in the changed source. Confirm the impact in the context of the application and its configured checks.
The Wagtail example removes an authorization check and passes request data to a subprocess in a one-file change. RepoPilot reports both the boundary change and the input-to-process flow.
Replay the example on the pinned test repository:
python3 scripts/zoo.py clone --only wagtail
scripts/demo-agent-edit.sh .zoo/wagtail
repopilot review .zoo/wagtailA reported flow is a path to investigate. RepoPilot does not prove that it is exploitable or that the application is safe.
Gate a branch review on high-confidence signals:
repopilot review . --base origin/main --fail-on-review definitelyA review is VERIFIED only when checks configured for the repository are
explicitly selected with --verify and pass on the reviewed revision. Generate
suggestions for a first setup with
repopilot init --suggestions-output repopilot-suggestions.toml; the file is
separate from active configuration. See configuration.
For a broader repository view, run repopilot scan .. Use
repopilot baseline create . to adopt existing findings before gating new work.
The same review can check work from a human or a coding agent. Record a starting point and review the changes made since it:
repopilot snapshot
# Work happens here.
repopilot review --since-snapshotWhen the working tree is already dirty, the marker also records a baseline commit of those uncommitted files, so the later review covers only what changed after the snapshot. It shows what changed, not who changed it. See common workflows.
In Claude Code, the RepoPilot plugin runs that loop for every session and stops Claude from finishing while a test it skipped, focused, removed, or weakened is unexplained:
/plugin marketplace add MykytaStel/repopilot
/plugin install repopilot@repopilotCodex installs the same plugin (codex plugin marketplace add MykytaStel/repopilot, then codex plugin add repopilot@repopilot). Gemini CLI installs it as an
extension (gemini extensions install https://github.com/MykytaStel/repopilot),
and Cursor runs it through project hooks. For GitHub Copilot's coding
agent and other agents, RepoPilot provides setup steps, an MCP entry, and an
AGENTS.md snippet. See Guard your agent runs.
RepoPilot also provides a local stdio MCP server and a GitHub Action. The MCP
server gives an agent access to the local scan and review tools. The Action runs
RepoPilot on the Actions runner and can publish SARIF or a pull request summary.
See Guard your agent runs, MCP server,
and GitHub integration. MCP Registry
name: mcp-name: io.github.MykytaStel/repopilot.
repopilot ai context . creates a local handoff with repository facts,
findings, and a prioritized plan. It makes no model calls.
repopilot init creates configuration or integration files for review.
Reports are available as console, Markdown, JSON, HTML, and SARIF.
Contributing and development setup: CONTRIBUTING.md.
MIT OR Apache-2.0.
Generate a budgeted Markdown brief of the repository (risks, hotspots, structure) to read before editing, especially in an unfamiliar codebase. Use it for orientation. For the full findings as JSON, use repopilot_scan; to review a change, use repopilot_review_change. Pass analysis_handle to make sure the brief still matches an earlier scan or review. Built locally from a scan; no AI service is called and nothing is uploaded.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Repository path. Defaults to the current working directory. | |
| focus | No | Optional focus: security, architecture (or arch), quality, framework, or all. | |
| budget | No | Optional approximate token budget for the brief. Defaults to the standard budget. | |
| config | No | Optional repopilot.toml path. Defaults to the one discovered in the repository. | |
| profile | No | "default" hides low-signal suggestions; "strict" includes all findings. | default |
| analysis_handle | No | Optional `analysisHandle` from an earlier repopilot_scan or repopilot_review_change call. The call fails if the workspace changed since that analysis. |
| Name | Required | Description |
|---|---|---|
| decision | No | Canonical primary review decision and next action from the referenced review handle, when selected. |
| evidence | No | Canonical evidence class, coverage, and provenance from the referenced review handle, when selected. |
| markdown | Yes | |
| change_proof | No | Canonical ChangeProof from the referenced review handle, when selected. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the readOnly/idempotent annotations by disclosing that the brief is built locally from a scan, no AI service is called, nothing is uploaded, and that passing analysis_handle will cause the call to fail if the workspace changed since that analysis. The failure condition in particular is non-obvious behavioral context an agent needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the deliverable and its use case, then sibling routing, then the handle-matching caveat, then the local-execution guarantee. Every sentence carries distinct information and nothing is repeated from the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists so return values need no explanation in prose. With usage context, sibling routing, parameter linkage, and execution/safety notes all covered, an agent has everything needed to select and invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all six parameters including defaults and the enum meaning for profile. The description only reinforces the purpose of analysis_handle ('make sure the brief still matches an earlier scan or review') without adding syntax or format detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Generate a budgeted Markdown brief of the repository') and names what the brief contains (risks, hotspots, structure) plus its intended purpose (read before editing). This clearly distinguishes it from repopilot_scan's JSON findings and repopilot_review_change's change review.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use it ('especially in an unfamiliar codebase. Use it for orientation') and routes the agent to alternatives by name: repopilot_scan for full JSON findings, repopilot_review_change for reviewing a change. Both the when and the when-not are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Explain how RepoPilot treats one file: the role it assigns (for example test, generated, config, or CLI command handler) and the evidence for it, which rules apply, the ordered overrides that change a rule's severity, and whether the default profile would show the result. Use it to understand a file without a report, or to ask why a rule (rule, optionally one detector signal) would or would not fire there. To explain a finding already in a scan or review, use repopilot_explain_finding; for a review signal, use repopilot_explain_review_signal. Reads local files only and returns JSON.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Path to the file to explain. | |
| rule | No | Optional rule ID (see the repopilot://rules resource) to focus the explanation on. | |
| signal | No | Optional detector signal within `rule` to focus on, e.g. "rust.todo" for language.rust.panic-risk. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered structurally. The description still adds real behavior: it reads local files only and returns JSON, and it discloses that overrides are ordered and can change a rule's severity — information that is not in the annotations. It does not detail pagination/limits, but for a read-only explainer that is minor.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the primary purpose then the routing guidance. Dense but every clause carries information; the inline parenthetical role examples are the only slight padding, and they illustrate the output meaningfully.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists, so return values need not be described. The description covers purpose, scope (local files only), the optional narrowing parameters, and correct sibling routing, leaving no gap an agent would need filled before calling it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% so the baseline is 3, but the description adds meaning beyond the schema by framing `rule` and `signal` as a query ('ask why a rule would or would not fire there') and clarifying that `signal` narrows within `rule`. This ties the two optional parameters to a purpose, not just a type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Explain how RepoPilot treats one file') and enumerates exactly what the explanation contains: assigned role with evidence, applicable rules, ordered severity overrides, and default-profile visibility. It names the sibling tools it is not (repopilot_explain_finding, repopilot_explain_review_signal), so an agent can disambiguate without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit use cases ('understand a file without a report', 'ask why a rule would or would not fire there') and explicit routing rules: use repopilot_explain_finding for a finding already in a scan/review and repopilot_explain_review_signal for a review signal. Both when-to-use and when-to-use-something-else are covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Explain why a finding was reported. Use it when you have a finding_id from repopilot_scan or repopilot_review_change in this session and need to know why it fired or whether it still reproduces. It replays the stored rule decision against the current workspace, returns the full decision trace, and reports whether the decision matched or drifted. For a review signal (signal_id), use repopilot_explain_review_signal; for a file with no finding, use repopilot_explain_file. Local-only.
| Name | Required | Description | Default |
|---|---|---|---|
| source | No | Which report holds the finding: the latest repopilot_scan ("last-scan") or the latest repopilot_review_change ("last-review"). | last-scan |
| finding_id | Yes | Stable finding ID from the findings array of the selected session report. | |
| line_start | No | Optional evidence start line from an ambiguity candidate. | |
| evidence_path | No | Optional evidence path from an ambiguity candidate. Used with line_start to select one occurrence without changing the stable finding ID. | |
| analysis_handle | No | Optional `analysisHandle` from an earlier scan or review in this session, to use that report instead of the latest one. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (readOnly, idempotent, non-destructive, not open-world), and the description adds genuinely new behavior: it replays the stored rule decision against the current workspace, returns a full decision trace, and reports matched vs. drifted. The 'Local-only' note also signals no external side effects, which the annotations alone do not convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four short sentences, front-loaded with purpose, then when-to-use, then the alternatives, then the local-only qualifier. Every sentence carries distinct routing or behavioral information with no restatement of the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return structure need not be documented, yet the description still summarizes what comes back (decision trace, match/drift verdict). Combined with the session-scoping rule and sibling routing, an agent has everything needed to call this correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the per-parameter descriptions already do the heavy lifting. The description adds provenance semantics the schema does not state: the `finding_id` must come from a prior scan/review in this session, and it distinguishes the `signal_id` case that belongs to a sibling tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('Explain why a finding was reported') and immediately scopes it to a `finding_id` originating from named sibling tools. It explicitly names the sibling tools to use instead for other inputs (repopilot_explain_review_signal, repopilot_explain_file), so an agent can route without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit when-to-use condition ('when you have a finding_id from repopilot_scan or repopilot_review_change in this session and need to know why it fired or whether it still reproduces') plus two named alternatives with the exact condition that selects each. Nothing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Explain one signal from a review: where it came from, its confidence tier, whether it can fail a gate, the files it affects, how to verify it, and its limits. Use it after repopilot_review_change, with a signal_id from that report's tiered_signals. For a finding (finding_id in the findings array), use repopilot_explain_finding instead. Reads the stored review only; it runs nothing and changes nothing.
| Name | Required | Description | Default |
|---|---|---|---|
| signal_id | Yes | The `signal_id` of an entry in the review report's `tiered_signals`. | |
| analysis_handle | No | Optional `analysisHandle` from an earlier repopilot_review_change call. Omit to use the latest review in this session. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and a closed world, so the safety profile is covered. The closing sentence ('Reads the stored review only; it runs nothing and changes nothing') largely restates those hints, though 'runs nothing' adds a small amount of extra assurance about side effects. Beyond that it discloses no additional behavioral traits such as lookup failure modes when a signal_id is unknown.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core verb and resource, then a dense enumerated list of what is explained, followed by prerequisites and the sibling handoff. Every sentence carries routing or scoping information; the enumerated list is slightly long but each item is substantive.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be described, and the annotations already carry the safety profile. The description completes the picture with the call sequence, argument provenance, the alternative tool for findings, and the fact that no state changes occur.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters, including that `analysis_handle` falls back to the latest review. The description reinforces that signal_id must come from `tiered_signals` but adds no syntax, format, or edge-case detail beyond the schema. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource (explain one review signal) and enumerates exactly what it returns: provenance, confidence tier, gate-failure capability, affected files, verification steps, limits. It explicitly distinguishes itself from the sibling repopilot_explain_finding, so an agent can route without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit precondition (use after repopilot_review_change) and the exact source of the required argument (the `signal_id` from that report's `tiered_signals`). It also names the alternative tool and the condition that selects it: findings use repopilot_explain_finding instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Review a Git change locally: what it touched and which checks it weakened. Use it before finishing work or before a merge. By default it reviews uncommitted work (working tree vs HEAD); pass base (e.g. "origin/main") to review a branch. For a repository health check that is not about one change, use repopilot_scan instead. Returns a JSON report with a decision, findings on changed lines vs the rest, blast radius (files that import the changed files), and deterministic signals grouped by confidence tier (definitely / maybe / noise) in tiered_signals: checks the change weakened (focused or skipped tests, removed tests, tests that lost assertions, new lint/type/coverage suppressions, relaxed CI or tool gates); security-boundary changes (auth, CORS, CI, dependency manifests, committed .env); behavioral changes (network, subprocess, filesystem, env, dependency, migration, or raw SQL added; error handling, an auth check, or a test removed; a removed named TypeScript/JavaScript export that a resolved local caller still imports); algorithmic changes (deeper nesting, a new nested loop, a grown function, new recursion); and taint-lite reachability (HTTP request or process arguments reaching SQL, exec, filesystem-write, or outbound-network sinks in a changed function). Signals are evidence, not verdicts; explain one with repopilot_explain_review_signal. RepoPilot uploads nothing. Only a non-empty verify array runs commands: the configured local checks, which may modify workspace files or contact external systems. Their captured output is bounded and redacted.
| Name | Required | Description | Default |
|---|---|---|---|
| base | No | Base Git ref to diff against, e.g. "origin/main". Optional; defaults to the working tree vs HEAD. | |
| head | No | Head Git ref. Optional and only valid together with "base". | |
| path | No | Repository path to review. Defaults to the current working directory. | |
| limit | No | Maximum findings to return. | |
| scope | No | "changed" reports findings in the changed files only; "full" also returns findings from the rest of the repository. | changed |
| config | No | Optional repopilot.toml path. Defaults to the one discovered in the repository. | |
| detail | No | "compact" returns at most 20 findings and 20 signals; "full" returns all of them. | compact |
| intent | No | Optional inline statement of what the change is meant to touch (paths, contract families, critical paths, verification IDs). The report marks drift outside it. It is metadata only and cannot execute commands. | |
| offset | No | Zero-based finding offset. | |
| verify | No | IDs of checks configured in repopilot.toml to run on the reviewed revision. They run as local processes. Omit to run nothing. | |
| filters | No | Optional thresholds and rule IDs that narrow the returned findings. | |
| profile | No | "default" hides low-signal suggestions; "strict" shows all findings. | default |
| baseline | No | Optional baseline file (from `repopilot baseline create`). Findings recorded in it count as accepted debt, separate from new findings. | |
| intent_path | No | Optional repository-rooted TOML file that states what the change is meant to touch. The report marks drift outside it. Use either this or `intent`, not both. | |
| fail_on_review | No | "definitely" fails the report's gate when a gate-eligible definitely-tier signal is present; "none" reports signals without gating. | none |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds substantial context beyond annotations: signals are evidence not verdicts, RepoPilot uploads nothing, only a non-empty verify array runs commands, those commands may modify workspace files or contact external systems, and output is bounded and redacted. This aligns with and enriches destructiveHint=true and openWorldHint=true without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with purpose, usage, and alternative routing, then details return structure and safety constraints. It is long because the tool is complex, and most sentences earn their place, though the single dense sentence enumerating signal categories is harder to scan than it could be.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 15-parameter schema, output schema, nested intent/filters objects, and destructive/open-world annotations, the description is complete. It covers usage, safety, side effects, return shape, tiered signals, and the explain-sibling for signal details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description still adds useful semantic framing for key parameters: base defaults to working tree vs HEAD, verify IDs run configured local checks, and intent is metadata-only and cannot execute commands. This is meaningful beyond the schema for high-impact fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: review a Git change locally, covering what it touched and which checks it weakened. It explicitly distinguishes itself from repopilot_scan for repository health checks, so an agent can route correctly without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit timing guidance (before finishing work or a merge), default behavior (uncommitted work vs HEAD), how to review a branch (pass base), and names the alternative for non-change health checks. When/when-not/alternative are all present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Audit a repository, folder, or file for findings across architecture, coupling, code quality, security, and testing, and return the JSON scan report (findings, metrics, risk summary). Use it for a health check that is not about one change. To review what a change touched or which checks it weakened, use repopilot_review_change; for a short Markdown brief to read before editing, use repopilot_context. Explain a returned finding with repopilot_explain_finding. Runs entirely on disk; nothing is uploaded.
| Name | Required | Description | Default |
|---|---|---|---|
| base | No | Base Git ref for "changed" scope, e.g. "origin/main": scans files changed between base and HEAD. Without it, "changed" means changed against HEAD, including untracked files. | |
| path | No | Path to scan. Defaults to the current working directory. | |
| limit | No | Maximum findings to return. | |
| scope | No | "full" scans every file under `path`; "changed" scans only changed files (against HEAD, or against `base` when given) and skips repository-level rules. | full |
| config | No | Optional repopilot.toml path. Defaults to the one discovered in the repository. | |
| offset | No | Zero-based finding offset. | |
| filters | No | Optional thresholds and rule IDs that narrow the returned findings. | |
| profile | No | "default" hides low-signal suggestions; "strict" shows all findings. | default |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds a genuinely new behavioral fact not in the structured data: 'Runs entirely on disk; nothing is uploaded.' It does not discuss pagination/limit behavior further, so it falls short of a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, front-loaded with the core purpose and return value before routing guidance. Every sentence is functional, though the sentence count is on the higher side; it is efficient rather than padded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return values need not be detailed, and the description still names the report contents. Annotations cover safety, the schema covers all 8 params, and alternatives are routed explicitly, so an agent has everything needed to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so scope, base, profile, filters, limit and offset are all fully documented in the schema itself. The description adds no parameter syntax, defaults, or interaction rules beyond what the schema already provides, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Audit a repository, folder, or file for findings') and enumerates the domains covered (architecture, coupling, code quality, security, testing) plus the return shape (JSON scan report). It explicitly distinguishes itself from siblings: it is 'not about one change,' unlike repopilot_review_change.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit routing rules: use for a health check that is not about a single change; use repopilot_review_change for what a change touched or which checks it weakened; use repopilot_context for a short Markdown brief; use repopilot_explain_finding to explain a result. Both when-to-use and named alternatives with selection conditions are present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.24.2repopilot_context3 fields changedInput schema / properties / analysis_handle / descriptionPrevious value: -"Optional scan/review handle whose workspace revision must still match before context is generated."New value: +"Optional `analysisHandle` from an earlier repopilot_scan or repopilot_review_change call. The call fails if the workspace changed since that analysis."Input schema / properties / config / descriptionPrevious value: -"Optional repopilot.toml path."New value: +"Optional repopilot.toml path. Defaults to the one discovered in the repository."Input schema / properties / profile / descriptionAdded value: +"\"default\" hides low-signal suggestions; \"strict\" includes all findings."repopilot_explain_file2 fields changedInput schema / properties / rule / descriptionPrevious value: -"Optional rule id to focus the explanation on."New value: +"Optional rule ID (see the repopilot://rules resource) to focus the explanation on."Input schema / properties / signal / descriptionPrevious value: -"Optional signal id to focus the explanation on."New value: +"Optional detector signal within `rule` to focus on, e.g. \"rust.todo\" for language.rust.panic-risk."repopilot_explain_finding2 fields changedInput schema / properties / analysis_handle / descriptionPrevious value: -"Optional scan/review handle to select a stored analysis instead of the latest result."New value: +"Optional `analysisHandle` from an earlier scan or review in this session, to use that report instead of the latest one."Input schema / properties / source / descriptionPrevious value: -"Session report containing the finding."New value: +"Which report holds the finding: the latest repopilot_scan (\"last-scan\") or the latest repopilot_review_change (\"last-review\")."repopilot_explain_review_signal2 fields changedInput schema / properties / analysis_handle / descriptionAdded value: +"Optional `analysisHandle` from an earlier repopilot_review_change call. Omit to use the latest review in this session."Input schema / properties / signal_id / descriptionAdded value: +"The `signal_id` of an entry in the review report's `tiered_signals`."repopilot_review_change10 fields changedInput schema / properties / baseline / descriptionPrevious value: -"Optional baseline path."New value: +"Optional baseline file (from `repopilot baseline create`). Findings recorded in it count as accepted debt, separate from new findings."Input schema / properties / config / descriptionPrevious value: -"Optional repopilot.toml path."New value: +"Optional repopilot.toml path. Defaults to the one discovered in the repository."Input schema / properties / detail / descriptionAdded value: +"\"compact\" returns at most 20 findings and 20 signals; \"full\" returns all of them."Input schema / properties / fail_on_review / descriptionAdded value: +"\"definitely\" fails the report's gate when a gate-eligible definitely-tier signal is present; \"none\" reports signals without gating."Input schema / properties / filters / descriptionAdded value: +"Optional thresholds and rule IDs that narrow the returned findings."Input schema / properties / intent / descriptionPrevious value: -"Optional bounded intent data. It is metadata only and cannot execute commands."New value: +"Optional inline statement of what the change is meant to touch (paths, contract families, critical paths, verification IDs). The report marks drift outside it. It is metadata only and cannot execute commands."Input schema / properties / intent_path / descriptionPrevious value: -"Optional repository-rooted bounded TOML intent file."New value: +"Optional repository-rooted TOML file that states what the change is meant to touch. The report marks drift outside it. Use either this or `intent`, not both."Input schema / properties / profile / descriptionAdded value: +"\"default\" hides low-signal suggestions; \"strict\" shows all findings."Input schema / properties / scope / descriptionAdded value: +"\"changed\" reports findings in the changed files only; \"full\" also returns findings from the rest of the repository."Input schema / properties / verify / descriptionPrevious value: -"Configured local verification check IDs to run explicitly."New value: +"IDs of checks configured in repopilot.toml to run on the reviewed revision. They run as local processes. Omit to run nothing."repopilot_scan5 fields changedInput schema / properties / base / descriptionPrevious value: -"Optional base ref for changed scope."New value: +"Base Git ref for \"changed\" scope, e.g. \"origin/main\": scans files changed between base and HEAD. Without it, \"changed\" means changed against HEAD, including untracked files."Input schema / properties / config / descriptionPrevious value: -"Optional repopilot.toml path."New value: +"Optional repopilot.toml path. Defaults to the one discovered in the repository."Input schema / properties / filters / descriptionAdded value: +"Optional thresholds and rule IDs that narrow the returned findings."Input schema / properties / profile / descriptionAdded value: +"\"default\" hides low-signal suggestions; \"strict\" shows all findings."Input schema / properties / scope / descriptionAdded value: +"\"full\" scans every file under `path`; \"changed\" scans only changed files (against HEAD, or against `base` when given) and skips repository-level rules."v0.24.1repopilot_contextrepopilot_explain_filerepopilot_explain_findingrepopilot_explain_review_signalrepopilot_review_changerepopilot_scanScored across 6 tools
Each tool has a clearly distinct purpose, and descriptions explicitly cross-reference alternatives (e.g. 'For a repository health check that is not about one change, use repopilot_scan instead'). The three explain tools are cleanly separated by input type: file, finding_id, and signal_id.
All tools share the repopilot_ prefix and mostly follow a verb_noun pattern (review_change, explain_file, explain_finding, explain_review_signal). Minor deviations: 'scan' and 'context' are single tokens without an explicit object, though still readable.
Six tools is well-scoped for a focused code-review/audit server, with three core operations (review_change, scan, context) plus three targeted explainers. Every tool earns its place.
The surface covers the full lifecycle of the domain: producing a review, a scan, a brief, and explaining findings, signals, and file treatment. Minor gap: no explicit tool to list or manage prior session handles beyond passing analysis_handle, but core workflows are covered.
Risk-scan a diff, flag AI-generated-code tells, find secrets. 5 of 7 tools need no account.
Security reviews for coding agents: diffs checked against your org policy and live infrastructure.
Agentic code review, no signup to try: reality gates + frontier-model review, with veto.
Code review that knows what depends on your change — before commit or on every PR.
