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). |
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.
Add one secure layer between your agents and this server.
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.