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. |
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.
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.