Hosted, OAuth-gated endpoint for quantakrypto's post-quantum crypto tools: scan code for quantum-vulnerable cryptography (RSA/ECDH/ECDSA/DH) and get NIST ML-KEM/ML-DSA/SLH-DSA migration guidance over authenticated HTTP — nothing to install. Sign-in required (Google/GitHub/email). Same tools as the open-source @quantakrypto/mcp server; source at github.com/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.
Average 4.3/5 across 11 of 11 tools scored.
Most tools have clear and distinct purposes, but there is some overlap in the fix/verify area: apply_verified_patch, verify_fix, and remediate_findings all involve verification, which could cause an agent to hesitate on which to use. However, the descriptions differentiate them well (single-fix verification vs. snippet verification vs. batch remediation). Triage and apply_triage are clearly sequential.
All tool names follow a consistent verb_noun pattern in lower_snake_case (e.g., check_dependency, list_rules, suggest_hybrid). The only slight variation is apply_verified_patch with an adjective, but it still follows verb_noun structure and the pattern is otherwise uniform.
11 tools is well within the ideal 3-15 range and each serves a distinct function in the post-quantum analysis and remediation workflow: detection, explanation, triage, remediation, and scoring. No obvious redundant tools. The count feels well-scoped for the domain.
The tool set covers analysis (explain_finding, get_fix_examples), triage (triage_findings, apply_triage), remediation (remediate_findings, apply_verified_patch), and scoring (score_delta), but there is no scan tool. All triage/remediation tools require 'findings' arrays from an external scan_path command, which is not exposed as a tool in this server. This creates a significant gap in the workflow, as agents cannot initiate scans without an external dependency.
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 provided, the description carries the full burden and does well: it discloses deterministic behavior, the 'never suppresses' guarantee, and the exposure-based sort order. It stops short of describing return shape or error handling, but the most important behavioral traits are covered.
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 cover the action, input requirements, ordering behavior, and a key guarantee. No redundancy or 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?
No output schema exists, so the return value is not formally documented; however, 'attach ... to findings and re-sort' strongly implies an enriched/sorted findings array. The description covers input linkage, ordering, and the no-suppression behavior, with only error cases left unspecified.
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 has 100% coverage for both parameters, so baseline is 3. The description adds value by specifying that findings should be the same array already triaged and listing the required verdict fields ({ fingerprint, exposureScore, priority, rationale }), which clarifies the relationship between the two parameters.
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 ('attach') with a clear resource (triage verdicts to findings) and outcome (re-sort by exposure, highest first). It distinguishes itself from sibling tools like triage_findings, which would produce the verdicts, and remediate_findings, which acts on findings.
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 workflow context: pass the same findings array you triaged plus a verdicts array, establishing when this tool should be used. It does not explicitly name alternatives or exclusions, but the tie to a prior triage step is unambiguous.
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?
Despite no annotations, the description fully discloses behavior: it runs patch-policy, verify_fix, and blast-radius gates; returns approved:true only under enumerated conditions; does not write the file; and operates offline. This exceeds the burden given absent annotations.
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 dense but purposeful sentences. It front-loads the key verb and uses the remaining space for approval criteria and side-effect clarification, with zero 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?
Given no output schema and no annotations, this description fully covers inputs, behavior, approval criteria, and side effects. It tells the user exactly what to provide, what will happen, and 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 provides 100% description coverage, so baseline is 3. The tool description adds value by explaining the roles of the finding, originalContent, and newContent in prose and by describing the approval output, going slightly 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 opens with 'Deterministically VERIFY a proposed fix before writing it', naming a specific verb and resource, and explicitly states 'This does NOT write the file', which clearly distinguishes it from apply/remediate tools. It also conveys the offline, no-key/non-network nature.
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 context for use: before writing a fix, offline, and with required inputs. It instructs the user to write only when approved and never auto-merge, but it does not explicitly name alternative sibling tools such as verify_fix for comparison.
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. It correctly implies a read-only lookup ('Check whether') and adds context about the database's purpose. However, it does not describe output format, error behavior, or any side effects, leaving some behavioral aspects undisclosed.
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 main purpose, and includes essential usage details without any filler. Every clause 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?
The tool is simple with only two parameters and no output schema, but the description does not explain what the response contains (e.g., a simple boolean versus a detailed match with crypto information). Given the parenthetical about 'classical crypto', more detail would help the agent anticipate the result; still, the core purpose is clear.
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 both parameters, but the description adds a meaningful default for 'ecosystem' (npm) and clarifies which parameter is required. This goes beyond the schema's descriptions and helps the agent invoke the tool 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 ('Check whether') and the exact resource ('quantakrypto's known quantum-vulnerable dependency database'). It also specifies the input fields, making its purpose unmistakable and distinct from sibling tools that handle remediation or verification.
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 it (when you need to check a package against the database) and explains how to provide parameters. However, it does not explicitly mention when not to use it or provide alternative tool names for related tasks, so the usage guidance is only implied rather than explicitly contrasted.
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 burden of behavioral disclosure. It adds a meaningful trait: 'The ruleId is resolved against the core detector set, so library and config rules explain correctly.' However, it does not disclose side effects, return format, error behavior, or what happens if neither parameter is provided. This is adequate but leaves 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 two sentences with no filler. It front-loads the core purpose and immediately follows with actionable parameter guidance. Every sentence 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?
The tool has no output schema and no annotations, so the description must convey enough context. It covers purpose and parameters but does not describe what the explanation will contain (e.g., remediation steps, affected components) or failure modes. For a read-only explain tool, this is a moderate 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%, so the baseline is 3. The description adds concrete examples for ruleId and algorithm and clarifies the relationship between them ('and/or'). It also explains the resolution behavior of ruleId, which adds meaning beyond the schema's brief descriptions.
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 specific verb+resource: 'Explain a quantakrypto finding and its post-quantum remediation.' This clearly distinguishes the tool from siblings that apply patches, triage, or list rules. The inclusion of example ruleId and algorithm values further reinforces the intended 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 provides explicit input guidance: 'Provide a ruleId and/or an algorithm.' It also explains that ruleId is resolved against the core detector set, which clarifies when the tool works. However, it does not mention when to use this tool over alternatives like get_fix_examples or remediate_findings, nor does it state 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 full burden. It discloses the tool is a read-only retrieval action ('Return examples'), which is good, but it does not detail return format, handling of both parameters, or error behavior. It is adequate but not rich.
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 purpose, followed by input guidance. Every word earns its place with no redundancy or 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 read tool with two optional parameters and no output schema, the description covers the essential information: what it returns and how to specify inputs. It lacks return structure detail (e.g., whether examples are a list), but this is not critical given the straightforward nature. A 4 is appropriate.
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 baseline is 3. The tool description adds value by specifying examples ('RSA, ECDH, ECDSA') and clarifying the exclusive relationship between 'algorithm' and 'ruleId' with 'or', which the schema does not explicitly state. This goes beyond simple restatement.
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 ('Return') and resource ('before/after code examples'), plus the scope ('migrating a classical algorithm to a post-quantum / hybrid replacement'). It distinguishes itself from siblings like suggest_hybrid by focusing on concrete examples rather than suggestions.
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 context on when to use the tool: when you have an algorithm (RSA, ECDH, ECDSA) or a ruleId from a finding. It implies the usage scenario but does not explicitly mention alternatives or exclusions, making it slightly below a fully specified guideline.
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 full burden. It states the action (list) and the content (detector ids and what they look for), which implies a read-only operation. However, it does not explicitly disclose side-effect-free behavior or any other traits beyond the action itself.
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, front-loaded sentence that states the action and the expected result without any wasted words. 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?
Given the tool has no parameters and no output schema, the description sufficiently explains what the tool returns: a catalog of detector ids and their descriptions. It is complete for its simple purpose.
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, so the baseline is 4. The description adds no parameter-specific information because none exists, but the schema already covers 100% of the (empty) parameter space.
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 specific resource 'quantakrypto detector catalog', and further specifies the output includes every detector id and its purpose. This distinguishes it from sibling tools which focus on applying triage, remediation, and other actions.
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 when one needs to see the available detectors, but it does not explicitly state when to use this tool over siblings or provide exclusion criteria. The context is clear from the tool's purpose, but no explicit guidance is given.
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?
With no annotations, the description carries the full burden and does an excellent job. It discloses determinism, no model call, no key requirement, the verification workflow with verify_fix, filtering of fixes, and explicit no-secrets/no-auto-merge constraints. This provides rich behavioral context beyond what any structured annotation would offer.
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 and effectively front-loaded. It opens with the core output ('deterministic remediation REQUEST bundle') and then packs critical constraints and workflow steps into a few sentences. No filler or redundant phrasing.
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, the description covers the full workflow: input source, processing steps, verification, filtering, and safety constraints. Although there is no output schema, the description enumerates what the bundle includes (rubric, fix schema, metadata, fingerprints), giving the agent a complete picture without needing further 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?
The schema already has 100% description coverage of the 'findings' parameter, including each subfield. The description adds meaningful provenance by instructing to pass findings from 'scan_path --format json', which is not captured in the schema. This extra guidance raises it above the baseline.
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 remediation REQUEST bundle' for the host agent to fix. It includes specific components (rubric, fix schema, metadata, fingerprints) and distinguishes itself from sibling tools by explicitly prohibiting auto-merge and directing verification to verify_fix.
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 context on how to use the tool: pass findings from scan_path --format json, propose corrected full file content, verify with verify_fix, and keep only fixes that clear the finding. It also gives exclusions ('Never touch files with secrets; never auto-merge'). It could be stronger by explicitly naming alternative tools, but the context is sufficient.
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?
With no annotations, the description must carry the full disclosure burden. It states what is computed (readiness-score and HNDL change) and implies a read-only computation, but it does not explicitly confirm no side effects, explain the matching logic, or define the 'HNDL' acronym in the description.
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 resource, and no wasted words. The purpose and input format are delivered efficiently.
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 compute/analysis tool without an output schema, the description adequately conveys inputs and the general output (readiness-score and HNDL change). It could be improved by describing how findings are matched (e.g., by ruleId and location) and the output format, but it remains reasonably complete given the tool's moderate complexity.
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 provides 100% coverage with detailed descriptions for both parameters. The description adds little beyond what the schema already states, mentioning the source format which is also in the schema item description. This meets the baseline for full schema coverage.
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 with a specific verb ('Compute') and resource ('readiness-score and HNDL change between two finding sets'). It distinguishes itself from siblings, none of which perform delta comparisons.
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 a concrete use case ('e.g. before and after a migration') and instructs how to pass parameters ('arrays of findings from scan_path --format json'). It gives clear context but does not explicitly mention when not to use it or alternative tools, though no siblings are relevant.
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?
With no annotations, the description carries the transparency burden but only states the recommendation behavior; it does not disclose return format or explicitly confirm no side effects.
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 front-loaded sentences, every clause earns its place; 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?
For a simple 3-param tool with rich schema, the description is reasonably complete; however, no output schema means return-value details are absent, so not a 5.
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 covers 100%, but the description adds value by clarifying that algorithm and context are alternatives and giving examples, plus when to use category-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?
The description states a specific verb ('Recommend') and resource ('a post-quantum / hybrid migration'), clearly differentiating from sibling triage/remediation tools.
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 instructs to provide either an algorithm or free-text context and to set tier to 'category-5' for CNSA 2.0/NSS, giving clear usage context; it does not explicitly mention when to prefer alternatives.
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?
No annotations are provided, so the description carries the full burden. It discloses important behavioral traits: the tool is 'deterministic', 'does NOT call any model', and 'needs no API key'. This gives the agent confidence about side-effect-free, repeatable execution. However, it does not explicitly state whether the tool is read-only or what side effects (if any) it has, which would be even more transparent.
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, each serving a distinct purpose: what it produces, the no-model/no-key guarantee, and the usage workflow. It is compact but the first sentence is slightly dense with parentheticals ('(rubric + verdict schema + per-finding metadata)'), which could be streamlined. Overall, it is efficient and front-loaded.
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 that generates a bundle for the host agent to reason over, the description provides enough context to use it correctly: the workflow, input source, and the fact that it doesn't call models. There is no output schema, so the description's summary of the bundle's components (rubric, verdict schema, per-finding metadata) is helpful. It could be more complete by describing the response format, but the agent's follow-up action (apply_triage) is clearly indicated.
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 fully describes the 'findings' parameter with 100% coverage. The description adds valuable context beyond the schema by specifying the exact source: 'from scan_path --format json'. This helps the agent understand the expected structure and provenance of the input, going beyond the raw 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's purpose: 'Produce a deterministic triage REQUEST bundle (rubric + verdict schema + per-finding metadata)'. It distinguishes itself from the sibling tool apply_triage by noting the bundle is 'for YOU (the host agent) to reason over' and that the tool 'does NOT call any model' – a unique characteristic among the sibling tools.
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 explicit workflow guidance: 'Assess each finding's real-world exposure, then call apply_triage with your verdicts.' It also specifies the exact input source: 'Pass 'findings' as an array from scan_path --format json.' This clearly tells when to use this tool (before apply_triage) and what to do with its output.
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 burden of behavioral disclosure. It communicates that the tool analyzes a code snippet and reports remaining issues, and it clarifies scope by excluding the filesystem. However, it does not explicitly state side effects (e.g., read-only), error behavior, or the structure of the report, which would provide fuller transparency.
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 at three sentences, front-loads the core purpose, and every sentence earns its place: what it does, when to use it, and what inputs to provide. No filler or 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?
Given the tool's modest complexity (3 params, no nested objects), the description covers purpose, scope, usage context, and input requirements. It gives a general sense of the return ('report any classical crypto that remains'), though a bit more detail about the output format would make it fully complete.
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 the parameter details are already well documented. The description adds a helpful hint to provide 'code' plus 'language' or 'filename', but this largely restates what the schema already indicates, adding minimal new meaning.
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 identifies a specific action: running quantakrypto detectors over a code snippet and reporting remaining classical crypto. It also states the intended use case ('confirm an edit actually removed the quantum-vulnerable usage'), distinguishing it from sibling tools like triage_findings or remediate_findings.
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 states when to use the tool ('Use this to confirm an edit actually removed the quantum-vulnerable usage') and provides an exclusion ('NOT the filesystem'). However, it does not name alternative sibling tools, so it falls just short of the highest level.
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!
