Quantum Readiness Scan

qrp-mcp

A local cryptographic inventory for developers and AI agents that carries verifiable coverage and its own limits inside the CBOM.

Every signature in your wallet, contract and validator rests on elliptic-curve cryptography, and a large quantum computer breaks it. Plenty of tools will tell you what they found. This one also tells you what it read, what it could not read, and which question it is not answering — in the document itself, where an auditor can check it rather than take your word.

An MCP server that scans a local directory for cryptography that Shor's algorithm defeats — secp256k1, Ed25519, BLS, Schnorr, RSA — plus weak primitives and CI signing commands, and classifies each one: broken by a quantum computer, post-quantum, or neither.

Everything runs on your machine. No network calls, no account, no API key, nothing uploaded. A tool that reads your keys' surroundings has no business phoning home, so this one makes zero outbound connections — enforced by a test, not promised in a paragraph. The only process it starts is a local git, to pin what it read, with the scanned repository's own hooks and filters disarmed.

flowchart TD

R["Your repository, on your machine, at a commit"] --> Q["qrp-mcp — offline, zero network calls"] Q --> F["Found file:line and family"] Q --> N["Not read each file with its reason"] F --> J["scan --out result.json"] N --> J J --> O["CBOM (CycloneDX 1.6) SARIF closure: what a change closed"]

Need a cryptographic inventory (a CBOM) for a post-quantum migration or an audit, without uploading your code? One command, no install step:

uvx qrp-mcp scan ~/code/my-project --out result.json

What comes back, run on this repository's own test fixtures -- the findings, and next to them what the scan did not read:

"verdict": "This scan read 24 of 27 files (88.89%); the remaining 3 (1 of 1, by extension

— .b64 — being 100.0% of them) are listed with a reason each." "summary": { "total_findings": 10, "quantum_vulnerable_count": 6, "pqc_ready_count": 1, "weak_count": 1, "pqc_readiness": "hybrid_partial", ... }

Why this matters for chains and wallets

Bitcoin and Ethereum authenticate with ECDSA over secp256k1. Solana, Cardano and Polkadot use Ed25519. Ethereum's consensus layer aggregates with BLS12-381. Taproot adds Schnorr.

All four are public-key schemes whose security rests on discrete-log hardness — and all four fall to the same quantum algorithm. The practical consequence is specific: once a public key is exposed, the private key becomes derivable. Reused addresses, on-chain public keys, and long-lived validator keys are where that exposure already exists today.

None of this is a prediction about dates. It is an inventory question: *which of my code paths sign with what?* That question has an answer right now, and this tool gives it.

Quick start

Add it to your MCP client — no installation step, uvx fetches and runs it:

{

"mcpServers": { "qrp": { "command": "uvx", "args": ["qrp-mcp"] } } }

Then ask your agent:

Scan ~/code/my-protocol for quantum-vulnerable cryptography.

As a Claude Code plugin

The same server, packaged with a skill, so there is no config file to edit:

/plugin marketplace add StanimirTenev/qrp-mcp

/plugin install qrp@quantumreadiness

Then /qrp:pqc-scan in any project. Both routes need uv on your PATH, since uvx is what fetches and runs the server.

Without an agent: write the result to a file

uvx qrp-mcp scan ~/code/my-protocol --out result.json

This produces the same result as the scan_repo tool, written to a file you can read before it goes anywhere. Nothing is sent. By default (from 0.40.0, as cbom since 0.16.0 and the tools) the quoted line is masked: everything in it but the algorithm name is starred out. --level full writes the line as it is, and --level trimmed removes the line altogether; all three keep each file and line number. The SHA-256 of the written bytes is printed, so anyone you send the file to can quote back exactly what they received.

That digest is the file's integrity, and the file holds its read times, so two runs over one commit print different ones. Beside it, findings sha256 is the fingerprint of the findings alone (findings_fingerprint in the JSON, in SARIF's run properties and in the CBOM as qrp:findings_fingerprint:sha256): the same on every run and at every --level that finds the same, different when a finding is added or removed. Its normalisation rules are written into the output beside it: each finding as family, raw value, classification and severity; each occurrence as category, path, line, family, role and key size; excerpts, confidence, owners, baseline state, mandate clauses, suppressed rows, coverage and the read window left out; both lists sorted, serialised as compact JSON with sorted keys, SHA-256 in hex. It says the result repeats; it says nothing about whether the result is complete.

uvx qrp-mcp cbom ~/code/my-protocol --out cbom.json

uvx qrp-mcp closure before.json after.json --out closure.json

cbom writes the same CycloneDX document as the export_cbom tool, masked by default because it is the document built to be sent. closure writes the prove_closure verdict for two saved scans, and names both inputs by their SHA-256, so the three files can be tied together by whoever receives them. Both print the SHA-256 of what they wrote.

A control on your own tree

uvx qrp-mcp control ~/code/my-protocol --seed 1 --out control.json

From 0.43.0. The tree is copied to a temporary directory, known cryptographic uses (9 styles) and lines that name an algorithm without using it (7 kinds) are planted into the copy, and the copy is scanned with the same instrument. The result says which planted lines were found, which were missed and which non-uses were reported as uses — robustness on known patterns, for this version. It is not a statement about what your tree contains, and it never makes the coverage claim stronger. scan --control-seed N carries the block in the result. The control.

A source scan against the build

uvx qrp-mcp scan ~/code/my-service --out scan.json      # before building

uvx qrp-mcp build-gap scan.json ~/code/my-service/bin/publish --out gap.json

From 0.44.0. Of K public-key-bearing packages or modules in the build, the source scan named J; the K - J list; the families on one side only; and a Go binary's DefaultGODEBUG crypto settings as recorded. It reads only tables the toolchain wrote (*.deps.json, .NET metadata names, go version -m, go tool nm), never code, and never a key size from the build — robustness on known patterns, not recall or coverage of the build. Source against build.

What it reads

Every file under the path is either read or named with the reason it was not. The full list of rules, file types and their limits is in What it looks at.

Coverage on three public repositories

What coverage.scope says on three trees this project did not write, measured on 4 Nov 2026 with the code of this release (the repositories at OpenSSH 7fe3b24, certbot 56ee049, Vault 41e571b). coverage_pct is the share of the files present that were read; read_in_full_pct leaves out the files read only in part (a device configuration, a certificate block that did not parse).

These are reading figures, not detection figures. How well the rules find what is there is a different question; the measurements made of it, each with its date and version, are in How it is measured, and no recall or precision figure is cited here as current.

Documentation

• What it looks at — the rules, file types and formats, and their limits
• What the coverage block says — coverage_pct, read_in_part, read_in_full_pct, examined_partly, concentration
• The CBOM it emits — CycloneDX 1.6 fields, the kind of place a finding sits in, how sure the scan is of each occurrence
• What a TLS line does not establish — TLS places, classical groups and SSH key exchanges offered on their own
• Gate, mandates and suppression markers — --mandate, --min-coverage, .qrp.toml, qrp:ignore with until= and owner=
• Closure, replacements and profiles — whether a fix closed it, what to replace it with, national profiles, the role of an RSA or EC line
• The control — qrp-mcp control, what it plants, the self_seeded_control block and its fields
• Source against build — qrp-mcp build-gap, what it reads from a build, what it never reads, what K and J are
• [How it is measured](https://github.com/StanimirTenev/qrp-mcp/blob/main/doc