Inventory the cryptography inside one local directory tree, file by file.

Reads source, configuration (nginx.conf, sshd_config, .ini, .toml), CI pipelines, Terraform and Kubernetes manifests under path. Returns each algorithm found with its file and line, the mathematical family and standing of every post-quantum scheme, and a coverage count.

Use this to answer what a specific project on this machine actually uses. Do not use it to ask whether this server knows a given algorithm, or to explain how one is classified without scanning anything -- list_algorithms answers that from the same table and reads no files. It is also the wrong tool for a network endpoint, a running host or a certificate store: it opens files on disk and nothing else.

Coverage is reported as a fraction with a base. files_scanned + unreadable_files + files_skipped_by_type == files_present. A file that could not be opened is listed, never counted as scanned, because no findings in a file nobody read is not the same as a file that is clean. Files skipped because this tool does not claim their type are counted by extension, so the reader can judge the boundary rather than assume past it.

Cost scales with the size of the tree, so a large monorepo takes proportionally longer; there is no cache and no partial mode.

Quoted lines are masked by default. Reading happens on this machine, but this result does not stay on it: it is returned to a model, which is a place the scanned line has not been before. A secret sharing a line with a finding -- a token in the call that names the cipher -- would travel with it. Masking keeps what a reader needs (the algorithm, the file, the line number, the shape of the call) and removes what nobody asked for. Pass level="full" when the line itself is the thing being examined.

List every algorithm family this server can recognise, and how each is classified.

Returns the whole table: family name, classification (classical and quantum-vulnerable, post-quantum, symmetric, hash, or deprecated) and the kind of use it stands for. Reads no files and takes no arguments.

Use this to check coverage before trusting a scan -- whether a scheme the project depends on is one this server knows at all -- or to explain a classification without scanning. To find what a particular directory uses, use scan_repo instead; this tool never looks at a codebase.

An algorithm absent from this table is reported as unknown by a scan, which is not the same as absent from the code.

Scan one directory and return a CycloneDX 1.6 CBOM that carries its own coverage.

Same reading as scan_repo; a different document. Use this when the result has to leave the machine -- an auditor, a customer, a pipeline artefact -- and scan_repo when a person or an agent is going to read it here.

What the document carries beyond the components: compositions.aggregate states how complete the list is in the schema's own vocabulary, complete only when every file present was examined; properties carries the whole coverage block flattened, including every file not examined with its reason; and each asset carries evidence.occurrences with file, line and matched text.

The coverage block travels as properties because the CycloneDX root object is additionalProperties: false and the format has no field for it. That is the point of emitting it this way rather than a limitation to work around.

The serial number is derived from the target, the two pins and a digest of the findings, so two runs of the same code over the same corpus that find the same things share it and a different result does not. The timestamp and coverage window record when each run happened.

The matched text in evidence.occurrences is masked by default, for the reason given on scan_repo and one more: this document is the one built to be sent. An auditor needs the algorithm, the file and the line; the contents of the line are not part of the claim being made.

Say whether two scans produced numbers that can be compared at all.

Two coverage percentages can differ because the estate moved, because the instrument moved, or because the corpus was collected differently, and the percentages show none of the three. This reads the pins and conditions in both blocks and answers with one of three verdicts.

comparable means nothing that moves the number differs. not_comparable lists which conditions differ, each with what it means, so the reader knows whether to re-run, re-clone or ignore it. unestablished means the blocks do not carry enough to decide -- an unpinned corpus, or an emitter that names no commit -- which is a different situation from a known difference and has a different repair.

Use it before putting two coverage figures in one table. Do not use it to compare findings; it reads conditions, not results.

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.