Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@pqblocks-mcp check my config for RSA/ECDSA and give me post-quantum migration steps"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server that tells AI coding agents which PQBlocks package to use, with install lines and quickstarts verified to run. Use it in Claude Code, Claude Desktop, Cursor, VS Code or any Model Context Protocol client when you add or migrate post-quantum cryptography, audit code for RSA and ECC, or pick a quantum-inspired solver. Implements the Model Context Protocol over stdio (protocol versions 2024-11-05, 2025-03-26 and 2025-06-18).
claude mcp add pqblocks -- uvx --from git+https://github.com/PQBlocks/pqblocks-mcp pqblocks-mcp
Ask an assistant to "add post-quantum encryption" and it will often invent a function name. This server answers from a catalog generated from the PQBlocks packages themselves, in which every quickstart was executed against its package before it was written. The agent gets a real package, the install line that works today and code that runs.
flowchart LR
A[Agent: "sign JWTs with ML-DSA"] -->|recommend_package| S[pqblocks-mcp]
S --> C[(catalog.json<br/>every package<br/>quickstarts executed)]
S -->|package · install · import · quickstart · docs| A
A -->|get_snippet / check_config| SRelated MCP server: CodeMore MCP Server
Client | Configuration |
Claude Code |
|
Claude Desktop |
|
Cursor |
|
VS Code |
|
Any client, with pip |
|
The server has no runtime dependencies: it speaks MCP over stdio with its own small JSON-RPC implementation. Install the sdk extra (pqblocks-mcp[sdk]) to use the official MCP Python SDK transport instead.
Tool | Input | Returns |
|
| Best package, why, install, import, executed quickstart, docs, alternatives |
|
| Install, import, executed quickstart, example scripts, evidence documents, warnings |
|
| Line-numbered findings: RSA, ECDSA, ECDH / NIST curves, DH, DSA, lone X25519 / Ed25519, MD5, SHA-1, 3DES, AES-128, with replacements and packages |
|
| All packages with area, version, status, install line |
The tools are plain functions too:
from pqblocks_mcp.server import check_config, recommend_package
print(recommend_package("find RSA usage in my repo")["recommended_package"]) # pqblocks-scan
for f in check_config('key = rsa.generate_private_key(key_size=2048)')["findings"]:
print(f["line"], f["algorithm"], "->", f["replace_with"])Function | Signature |
|
|
|
|
|
|
|
|
| Console entry point |
The server reads only its bundled catalog. It makes no network calls and executes no code it receives.
check_config is a pattern match on algorithm names. It cannot see algorithms chosen at runtime or hidden behind library defaults, and it says so in every response. Use pqblocks-scan for a whole repository.
Recommendations point to pre-1.0 packages that are not FIPS 140-3 / CMVP validated or externally audited; each package's SECURITY_NOTES.md has the details.
tests/test_server.py checks that every catalog entry is verified and parses, that 22 realistic tasks route to the right package, that a package is never recommended for something its README says it does not do, that the config checker has no false positives on hybrid names, and the full stdio protocol (initialize, notifications, tools/list, tools/call, errors, ping).
The catalog is built in the pqblocks.github.io repository, which runs every quickstart, and synced here every six hours by .github/workflows/sync-catalog.yml after the tests pass. New packages appear without a code change.
pip install -e ".[test]" && pytest -qPQBlocks builds verified building blocks for the post-quantum era. See also pqblocks-skills (Claude skill, Cursor rule, AGENTS.md) and the package catalog. Licensed under Apache-2.0.
Scan pasted code or config for quantum-vulnerable public-key algorithms (RSA, ECDSA, ECDH, DH, DSA, lone X25519/Ed25519) and classically weak ones (MD5, SHA-1, 3DES, AES-128); returns line-numbered findings, replacements and matching packages.
| Name | Required | Description | Default |
|---|---|---|---|
| code_or_config | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does a creditable job: it discloses detection scope down to the nuance that only *lone* X25519/Ed25519 uses are flagged (i.e. hybrid use is not), and it describes the return shape (line-numbered findings, replacements, matching packages). It does not state input size limits, whether it is strictly read-only, or rate/throughput behavior, leaving modest gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, front-loaded with the verb and resource, with the algorithm enumeration doing real work by defining detection scope. The two parenthetical lists make it dense and slightly hard to skim, but nothing is redundant and nothing could be cut without losing meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter, annotation-free analysis tool with no output schema, the description covers purpose, detection scope, and return contents — close to what an agent needs. Remaining gaps are operational (input size limits, how to act on the 'matching packages' output) rather than fundamental.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for the single required parameter, so the description must compensate. 'Pasted code or config' does convey the important semantics that the parameter is raw content, not a path or identifier — a genuinely useful clarification. It says nothing about accepted formats, size limits, or multi-file handling, so compensation is partial rather than complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (scan) plus the exact resource (pasted code or config) and enumerates what counts as a finding: quantum-vulnerable public-key algorithms (RSA, ECDSA, ECDH, DH, DSA, lone X25519/Ed25519) and classically weak ones (MD5, SHA-1, 3DES, AES-128). None of the siblings (recommend_package, get_snippet, list_packages) scan input, so an agent can route to this tool unambiguously.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The word 'pasted' hints that this takes inline text rather than a file path or repo reference, which is a real usage constraint, and the detection list implies when it applies. But there is no explicit when-to-use/when-not framing and no mention of the natural follow-up siblings (recommend_package for fixes, list_packages for the matching packages it returns). Usage is inferable rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Install line, import name and the README quickstart for one PQBlocks package. Every quickstart was executed against the package source when the catalog was built; use it as-is rather than guessing an API.
| Name | Required | Description | Default |
|---|---|---|---|
| package | Yes | ||
| framework | No | python |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full disclosure burden, and it does add a genuinely useful trait: every quickstart was executed against the package source at catalog build time, so the output is verified and should be trusted verbatim. However, it says nothing about behavior for an unknown package name, whether the call is read-only, or what the response looks like beyond the three listed items.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences: the payload is front-loaded, and the second sentence is a trust/provenance note that directly prevents a common failure mode (the agent inventing an API). Nothing is redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description does well to enumerate the returned items (install line, import name, quickstart). But it leaves the framework parameter and the missing-package behavior entirely unaddressed, which is a material gap for a two-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for two parameters. The description clarifies 'package' as exactly one PQBlocks package, but the 'framework' parameter (default python) is never mentioned anywhere, so the agent has no idea it can request a non-Python quickstart. Only half the parameters are compensated for.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
It concretely defines what a 'snippet' is for this tool: install line, import name, and README quickstart for one named package. That is a specific resource with an enumerated payload, far better than restating the name. It never distinguishes itself from recommend_package or list_packages, so sibling disambiguation is absent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Use it as-is rather than guessing an API' implies the use case (getting started with a known package) but states no explicit when-to-use/when-not or routing to the alternatives. An agent must infer that list_packages is for discovery and this tool is for a package already chosen.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List every PQBlocks package with area, status, version and the install line that works today. Optional category filter: 'PQ cryptography', 'Migration & readiness', 'Interoperability', 'Conformance', 'Quantum-inspired'.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. 'List' strongly implies a read-only operation, and the description usefully discloses the returned fields and filter behavior, but it omits any statement about authentication, pagination, ordering, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tightly written sentences with the main purpose front-loaded and the optional filter detail following. Every clause contributes useful information, and there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter list tool with no output schema and no annotations, the description supplies the key missing context: what is returned and what category values are valid. It is nearly complete, with only secondary details like ordering or pagination absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must supply parameter meaning itself. It does so by identifying the single optional parameter as a category filter and enumerating five accepted values, adding substantial value beyond the bare schema. It does not clarify matching rules or case sensitivity, which keeps it short of a 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (list) and resource (PQBlocks packages), and names the fields returned (area, status, version, install line), which makes the operation concrete. It doesn't explicitly contrast itself with the sibling recommend_package, but the inventory-browsing scope is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is the tool for browsing all packages and mentions the optional category filter, but it never says when to use this versus recommend_package or check_config. No exclusions or alternative-selection guidance are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pick the PQBlocks package for a task described in plain words (e.g. 'sign JWTs with ML-DSA', 'find RSA in my repo', 'solve a QUBO'). Returns the package, why, its install line, a quickstart verified to run, docs links and alternatives.
| Name | Required | Description | Default |
|---|---|---|---|
| task_description | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it enumerates the response contents (package, reasoning, install line, verified quickstart, docs links, alternatives), which tells the agent exactly what it will get back and that the quickstart is verified to run. It stops short of noting confidence limits or what happens for unrecognized tasks.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the action and input format in the first clause, then lists outputs compactly. Dense but every element (examples, return fields) adds usable information; slightly long single sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description appropriately covers return values in detail, and the single simple parameter needs little explanation. Missing only guidance on how the agent should phrase ambiguous or multi-part tasks.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the single parameter is self-descriptive and the description compensates by giving three concrete example task strings, which conveys the expected granularity and phrasing better than the bare schema does.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Uses a specific verb ('Pick') plus a concrete resource ('the PQBlocks package') and immediately distinguishes itself from siblings like list_packages and get_snippet by framing input as a plain-language task. The parenthetical examples ('sign JWTs with ML-DSA', 'solve a QUBO') make the scope unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
States the triggering condition clearly: use this when the task is expressed in plain words rather than a known package name. It does not explicitly name siblings like list_packages as the alternative for browsing, so the routing logic is implied rather than spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0check_configget_snippetlist_packagesrecommend_packageScored across 4 tools
Each tool has a distinct role: list_packages browses the catalog, recommend_package maps a task to a package, get_snippet returns details for a known package, and check_config scans user code. The only real overlap is that recommend_package also returns install lines and quickstarts, so an agent might sometimes skip get_snippet, but the descriptions make the task-driven vs package-specific split clear.
All four tools follow a clean verb_noun snake_case pattern (recommend_package, get_snippet, check_config, list_packages). No mixed conventions or vague verbs.
Four tools is slightly lean but each maps to a distinct step in the workflow: discover, choose, inspect, and audit. Nothing feels redundant or missing for a package catalog server.
The surface covers the key lifecycle: listing packages, recommending one for a task, retrieving its quickstart, and auditing existing code for vulnerable algorithms. Gaps are minor, e.g. no dedicated search-by-keyword or version/detail lookup beyond what list_packages and get_snippet provide.
Scan code for quantum-vulnerable cryptography and get NIST post-quantum migration guidance.
QuantumOracle — 18 post-quantum crypto tools: Kyber, Dilithium, hybrid schemes, migration.
Governance copilot for AI-assisted coding. 72 packs, 532 rules, proof bundles.
PQC scanner for GitHub repos and smart contracts. Detects quantum-vulnerable ECDSA/RSA.
