quantakrypto pqc-tools
Server Details
Scan code for quantum-vulnerable cryptography and get NIST post-quantum migration guidance.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- quantakrypto/pqc-tools
- GitHub Stars
- 6
- Server Listing
- quantakrypto pqc-tools
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 3.9/5 across 11 of 11 tools scored. Lowest: 3.2/5.
Tools are mostly distinct, but 'apply_triage' and 'triage_findings' are closely related sequential steps, and 'remediate_findings', 'verify_fix', and 'apply_verified_patch' could cause confusion if descriptions are not read carefully. Overall, clear differentiation with detailed descriptions.
All tool names follow a consistent verb_noun pattern using underscore separators (e.g., list_rules, verify_fix). No mix of casing or naming styles, making it predictable for an agent.
11 tools is well-scoped for a post-quantum security analysis server. Each tool serves a distinct function (detection, explanation, triage, remediation) without redundancy, fitting a complete workflow.
The tool surface covers detection, explanation, triage, and remediation comprehensively. However, there is no tool for initiating a scan; the tools assume findings are provided externally via scan_path, which is a minor but notable gap.
Available Tools
11 toolsapply_triageAInspect
Deterministically attach your triage verdicts to their findings and re-sort by exposure (highest first). Never suppresses. Pass the same 'findings' array you triaged plus a 'verdicts' array of { fingerprint, exposureScore, priority, rationale }.
| Name | Required | Description | Default |
|---|---|---|---|
| findings | Yes | The findings that were triaged. | |
| verdicts | Yes | One verdict per finding, keyed by fingerprint. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It states determinism and that it never suppresses, which is helpful. However, it omits details like idempotency, error handling, or whether the tool mutates inputs or returns new data. The lack of output schema also leaves return behavior unclear.
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?
The description is very concise—two sentences covering purpose and parameter usage. Every sentence earns its place with no wasted words or repetition of schema.
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?
Given the tool's complexity (two array inputs of nested objects) and absence of output schema, the description should explain what the tool returns or if it modifies inputs. It only implies a re-sorted result. Error scenarios and compatibility between inputs (e.g., verdicts matching findings) are not addressed.
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 100% with descriptions for all fields. The description reiterates the structure of the verdicts array but adds little new meaning beyond what the schema provides. Baseline 3 is appropriate.
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?
The description clearly states the tool's purpose: 'Deterministically attach your triage verdicts to their findings and re-sort by exposure (highest first).' It specifies the action (attach verdicts, re-sort), the resource (findings and verdicts), and the deterministic behavior, distinguishing it from siblings like 'triage_findings' which generates verdicts.
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 explicitly instructs to 'Pass the same 'findings' array you triaged plus a 'verdicts' array,' providing clear when-to-use guidance as a follow-up to triage. However, it does not mention when not to use or suggest alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
apply_verified_patchAInspect
Deterministically VERIFY a proposed fix before writing it — runs the same patch-policy + verify_fix + blast-radius gates as qremediate (offline, no key, no network). Give the finding, the file's current content, and your proposed FULL corrected content; returns approved:true only if the patch is in-policy, clears the finding, adds no new finding, introduces no network/exec sink, and is bounded in size. This does NOT write the file — you write it, only when approved, and never auto-merge.
| Name | Required | Description | Default |
|---|---|---|---|
| finding | Yes | The scan finding being fixed (needs a string ruleId and location.file). | |
| newContent | Yes | Your proposed full corrected file content. | |
| originalContent | Yes | The file's current full content. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Describes deterministic, offline behavior with no network usage, and lists all checks (in-policy, clears finding, no new finding, bounded size). Explicitly states it does not perform writes.
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?
Four sentences, each substantive and front-loaded. Could be slightly more concise but avoids redundancy. Structure is logical: function, inputs, output, caveats.
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 tool with nested objects and no output schema, description explains what is returned (approved:true with conditions) and all non-trivial behaviors. Complete for effective invocation.
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 100% but description adds critical context: finding needs ruleId and location.file, newContent is proposed corrected content. This augments the schema descriptions meaningfully.
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?
Clear verb 'VERIFY' and resource 'proposed fix'. Distinguishes from siblings by explicitly contrasting with qremediate and stating it does not write. Scope and action are 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 when to use (before writing), what it does (runs policy + verify gates), and explicit exclusions ('does NOT write', 'never auto-merge'). Provides clear context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_dependencyAInspect
Check whether a package is in quantakrypto's known quantum-vulnerable dependency database (the classical crypto it exposes). Provide 'name' and optional 'ecosystem' (default npm).
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Package name to look up (e.g. 'node-forge', 'jsonwebtoken'). | |
| ecosystem | No | Package ecosystem. Default: npm. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses only that the tool performs a lookup in a known-vulnerability database, but does not mention side effects, latency, caching, or whether the check is read-only. More detail is needed.
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 concise sentences, front-loaded with the primary purpose. No redundant or irrelevant content. Every word earns its place.
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 straightforward lookup tool with no output schema, the description covers the essential behavior and inputs. However, it lacks mention of the output format (e.g., boolean or details), which would improve completeness.
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 100%, with both parameters well-described in the schema (name: package name; ecosystem: ecosystem with default). The description merely restates this information and adds an example for name, but no additional semantics beyond the schema.
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?
The description clearly states the verb 'Check whether a package is in quantakrypto's known quantum-vulnerable dependency database', specifying the resource (dependency database) and the aspect checked (classical crypto exposure). This distinguishes it from sibling tools like apply_triage or explain_finding.
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 instructs to provide 'name' and optional 'ecosystem', giving basic parameter guidance. However, it does not explicitly state when to use this tool versus alternatives like explain_finding or get_fix_examples, leaving context implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
explain_findingBInspect
Explain a quantakrypto finding and its post-quantum remediation. Provide a ruleId (e.g. 'forge-rsa-keygen', 'elliptic-ec', 'node-rsa', 'pem-ec-private-key') and/or an algorithm (e.g. 'RSA', 'ECDSA'). The ruleId is resolved against the core detector set, so library and config rules explain correctly.
| Name | Required | Description | Default |
|---|---|---|---|
| ruleId | No | The finding's rule id, matching a detector id prefix. | |
| algorithm | No | The classical algorithm family involved (e.g. RSA, ECDH, ECDSA). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It explains ruleId resolution against the core detector set and that library/config rules work, but does not confirm read-only status, error handling, or whether it modifies state. Some transparency, but incomplete.
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 sentences with no wasted words. First sentence states purpose; second adds parameter details and resolution behavior. Extremely concise and well-structured.
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?
Given the sibling set of 11 tools and lack of output schema or annotations, the description could be more complete. It does not mention output format, error cases, or when to prefer this tool over alternatives. Adequate but not thorough.
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 100%, so baseline is 3. The description adds value by providing concrete examples of ruleId and algorithm values, and explaining resolution behavior. This extra context raises it to 4.
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?
The description clearly states the tool explains a quantakrypto finding and its post-quantum remediation, with specific examples of ruleIds and algorithms. However, it does not explicitly contrast with sibling tools like apply_triage or get_fix_examples, slightly reducing clarity.
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?
No usage guidelines are provided. The description omits when to use this tool versus siblings (e.g., when to explain vs. apply a fix). It only mentions providing ruleId and/or algorithm, not context-dependent guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_fix_examplesAInspect
Return before/after code examples for migrating a classical algorithm to a post-quantum / hybrid replacement. Provide an 'algorithm' (RSA, ECDH, ECDSA, …) or a 'ruleId' from a finding.
| Name | Required | Description | Default |
|---|---|---|---|
| ruleId | No | A finding's ruleId (resolved to its algorithm). | |
| algorithm | No | Classical algorithm family to migrate away from. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must bear the full burden. It states the function is to return examples, implying read-only behavior, but does not explicitly confirm safety, idempotency, or any other behavioral traits.
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 sentences, front-loaded with key information. Every phrase adds value; no unnecessary words.
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?
The description covers the core purpose and input method. For a tool with no output schema and moderate complexity, it is sufficiently complete, though details about output format or result structure could be added.
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 100% and both parameters have descriptions. The description adds concrete examples of algorithm values (RSA, ECDH, ECDSA) and explains how ruleId is resolved, providing meaning beyond the schema.
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?
Describes specific verb 'return' and resource 'before/after code examples' for migrating classical algorithms. Clearly distinguishes its purpose from sibling tools like 'suggest_hybrid' or 'explain_finding'.
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?
Indicates how to specify input (algorithm or ruleId), but does not provide guidance on when to use this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_rulesAInspect
List the quantakrypto detector catalog: every detector id and what it looks for.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only mentions 'list', indicating a read operation, but does not disclose any potential limitations, authentication requirements, or output format details. More behavioral context would be beneficial.
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?
The description is a single, efficient sentence that front-loads the verb and noun. No wasted words.
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?
Given the tool's simplicity (no parameters, no output schema), the description is fairly complete, covering the purpose and content of the list. However, it could mention whether the result is paginated or if any filtering exists, which would enhance completeness.
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?
There are no parameters, and schema coverage is 100% trivially. The description adds value by explaining what the catalog contains (detector ID and what it looks for), which is above the baseline of 4 for zero-parameter tools.
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?
The description clearly states the verb 'List' and the resource 'quantakrypto detector catalog', specifying that it returns every detector ID and what it looks for. This distinguishes it from sibling tools which involve actions like triage or patching.
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 usage for retrieving the detector catalog but does not explicitly state when to use or when not to use this tool versus alternatives. It lacks guidance on exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
remediate_findingsBInspect
Produce a deterministic remediation REQUEST bundle (rubric + fix schema + per-finding metadata + fingerprints) for YOU (the host agent) to fix. This tool calls no model and needs no key. For each finding, propose the corrected FULL file content, then VERIFY with verify_fix and keep only fixes that clear the finding. Never touch files with secrets; never auto-merge. Pass 'findings' from scan_path --format json.
| Name | Required | Description | Default |
|---|---|---|---|
| findings | Yes | Findings from a scan's JSON output. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description notes the tool is deterministic and model-independent, and includes critical constraints (no secrets, no auto-merge). However, it lacks detail on side effects, such as whether the bundle is returned or stored, and how the host agent applies it.
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?
The description is verbose and mixes purpose with step-by-step instructions. While informative, it could be more concise by separating the primary function from procedural guidance.
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?
The description mentions a 'rubric + fix schema + per-finding metadata + fingerprints' but does not explain their structure or how they are used downstream. Without an output schema, more detail is needed to fully understand the tool's output and integration with siblings like apply_verified_patch.
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?
The schema already provides descriptions for most nested fields (100% coverage). The description adds context by specifying the source format ('scan_path --format json') and outlining the required structure, thus enhancing understanding beyond the schema.
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?
The description clearly states the tool produces a remediation request bundle and identifies the host agent as the actor. It specifies the tool calls no model and needs no key, distinguishing it from AI-dependent tools. However, the purpose is somewhat obscured by embedded instructions.
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 directs passing 'findings' from a scan and instructs to verify with verify_fix, but does not explicitly state when not to use this tool or provide alternatives for different scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
score_deltaAInspect
Compute the readiness-score and HNDL change between two finding sets (e.g. before and after a migration). Pass 'before' and 'after' as arrays of findings from scan_path --format json.
| Name | Required | Description | Default |
|---|---|---|---|
| after | Yes | Findings after the change. | |
| before | Yes | Findings before the change (from a scan's JSON findings). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral aspects. It states it computes two metrics but does not reveal the output format, potential side effects, or performance implications. The description is incomplete for a tool with zero annotation coverage.
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 sentences with no wasted words. First sentence states purpose, second sentence provides usage. Perfectly concise.
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 is provided, but the description fails to describe the return value structure (how readiness-score and HNDL change are presented). For a tool with two array parameters and no output schema, this is a significant gap.
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 100%, with detailed item schemas. The description adds guidance to pass findings from 'scan_path --format json', which is useful but does not significantly enhance understanding beyond the schema. Baseline of 3 is appropriate.
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?
The description clearly states the verb 'compute' and the specific outputs 'readiness-score and HNDL change' between two finding sets, with a concrete example ('before and after a migration'). It distinguishes from siblings like triage_findings or explain_finding by focusing on comparison.
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 explicitly tells when to use the tool: 'between two finding sets (e.g. before and after a migration)'. It does not provide exclusions or alternatives, but the context makes usage clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
suggest_hybridBInspect
Recommend a post-quantum / hybrid migration. Provide an 'algorithm' (e.g. RSA, ECDH, ECDSA) or free-text 'context' describing the usage. Set 'tier' to 'category-5' for CNSA 2.0 / national-security systems.
| Name | Required | Description | Default |
|---|---|---|---|
| tier | No | Security tier: 'category-3' (default, commercial — ML-KEM-768 / ML-DSA-65) or 'category-5' (CNSA 2.0 / NSS, long-lived secrets — ML-KEM-1024 / ML-DSA-87). | |
| context | No | Free-text description of the cryptographic usage (used when no algorithm is given). | |
| algorithm | No | Classical algorithm family to migrate away from. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It merely states the tool recommends a migration without describing if it is read-only, what the output looks like, or any side effects. This is insufficient for an agent to anticipate behavior.
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?
The description is short (2 sentences) and front-loads the purpose. The second sentence is dense but packs useful parameter guidance. Minor improvement could be splitting into separate sentences for clarity, but overall it is appropriately concise.
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 fails to explain what the tool returns (e.g., a string, a structured plan). It also omits prerequisites or side effects, leaving the agent under-informed about how to use the recommendation result.
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 100%, so baseline is 3. The description adds semantic value by providing concrete examples ('RSA, ECDH, ECDSA') and a specific instruction for the 'tier' parameter ('set to category-5 for CNSA 2.0'), which helps the agent choose correct values.
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?
The description opens with a clear action ('Recommend a post-quantum / hybrid migration'), specifying the verb and resource. It is distinct from sibling tools, which focus on triage, fixes, and dependency checks, so no confusion arises.
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 instructs how to invoke the tool (provide algorithm or context, set tier) but does not explicitly state when to use it or when to prefer alternatives. The implied use case is clear from the purpose, but explicit guidance is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
triage_findingsAInspect
Produce a deterministic triage REQUEST bundle (rubric + verdict schema + per-finding metadata) for YOU (the host agent) to reason over. This tool does NOT call any model and needs no API key. Assess each finding's real-world exposure, then call apply_triage with your verdicts. Pass 'findings' as an array from scan_path --format json.
| Name | Required | Description | Default |
|---|---|---|---|
| findings | Yes | Findings from a scan's JSON output. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It states the tool does NOT call any model and needs no API key, implying it is a non-destructive, deterministic operation. Could directly state it has no side effects, but overall clear.
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 sentences, front-loaded with key information. Every sentence is necessary and concise, with no wasted words.
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?
Given no output schema and one parameter, the description adequately explains the purpose and workflow. It mentions the bundle contains rubric, verdict schema, and per-finding metadata, which is sufficient for the agent to understand the tool's role.
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 100% with each field described. The description adds value by indicating the source format ('from scan_path --format json') and that the array represents findings from a scan, going beyond the schema.
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?
The description clearly states the tool produces a deterministic triage request bundle for the agent to reason over, and distinguishes it from sibling apply_triage by specifying that this tool does not call any model or require an API key.
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?
Explicitly tells the agent to assess each finding and then call apply_triage with verdicts, and specifies the input format ('pass 'findings' as an array from scan_path --format json'). Provides clear context and alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
verify_fixAInspect
Run the quantakrypto detectors over a code snippet (NOT the filesystem) and report any classical crypto that remains. Use this to confirm an edit actually removed the quantum-vulnerable usage. Provide 'code' plus a 'language' or 'filename'.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | The source code to check. | |
| filename | No | Optional filename; its extension selects the detectors (overrides 'language'). | |
| language | No | Language of the code (js, ts, python, go, java, csharp, rust, ruby, c, …). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the transparency burden. It discloses that the tool runs detectors on a code snippet (not filesystem) and reports remaining classical crypto, which is sufficient for a read-only scanning tool. It does not mention destructive behavior, authentication, or rate limits, but these are implied to be negligible.
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?
The description is three sentences with no redundancy. It front-loads the action, then the use case, then parameter guidance, making it efficient and easy to parse.
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?
Given the tool has no output schema and no annotations, the description could provide more details about the return format (e.g., what kind of report is returned). The description implies a report but does not specify structure, which may cause ambiguity for the agent.
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 100%, but the description adds valuable guidance beyond the schema: 'Provide 'code' plus a 'language' or 'filename'' and explains that filename overrides language. This helps the agent select and use parameters correctly.
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?
The description clearly states the action ('run the quantakrypto detectors over a code snippet') and the resource ('code snippet'), distinguishing it from sibling tools like 'remediate_findings' or 'check_dependency'. The purpose is specific and 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?
The description provides clear when-to-use guidance ('Use this to confirm an edit actually removed the quantum-vulnerable usage') and a constraint ('NOT the filesystem'). However, it does not explicitly mention when not to use or list alternatives, though the context is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!
Your Connectors
Sign in to create a connector for this server.