Retrieves one of your prior scans by scan_id, including the stored full output, so you can build on earlier results without re-paying. Free to call.
| Name | Required | Description | Default |
|---|---|---|---|
| scan_id | Yes | The scan id to retrieve (from agent_history). | |
| include_full_output | No | Include the full stored tool output, not just the summary (default true). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the baseline safety profile is clear. The description adds behavioral context beyond annotations: it mentions the stored full output is included, it's scoped to 'your prior scans' (ownership), and it's free to call (cost behavior). This is useful context not present in the 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?
The description is a single sentence that leads with the action, then provides the output detail, the use case, and the cost note. Every phrase earns its place; there is no fluff or redundancy. It is appropriately compact for a simple retrieval tool.
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 low-complexity retrieval tool with two well-described parameters and no output schema, the description covers the essential purpose, usage context, and cost. It doesn't describe error handling or response shape in detail, but the 'including the stored full output' gives a high-level view of the return. Given the simplicity and strong annotations, this is sufficiently 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 schema already documents both parameters clearly. The description adds marginal value by echoing the key parameter concepts ('by scan_id', 'including the stored full output'), but it doesn't introduce new semantics or clarify any ambiguity beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Retrieves') plus a clear resource ('one of your prior scans') and identifier ('by scan_id'). It also distinguishes itself from scanning tools by focusing on retrieving past results, and the benefit ('build on earlier results without re-paying') makes the 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 gives clear context for when to use this tool: when you want earlier scan results and want to avoid re-paying. It also notes it's 'Free to call,' which is a direct usage incentive. It doesn't explicitly name alternative tools, but the mention of 'from agent_history' in the schema parameter description provides a pointer to the sibling history tool.
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 clearly distinct purposes with detailed descriptions that disambiguate overlaps (e.g., dns_security_check vs email_security_audit, ssl_tls_audit vs vet_endpoint). A few compliance lifecycle tools (compliance_framework_check, control_gap_analysis, audit_report_generate) could be confused, but descriptions clarify their sequencing.
All tool names use lowercase snake_case, but the verb/noun order varies (e.g., access_review vs agent_history vs cve_lookup). The pattern is readable and predictable enough, with minor inconsistency in whether the resource or action comes first.
28 tools is on the heavy side, exceeding the 25-tool threshold for 'too many' in the calibration. However, the broad security/compliance domain justifies the count, and each tool covers a distinct aspect, though some consolidation (e.g., email_security_audit vs dns_security_check) could reduce redundancy.
The toolset covers the full security assessment lifecycle: identity/access review, vulnerability discovery and prioritization, compliance frameworks and gap analysis, evidence collection, policy generation, incident triage, and specialized scans (code, secrets, network, web app, MCP/skill supply chain). No obvious critical gaps for the stated purpose.