RepoPilot

Prioritize review for a PR or diff

check_change_risk

Read-only

CALL before merging a pull request or after producing a local diff. Returns a deterministic 0-10 change-shape score with receipts for size, spread, missing tests, sensitive paths, hotspots, and blast radius. Pass repo+pr OR diff; repo may accompany diff for cached hotspot context. This prioritizes review and never approves a merge.

Input Schema

TableJSON Schema

Name	Required	Description
`pr`	No	Positive pull request number, used with repo.
`diff`	No	Raw unified git diff to score directly.
`repo`	No	owner/repo or a github.com URL.
`files`	No	Privacy-preserving changed-file facts; contains no source or diff hunks.
`proofs`	No
`base_sha`	No
`head_sha`	No
`contract_id`	No	Optional short-lived contract_id returned by plan_repo_task.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`tool`	Yes
`agent`	Yes
`status`	Yes
`schema_version`	Yes

TDQS

A4.6/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context: output is deterministic, it never approves a merge (limit on its authority), and it notes repo caching for hotspot context. It does not detail receipts format, but with readOnlyHint covering the safety dimension, 4 is generous but warranted.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, front-loaded with when to call, the core value (deterministic score with receipts), input modes, and a critical behavioral caveat. Every clause carries information; zero filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Output schema exists so return format needn't be detailed. The description covers invocation timing, input-mode disjunction, scoring dimensions, determinism, and non-approval semantics. It doesn't detail the receipt structure or caching behavior, but given the good annotations and output schema, this is adequately complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 63%, and the description fills key gaps: it explains the input-mode semantics (repo+PR OR diff), states repo may accompany diff for cached hotspot context, and notes files array is 'privacy-preserving... contains no source' — clarifying that line counts may be placeholders. This adds meaning beyond the oneOf constraints.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states it computes a 'deterministic 0-10 change-shape score' with receipts for specific factors (size, spread, missing tests, sensitive paths, hotspots, blast radius). The verb 'check' plus resources (PR/diff) and the distinct scoring behavior distinguish it from siblings like check_dependency or analyze_repo.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says 'CALL before merging a pull request or after producing a local diff', giving concrete timing. It lists valid input combinations ('repo+pr OR diff; repo may accompany diff') and clarifies it 'prioritizes review and never approves a merge', which sets expectations for when it's appropriate vs not.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All RepoPilot tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.3/5.0

Disambiguation3/5

The set separates into repo-orientation, dependency-checking, and change-risk workflows, but there is real overlap: analyze_repo/get_artifact/plan_repo_task all provide orientation and reading order, and check_dependency vs. evaluate_dependency_change both fire before adding/upgrading a dependency. The descriptions help clarify intent, yet an agent could still struggle to pick the right one in unfamiliar scenarios.

Naming Consistency5/5

Every tool follows a consistent verb_noun snake_case pattern: analyze_repo, check_dependency, compare_repos, evaluate_dependency_change, get_artifact, plan_repo_task, verify_dependency_change. The verbs are descriptive and the pattern makes the lifecycle stages predictable and easy to navigate.

Tool Count5/5

Eight tools is well within the ideal range for a server focused on repository and dependency due diligence. Each tool addresses a distinct phase of the workflow—orientation, planning, risk scoring, comparison, evaluation, and verification—without bloating the surface.

Completeness4/5

The server covers the core lifecycle well: understanding a repo, planning work, assessing change risk, evaluating dependencies, comparing options, and verifying updates. Minor gaps exist, such as no tool for auditing an entire dependency tree or comparing more than two candidates, but these are workable limitations rather than fatal omissions.

Resources

Need Help?