qrp-mcp

Overview Schema Source Related Servers Discussions Admin

prove_closure

Read-onlyIdempotent

Compare two saved scans of the same tree to verify which findings a fix actually closed, rejecting incomparable runs and classifying moved, removed, or new issues.

Instructions

Say which findings a change actually closed, by comparing two saved scans of one tree.

First it decides whether the two runs can be compared for closure at all: the same instrument commit, version, rules, file types and exclusions, both trees pinned to a commit and clean, both results quoting lines at the same level. The trees themselves may differ -- that difference is what is measured. If the runs cannot be compared, nothing is reported as closed and the repair is named.

Only then does it match every occurrence without its line number: closed (present before, absent from every file the second run read), still open (and how many only moved lines), relocated to another path (renamed or moved, not fixed), removed (the whole file is gone from the second tree -- not counted as closed), moved into or out of test code, new, and unverifiable (in a file the second run did not read). A file the second run could not open is never counted as fixed.

To keep the verdict as a file that names the two scans it judged, run qrp-mcp closure BEFORE AFTER --out FILE.

Use it after a fix, to evidence the fix. Do not use it to compare coverage figures between two estates -- compare_coverage answers that. It reads two local files and nothing else.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`after`	Yes	Path to the JSON result of the scan made AFTER the change, same tree, same instrument, same level.
`before`	Yes	Path to the JSON result of the scan made BEFORE the change (`qrp-mcp scan PATH --out FILE`).

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.27.0Sep 30, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations declare the safety profile (readOnly, idempotent, non-destructive), and the description adds genuinely new behavioral context: the comparability preconditions, the full closure taxonomy, and edge rules such as 'a file the second run could not open is never counted as fixed.' It even notes it reads only two local files.

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

Conciseness4/5

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

Front-loaded with the core purpose, then preconditions, then the taxonomy. It is fairly long, and the inline CLI aside is somewhat tangential, but every sentence contributes; no filler or repetition.

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

Completeness5/5

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

An output schema exists, so return-value explanation is not required. The description supplies the preconditions, the classification vocabulary, and the guarantee that the verdict names the scans judged, which is everything an agent needs to invoke it correctly.

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 100%, so before/after are already documented. The description adds meaning beyond the schema by specifying the two files must share instrument commit, version, rules, file types and level, and that the trees themselves may differ, clarifying what the paths must satisfy to be comparable.

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?

The opening sentence gives a specific verb and resource ('say which findings a change actually closed') and scopes it ('by comparing two saved scans of one tree'). It explicitly distinguishes itself from the sibling that could be confused with it, compare_coverage.

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?

It states when to use it ('after a fix, to evidence the fix') and when not to ('Do not use it to compare coverage figures between two estates'), naming compare_coverage as the alternative. This is exactly the explicit when/when-not/alternative structure.

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

Deploy Server