Scan code for quantum-vulnerable cryptography and get NIST post-quantum migration guidance.
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.
Average 4.2/5 across 11 of 11 tools scored.
Most tools target distinct parts of the PQC remediation workflow (explain, triage, fix, verify), but verify_fix and apply_verified_patch have overlapping purposes: both check code for remaining classical crypto. The latter adds patch-policy and blast-radius gates, making the boundary somewhat blurry.
All tool names follow a consistent verb_noun snake_case pattern (e.g., list_rules, triage_findings, verify_fix). There are no mixed conventions or unpredictable naming variations.
11 tools is well within the ideal range for a specialized toolkit. Each tool addresses a distinct step in the migration process: understanding, triaging, remediating, verifying, and scoring.
The set covers the core lifecycle: rule discovery, finding explanation, triage, remediation bundling, patch verification, and progress measurement. The only notable gap is that it relies on an external scan_path to provide findings—no scan tool is included—but this appears to be an intentional separation of concerns.
apply_triageAInspectDeterministically 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It adds meaningful traits: 'Deterministically' (guarantees reproducible output), 'Never suppresses' (assures no findings are hidden), and 're-sort by exposure' (defines ordering). While it doesn't describe return shape or error handling, the key behavior is clearly disclosed beyond a generic 'attach'.
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 two sentences, front-loaded with the primary action and key behavioral guarantees. No redundant information; every clause earns its place. The structure is efficient and scannable.
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 tool has two complex array parameters and no output schema, but the description provides essential context: the input arrays and their relationship, the deterministic merge, and sorting behavior. It implicitly covers the return value (attached, sorted findings). It could mention what happens on mismatched fingerprints or if verdicts are missing, but overall it is adequate for use.
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%, so baseline is 3. The description adds value by clarifying the relationship between parameters: 'Pass the same `findings` array you triaged plus a `verdicts` array...' and explicitly lists the required verdict fields. This reinforces the schema and gives practical usage meaning beyond type definitions.
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 function: 'Deterministically attach your triage verdicts to their findings and re-sort by exposure (highest first).' This uses a specific verb (attach) and resource (findings + verdicts), and distinguishes itself from siblings like triage_findings (which likely produces verdicts) and remediate_findings (which likely takes actions). The additional behavior 'Never suppresses' further clarifies purpose.
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 gives a clear usage context: 'Pass the same `findings` array you triaged plus a `verdicts` array...' This implies this tool is used after a triage step, effectively differentiating it from siblings. However, it does not explicitly state when NOT to use it or name alternatives, so it misses the full 'when/when-not' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
apply_verified_patchAInspectDeterministically 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility. It discloses offline/no key/no network, specific gates (in-policy, clears finding, no new finding, no network/exec sink, bounded size), non-writing behavior, and agent responsibility. This is thorough and leaves no major behavioral surprises.
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 dense paragraph, but every sentence contributes meaningful information. It front-loads the core purpose and avoids fluff. Minor improvement could be splitting into shorter sentences, but it is appropriately sized for the complexity.
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 and lack of output schema, the description covers inputs, process, constraints, and expected output (approved:true). It also tells the agent how to proceed after verification (write only if approved, never auto-merge). This is complete for safe and correct use.
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 3. The description reinforces that newContent must be the 'FULL corrected content' and adds context about verification gates, but it primarily restates schema field descriptions. It does not add substantial new parameter semantics beyond what the schema already provides.
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 VERIFY a proposed fix before writing it' and explicitly contrasts with writing tools by saying 'This does NOT write the file.' It distinguishes itself from siblings like verify_fix and remediate_findings by emphasizing deterministic verification, offline operation, and blast-radius gates.
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?
Provides clear context on when to use: when verifying a proposed fix before writing, with inputs (finding, current content, proposed content) and the output (approved:true). It implicitly differentiates from apply_triage and remediate_findings by stating it never auto-merges and the agent must write manually. However, it does not explicitly name alternative tools or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_dependencyAInspectCheck 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds useful context about the database's focus (quantum-vulnerable dependencies and classical crypto exposure) and the default ecosystem, but it does not mention what the tool returns on match/non-match or any other behavioral aspects.
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 two sentences long, front-loaded with the core purpose followed by brief parameter instructions. Every word is informative and there is no redundancy.
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 tool is simple and the purpose is clear, but there is no output schema to define return values. As a 'check' tool, the description should ideally state what a positive or negative result looks like, but it does not.
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 input schema already provides 100% coverage with descriptions for both parameters. The description essentially restates the parameter names and the default ecosystem, adding little beyond what the schema already defines.
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 uses a specific verb phrase 'Check whether' and clearly identifies the resource: 'quantakrypto's known quantum-vulnerable dependency database'. This distinguishes it from sibling tools like triage or remediation tools, making its purpose 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 includes parameter-level instructions ('Provide name and optional ecosystem') but does not explicitly state when to choose this tool over the sibling alternatives. The usage context is implied from the purpose rather than explicitly articulated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
explain_findingAInspectExplain 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). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It adds a useful detail about ruleId resolution against the core detector set, but it does not explicitly state that the tool is read-only or describe return values, leaving some 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?
The description is concise, front-loaded with the core purpose, and every sentence adds value without unnecessary fluff.
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 tool is simple: no output schema, two optional parameters. The description sufficiently covers purpose and parameters, though a brief note on return value would improve completeness, but it's not essential.
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 the description enriches both parameters with concrete examples and explains the ruleId resolution behavior, adding value 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 a specific action (explain) on a specific resource (quantakrypto finding) and its remediation, which distinguishes it from sibling tools like remediate_findings or get_fix_examples.
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 when to use the tool (to explain findings) and gives parameter guidance ('Provide a ruleId and/or an algorithm'), but it does not explicitly name alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_fix_examplesAInspectReturn 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden. It states what the tool returns but does not disclose behavior around empty inputs or both parameters supplied. There is no mention of side effects or error handling, leaving some ambiguity.
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 two sentences long, front-loaded with the verb 'Return', and contains no filler. Every clause adds value, making it highly efficient.
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 (2 optional params, no output schema), the description is largely complete: it defines purpose, input, and output. It lacks explicit details about the precedence when both params are provided or behavior when neither is supplied, but these are minor gaps for a 'get examples' 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 100% for the two parameters, and the description adds little beyond the schema. It does provide examples of algorithms (RSA, ECDH, ECDSA) and clarifies the 'or' relationship, but the core meaning is already present in the schema, so it aligns with the baseline of 3.
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 returns before/after code examples for migrating a classical algorithm to a post-quantum/hybrid replacement. It specifies the resource (code examples) and the action (return), distinguishing it from siblings like suggest_hybrid which likely recommends algorithms.
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 gives clear usage context: provide an 'algorithm' or a 'ruleId' from a finding. This implies when to use the tool, but it does not explicitly mention alternatives or when not to use it, so it only meets the 'clear context, no exclusions' level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_rulesAInspectList the quantakrypto detector catalog: every detector id and what it looks for.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It clearly states that the tool lists all detector IDs and their purposes, which is a simple read-only operation. However, it does not describe output format, potential volume, or any caveats, though the simplicity of the tool makes this less critical.
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 'List' and immediately specifies the catalog and content. No redundant words or repetition of the tool name.
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, parameterless list tool with no output schema, the description adequately covers what it returns. It could be more explicit about the output format, but the context of the sibling tools and the clear purpose make it sufficiently complete for an agent to decide to invoke it.
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 tool has zero parameters, and the schema is empty with 100% coverage. Per rubric, the baseline for 0 params is 4. The description adds context about the list content, but no parameter-specific semantics are needed.
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 uses the specific verb 'List' and identifies the resource as 'the quantakrypto detector catalog', with detail on what is returned (every detector id and what it looks for). This clearly distinguishes it from sibling tools, which are all action-oriented (apply, triage, remediate, verify).
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 when you need to see the detector catalog, but does not explicitly state when to use this tool versus alternatives or any exclusions. The distinction from siblings is clear from their names, but the description itself does not provide direct usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
remediate_findingsAInspectProduce 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the burden. It explicitly discloses that the tool calls no model, needs no key, is deterministic, and never auto-merges. The constraints around secrets and the verify-with-verify_fix step clarify side effects and validation behavior, though the phrasing blurs tool behavior and agent instructions.
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?
Every sentence provides distinct information: the output bundle, the no-model/no-key property, the usage workflow with verification, safety constraints, and input source. It is three sentences, front-loaded with purpose, and contains 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 single-parameter tool, the description covers purpose, input source, usage steps, and output bundle composition sufficiently. While there is no output schema, the description enumerates the bundle's contents; some ambiguity exists about how the host agent consumes the bundle, but it is adequate for selection and 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%, with detailed descriptions for `findings` and its items. The description adds value by instructing to pass findings from `scan_path --format json`, giving provenance beyond the schema's own text.
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?
Description opens with 'Produce a deterministic remediation REQUEST bundle' – a specific verb and resource, listing components (rubric, fix schema, metadata, fingerprints). It distinguishes itself from sibling tools by referencing verify_fix as a downstream verification step, and the 'never auto-merge' constraint separates it from apply_verified_patch.
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?
Provides clear context: findings come from scan_path --format json, and each finding should be verified with verify_fix before keeping the fix. It also gives exclusions ('Never touch files with secrets; never auto-merge'). It does not explicitly name alternatives, but the workflow is well-defined enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
score_deltaAInspectCompute 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). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. The verb 'Compute' implies a read-only operation, but it doesn't explicitly state side effects, permissions, or what happens with malformed input. It adds input source guidance but doesn't elaborate on the computation logic or output 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 a two-sentence, front-loaded statement that efficiently states the purpose and input requirements. Every word earns its place, with no redundancy or fluff.
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?
There is no output schema, so the description should explain what the tool returns (e.g., the shape of the delta or readiness-score change). It doesn't mention output format or clarify the meaning of 'readiness-score' and 'HNDL change'. The example helps but leaves significant ambiguity for a computation tool without output documentation.
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 the schema already documents both parameters in detail. The description adds value by telling the agent to pass arrays from 'scan_path --format json', which clarifies the expected input source beyond the schema. This extra guidance justifies a 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 computes 'readiness-score and HNDL change' between two finding sets, using a specific verb ('Compute') and resource. The example ('before and after a migration') and focus on delta distinguish it from sibling tools like triage or remediation.
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?
It provides clear context for when to use the tool (comparing two finding sets, e.g., migration) and specifies input format ('Pass before and after as arrays of findings from scan_path --format json'). However, it doesn't explicitly state exclusions or alternative tools, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
suggest_hybridAInspectRecommend 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the transparency burden. It clarifies that tier 'category-5' maps to CNSA 2.0/national-security systems, which is helpful, but it does not explicitly state whether the tool is read-only, describe any side effects, or disclose the return format. 'Recommend' implies non-mutating, but this is not explicit.
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 two sentences, front-loaded with the purpose. Every sentence provides actionable guidance without fluff.
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 not specify the nature of the returned recommendation or handle edge cases like both algorithm and context being provided. The basic usage is clear, but an agent may lack details on expected output and parameter exclusivity.
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% as all parameters are described in the schema. The description adds minor value by providing algorithm examples (RSA, ECDH, ECDSA) and clarifying the 'or' relationship between algorithm and context, but these are largely redundant with the schema's stated semantics. 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 function with a specific verb+resource: 'Recommend a post-quantum / hybrid migration'. This distinguishes it from sibling action-oriented tools like 'remediate_findings' or 'apply_verified_patch', which focus on execution rather than recommendation.
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 conveys when to use the tool by defining its purpose and gives clear invocation context: provide an 'algorithm' or 'context', and set 'tier' for CNSA 2.0. It does not explicitly mention alternatives or exclusions, but the context is clear given the sibling tools' action-oriented nature.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
triage_findingsAInspectProduce 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It clearly states the tool does NOT call any model, needs no API key, and is deterministic — traits not inferable from the schema or annotations otherwise. It does not mention potential side effects, but as a request-bundle producer, side effects are unlikely.
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 concise: four sentences, each with a distinct purpose — defining the output, clarifying behavioral traits, giving the next step, and specifying the parameter source. 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?
The description provides sufficient context for a one-parameter tool with no output schema. It explains the tool's role in the overall triage workflow, the nature of its output, and the follow-up action. This is complete enough for the host agent to invoke it correctly and know what to do next.
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 covers the 'findings' parameter thoroughly, so baseline is 3. The description adds value by directing the host agent to pass findings from scan_path --format json, which clarifies the expected data source and format beyond the schema's generic 'from a scan's JSON output'.
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: produce a deterministic triage REQUEST bundle. It specifies the exact output (rubric + verdict schema + per-finding metadata) and distinguishes itself from sibling apply_triage by framing itself as the preparation step.
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 gives a clear workflow: assess findings, then call apply_triage with your verdicts. It also tells users how to supply the 'findings' parameter (from scan_path --format json). While it doesn't explicitly list when not to use it, the context and mention of apply_triage make the intended usage unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
verify_fixAInspectRun 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, …). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It discloses that the tool runs detectors, reports only remaining classical crypto, and operates on code snippets rather than the filesystem. While it doesn't explicitly state side effects or return format, its analysis-oriented behavior is reasonably transparent for a verification tool.
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 the action and scope, with no redundant filler. Every clause adds information, including the filesystem exclusion and the parameter 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 covers purpose, input requirements, and scope exclusions sufficiently for a 3-parameter tool with no output schema. It doesn't explain the exact format of the report, but the return behavior is implied well enough for selection and 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% and each parameter is described. The description adds guidance that 'code' should be provided along with 'language' or 'filename', which helps the agent understand parameter selection, though 'plus' could be misread as implying the optional parameters are required.
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 runs detectors over a code snippet and reports remaining classical crypto. It explicitly distinguishes from filesystem scanning ('NOT the filesystem'), and the verb 'confirm an edit actually removed' makes the purpose specific and actionable.
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?
It explicitly says to use it to confirm an edit removed quantum-vulnerable usage, and excludes filesystem scanning as a scope. However, it does not name alternative sibling tools or describe when not to use it beyond the filesystem distinction.
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.
No comments yet. Be the first to start the discussion!
Sign in to create a connector for this server.