qrp-mcp

Every signature in your wallet, contract and validator rests on elliptic-curve cryptography. A large quantum computer breaks it. This tells your AI agent exactly where yours is.

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.

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.

Tools

What it looks at

Chain and wallet code — secp256k1, ecrecover, ethers, web3, bitcoinjs, ECPair, btcec, tweetnacl, @solana/web3.js, solana_program, bls12-381, blst, @chainsafe/bls, BIP340/Taproot Schnorr. Solidity (.sol), Rust (.rs), Move and Cairo are scanned alongside Python, Go, Java, JS/TS, Ruby, PHP, C/C++/C# and shell.

Classical crypto anywhere else — RSA, DSA, DH, ECDSA and elliptic-curve usage, plus MD5, SHA-1, RC4 and DES/3DES.

Hybrids and composites — the RFC 10024 TLS groups X25519MLKEM768, SecP256r1MLKEM768 and SecP384r1MLKEM1024, OpenSSH 10's default mlkem768x25519-sha256, and the composite certificate algorithms of draft-ietf-lamps-pq-composite-sigs such as id-MLDSA44-RSA2048-PSS-SHA256. A hybrid holds if either half holds, so the post-quantum scheme leads — and the classical half is carried in also_present rather than dropped, since it is the component Shor breaks.

Post-quantum schemes, by family — ML-KEM, ML-DSA, SLH-DSA, Falcon (FN-DSA), NTRU, Classic McEliece, BIKE, HQC, FrodoKEM, XMSS, and the stateful LMS/HSS of SP 800-208 that CNSA 2.0 requires for firmware signing. The nine schemes NIST advanced to its third additional-signatures round in May 2026 — FAEST, HAWK, MAYO, MQOM, QR-UOV, SDitH, SNOVA, SQIsign, UOV — are recognised as candidates, and CROSS as dropped from that process.

Each carries the mathematical family it rests on (structured or unstructured lattice, code-based, hash-based, isogeny-based, multivariate, symmetric-based) and where it stands: standardised, selected, candidate, withdrawn, eliminated or broken. SIKE is reported as broken and HAWK as withdrawn rather than counted as quantum-resistant — "post-quantum" is a category, not an assessment.

Configuration — nginx.conf, sshd_config, openssl.cnf, .ini, .toml, .properties, and any YAML that is not a manifest. This is where a TLS or SSH hybrid group is chosen: X25519MLKEM768 and mlkem768x25519-sha256 are almost never strings in code.

CI/CD pipelines — signing commands such as gpg --sign, cosign sign, signtool, jarsigner, codesign.

Infrastructure as code — Terraform and Kubernetes key algorithms, and private key material committed by mistake.

Real run against OpenZeppelin's contracts (711 files, about five seconds):

{
  "detected_algorithms": ["ECDSA", "RSA"],
  "summary": {
    "quantum_vulnerable_count": 2,
    "pqc_ready_count": 0,
    "highest_severity": "high",
    "pqc_readiness": "classical_only"
  }
}

Why deterministic

There is no LLM inside this tool. The same input always produces the same output, and every finding points at a file and a line you can open yourself.

That is the point of handing it to an agent: the agent brings the language, the tool brings the truth. An agent guessing about your signing code is worse than nothing; an agent reading a deterministic inventory can actually reason about it.

What it is not

It reads source, configuration, CI pipelines, infrastructure-as-code and Kubernetes manifests. It does not read documentation, binaries or images.

Every file under the path is accounted for in one of three ways: scanned, unreadable, or skipped because the tool does not claim that type — the last counted by extension, so the coverage figure has a base. files_scanned + unreadable_files + files_skipped_by_type always equals files_present. A scan that read seven files out of nine is a different report from one that read seven out of four hundred, and only one of them is worth trusting.

A free inventory tool, not a readiness assessment. It deliberately does not do:

• risk scoring or prioritisation,
• migration planning,
• network, host or certificate scanning,
• tracking change over time.

Those live in the Quantum Readiness Platform, the product this tool is extracted from. Nothing here is crippled to push you there — what it does, it does completely.

It also does not tell you that you are about to be hacked. It tells you what you are using.

License

Apache-2.0.