Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must fully disclose behavior. It only states the purpose but does not explain how the check is performed (e.g., database lookup, API call), what 'potentially hallucinated' means precisely, or any side effects. This lack of detail limits the agent's ability to anticipate 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 single, concise sentence with no wasted words. It is front-loaded and efficiently communicates the tool's purpose.

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 lack of an output schema, the description should specify what the return value looks like (e.g., boolean, details object). It also fails to mention potential errors, performance characteristics, or any prerequisites. The tool is simple, but the description omits critical information about the output format.

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 clear descriptions for both parameters. The tool description adds context about the purpose but does not enhance parameter meaning 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 clearly states the verb 'Check' and the resource 'package name', with a specific purpose: determining legitimacy or potential hallucination. It distinguishes from sibling tools like 'sbom_check_hallucinations' by focusing on a single package name.

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 checking a package name for hallucination) but provides no explicit guidance on when not to use it or comparisons with similar tools like 'scan_packages' or 'sbom_check_hallucinations'.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 only states it's an alias without describing any behavior of scanner_health. The agent learns nothing about side effects or resource requirements.

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?

One highly focused sentence that front-loads the essential information: alias, deprecation, and replacement. 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?

Given the tool's trivial complexity (no parameters, no output schema, just a deprecated alias), the description is complete. It tells the agent everything needed: don't use this, use scanner_health instead.

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?

With zero parameters and 100% schema coverage, no additional meaning is needed. The description adds no parameter details, but none 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 is an alias for scanner_health and is deprecated. It identifies the tool's purpose as a redirect to another tool, which is specific and distinguishes it from siblings by its deprecation status.

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?

Explicitly instructs to use scanner_health instead, providing clear when-not-to-use guidance. This is a model example of usage guidelines for a deprecated alias.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the burden. It discloses that the tool collects evidence from scans and optionally saves an evidence bundle, indicating a side effect. However, it does not specify if any modifications occur, required permissions, or behavior if evidence already exists. The description is moderately transparent but could be more 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 three sentences, front-loaded with purpose and frameworks. Every sentence adds value: first defines scope, second explains process, third notes optional save. No unnecessary words or repetition.

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 the main purpose and optional save, but lacks details on output format or return value (e.g., what does 'evaluate' produce? Controls pass/fail?). It also doesn't mention prerequisites (e.g., prior scans needed) or whether network access is required. Given no output schema, these omissions reduce completeness.

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 explaining that the tool evaluates controls using evidence from multiple sources (code scans, SBOM, vulnerabilities, hallucination detection), which goes beyond individual parameter descriptions. This provides context that enhances understanding of how parameters like 'frameworks' and 'save_evidence' fit into the overall process.

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 'evaluate' and the resource 'project against compliance frameworks', listing specific frameworks (SOC2-technical, GDPR-technical, AIUC-1). It distinguishes itself from sibling tools like get_compliance_controls and scan_* tools by focusing on a holistic compliance evaluation rather than individual scans or control listings.

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 compliance evaluation but does not explicitly state when to use this tool versus alternatives like get_compliance_controls or sbom_* tools. No exclusions or context-specific guidance is provided, leaving the agent to infer.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 verbosity levels but does not mention whether the tool modifies the file, requires permissions, or has side effects. The behavioral impact of scanning and returning fixes is unclear.

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 with two sentences, front-loading the purpose and then detailing the verbosity parameter. No redundant information.

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 with 2 parameters and 100% schema coverage, the description adequately explains the return format based on verbosity. However, it lacks details about what scanning involves, what 'fixes' means, and whether there are output limitations or prerequisites.

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?

Since schema description coverage is 100%, the baseline is 3. The description adds value by explaining the three verbosity levels beyond the enum, but the file_path parameter adds no extra meaning 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 the tool scans a file and returns fixes, using a specific verb+resource. While it distinguishes itself from siblings like 'scan_security' by focusing on fixes, it could be more precise about the nature of fixes.

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 only provides guidance on the verbosity parameter (minimal, compact, full) but does not specify when to use this tool versus alternatives like 'scan_security' or other fix tools. No exclusions or contexts are given.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden for behavioral traits. It only says 'Look up,' implying a read-only operation, but lacks details on side effects, authentication, rate limits, or response structure. This is insufficient for a tool with no 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 uses two sentences: the first states the core purpose, the second provides supported frameworks and filter details. It is concise, front-loaded, and free of extraneous information.

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, the description should hint at return structure but only mentions 'compliance controls with evaluation criteria,' which is vague. It omits pagination, limits, or behavior for invalid filters. Given the tool's complexity (5 parameters, multiple frameworks), the description is adequate but not 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%, with each parameter already documented. The tool description reiterates filter options (domain, control IDs, OWASP tags) but adds no new semantic meaning beyond the schema. 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 'Look up compliance controls with evaluation criteria,' specifying the verb and resource. It lists supported frameworks and filter options, which distinguishes it from the sibling 'evaluate_compliance' that likely performs active evaluation.

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 does not explicitly state when to use this tool versus alternatives. While the name and wording imply a lookup operation, no guidance is provided on exclusions or when to prefer siblings like 'evaluate_compliance'.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description bears full burden. It implies a read operation but lacks detail on side effects, return format, or pagination. Minimal disclosure beyond the obvious.

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?

Single sentence, front-loaded with key info. Very concise, but could include more detail without being verbose.

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?

Input schema empty, no output schema, no annotations. Description does not explain what 'loaded package lists' or 'statistics' entail, leaving agents uncertain about return data and usage context.

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?

With zero parameters, schema coverage is 100%. Description adds context that the tool outputs statistics for hallucination detection, which is meaningful despite no 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?

Description clearly states the verb 'List' and resource 'statistics about loaded package lists' with a specific purpose 'hallucination detection'. While it doesn't explicitly differentiate from siblings like 'sbom_check_hallucinations', the focus on listing statistics distinguishes it.

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?

No guidance on when to use this tool versus alternatives. There are related sibling tools for hallucination detection, but the description does not clarify context or prerequisites.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, and the description does not disclose any behavioral traits such as authentication requirements, rate limits, idempotency, or side effects. For a tool with no annotations, the description must bear the full burden, and it fails to do so.

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, concise sentence. It is front-loaded and contains no fluff, though it could be slightly more descriptive about the returned data without becoming verbose.

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 (no parameters, no output schema), the description is adequate but lacks details about pagination, filtering, or the structure of the returned templates. It is minimally complete for an agent to understand the basic operation.

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 has zero parameters, and schema coverage is 100% (vacuously). The description adds no parameter information, which is acceptable since there are none. It mentions 'descriptions' in the output, which is a minor bonus.

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 that the tool lists 'security fix templates and their descriptions'. It uses a specific verb and resource, distinguishing it from siblings like 'scan_security' and 'fix_security', though the term 'security fix templates' could be more explicit.

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?

No guidance on when to use this tool versus alternatives like 'scan_security' or 'fix_security'. The description simply states what it does, without indicating prerequisites, context, or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must fully disclose behavior. It mentions querying official registries and unsupported ecosystems, but lacks details on authentication, rate limits, network requirements, or error handling. Critical behavioral traits are missing.

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 with front-loaded purpose. Every sentence provides essential information with no waste.

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?

Covers core purpose and supported ecosystems, but lacks details on output format, prerequisites (e.g., internet access), and failure modes. Given the absence of an output schema and annotations, some gaps remain.

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 each parameter. The description adds context about generating a fresh SBOM via directory_path, but does not significantly enhance parameter understanding 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 the tool checks SBOM packages against official registries to detect hallucinated names. It specifies supported ecosystems and explicitly marks unsupported ones, making it distinct from sibling tools like sbom_scan_vulnerabilities or sbom_diff.

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 use for SBOM validation but does not explicitly state when to use this tool over alternatives like sbom_scan_vulnerabilities. No when-not or alternative guidance is provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must disclose all behaviors. It states the comparison outputs and the save_baseline side effect, but does not mention other potential side effects (e.g., file creation/modification) or required permissions.

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 zero waste: the first clearly states purpose, the second gives actionable guidance. Every sentence serves a purpose.

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 parameter count and full schema coverage, the description covers the main action. It lacks detail on return format or error handling, but the tool's comparison output is sufficiently implied.

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 only adds minimal context for save_baseline, but other parameters like verbosity and directory_path are already described in 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 the tool compares the project SBOM against a stored baseline and reports added, removed, and version-changed packages. This distinguishes it from sibling tools like sbom_generate or sbom_check_hallucinations.

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 a specific usage hint ('Use save_baseline=true to create initial baseline'), giving context for first use. However, it does not explicitly exclude scenarios or mention alternatives among sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description must disclose behavioral traits. It mentions generating reports and optionally enriching with vulnerabilities, but does not disclose side effects (e.g., file creation overwrites), permissions needed, or whether the tool is read-only. The behavioral transparency is limited.

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, and includes a relevant use case. Every sentence adds value; no 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?

Given 6 parameters and no output schema, the description covers the main functionality but omits details like behavior when both sbom_path and directory_path are provided, error handling, or the exact nature of the vulnerability enrichment. It is adequate but not fully comprehensive.

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 all parameters described in the input schema. The description adds high-level context (e.g., 'audit report', 'compliance') but does not delve into parameter interactions or constraints. It meets the baseline for a well-described schema but adds only modest semantic value.

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 'Generate' and the resource 'audit report from SBOM data', specifying the output formats (HTML or JSON) and optional vulnerability enrichment. It distinguishes itself from siblings like sbom_generate (which creates the SBOM) by focusing on report export.

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 mentions suitability for 'PCI-DSS and compliance audits', giving a usage context. However, it does not explicitly state when not to use this tool or provide alternatives, such as using sbom_generate if the SBOM doesn't exist or sbom_scan_vulnerabilities for standalone scanning.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It discloses that it discovers direct and transitive dependencies from lock files/manifests, describes output formats for verbosity levels, but does not specify behavior when lock files are missing or whether the tool is read-only.

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?

Three sentences, each earning its place: purpose/scope, ecosystem list, verbosity guidance. Front-loaded with key action and resource.

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?

Covers core aspects: purpose, supported ecosystems, verbosity output, and parameter semantics. Lacks handling of missing lock files or error scenarios, but no output schema exists, so description compensates reasonably.

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 adds significant meaning beyond schema by explaining verbosity levels in detail ('counts', 'component list', 'complete CycloneDX JSON') and specifying output_path's default behavior (no write).

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 generates a CycloneDX v1.5 SBOM for a project, lists supported ecosystems (Node.js, Python, Go, Rust, Ruby, Java), and distinguishes from siblings like sbom_scan_vulnerabilities or sbom_diff by focusing on generation rather than analysis.

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 guidance on verbosity levels but does not explicitly compare with sibling tools or state when not to use it. It implies usage for generating SBOMs but lacks exclusion criteria.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It explains the main behavioral aspects (cross-referencing, retrieving vulnerabilities) but does not disclose side effects like file creation when using directory_path, authentication needs, or rate limits. Acceptable but not comprehensive.

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 front-loading the core purpose and clarifying parameters. No redundancy, each sentence adds value.

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 with 4 parameters and no output schema or annotations, the description covers inputs and outputs reasonably well. Could mention output format or pagination, but overall adequate given the tool's 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?

Schema coverage is 100% with descriptions for all 4 parameters. Description adds context for the two path parameters (mode of use) but does not elaborate on enum parameters (verbosity, severity_threshold) beyond schema. Marginal added value.

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?

Clearly states tool cross-references SBOM components against OSV.dev vulnerability database and returns specific outputs (CVE IDs, CVSS scores, severity, fix recommendations). Distinguishes from siblings by focusing on vulnerability scanning vs generation or diffing.

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 instruction on when to use directory_path (generate fresh SBOM) vs sbom_path (load saved artifact). Does not explicitly exclude alternatives or mention when not to use, but sufficient for guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It discloses that the tool returns verdicts (ALLOW/WARN/BLOCK) and lists supported action types. It implies safety (pre-execution check) but does not explicitly confirm read-only behavior or detail side effects. The disclosure is adequate for a straightforward check 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?

The description is a single, well-structured sentence that front-loads the purpose and lists supported action types compactly. 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 covers the core purpose and output verdicts, but lacks details on the verbosity parameter (though schema covers it) and does not describe the full response structure. With no output schema, the agent may lack understanding of what 'full' details include. Adequate but not 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 coverage is 100%, so the description adds minimal value beyond the schema. The description reinforces the tool's purpose but does not explain parameter semantics in more detail than the schema already provides. The baseline of 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 performs a 'Pre-execution security check for agent actions' and lists specific action types (bash, file_write, etc.), making the purpose and scope unambiguous. It distinguishes itself from sibling tools by focusing on pre-execution checks for agent 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 is for pre-execution security evaluation, but does not explicitly state when to use this tool versus alternatives like 'evaluate_compliance' or 'fix_security'. No when-not-to-use or alternative recommendations are provided, so guidance is implicit but not fully explicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 states the tool scans and returns a result but does not disclose whether it modifies any state, requires specific permissions, or has side effects. For a security tool, behavioral traits like read-only nature, network calls, or audit logging should be mentioned.

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 with no wasted words. It front-loads the purpose and then gives actionable verbosity 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?

Given no output schema, the description mentions possible return values (BLOCK/WARN/LOG/ALLOW), which is helpful. However, it does not specify whether the result is a simple string or a structured object. It also doesn't cover potential errors or timeouts. For a simple tool, the basics are covered, but more details on output format would improve completeness.

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 is 3. The description adds minimal value beyond the schema: it explains verbosity values ('minimal' for action only, etc.), which are already in the enum. The description doesn't clarify the 'context' object beyond the schema. Overall, the description does not significantly improve parameter understanding.

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 scans a prompt for malicious intent and returns a classification (BLOCK/WARN/LOG/ALLOW). It specifies the resource (prompt) and action (scan), which is specific enough to differentiate from sibling tools like 'scan_agent_action' or 'scan_security', though it could be more explicit about what constitutes 'malicious intent'.

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 guidance on the verbosity parameter (minimal/compact/full) but fails to mention when to use this tool versus alternatives. With siblings like 'scan_agent_action' and 'scan_mcp_server', the description should indicate scenarios where prompt scanning is appropriate and when other tools are preferred. No 'when not to use' or alternatives are mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 that only changed lines are reported, which is key behavior. However, it does not mention if the tool is read-only, what it returns, or any side effects. Given the scan nature, it's likely non-destructive but not explicitly stated.

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 with no wasted words. Front-loaded with the core action and purpose, followed by a key constraint and usage hint.

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 3 optional parameters and no output schema. The description explains the core behavior and use case adequately for typical PR review scenarios. Could be improved by hinting at the return format, but 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% with descriptions for all three parameters. The description does not add new semantics beyond the schema, so 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?

Description clearly states the verb 'Scan' and resource 'git diff' with a specific purpose 'new security vulnerabilities'. The scope is explicitly limited to 'changed lines', and it's directly tied to 'PR reviews', distinguishing it from siblings like 'scan_security' or 'scan_project'.

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?

Explicitly says 'Use for PR reviews', providing clear context. Does not list when not to use or alternatives, but the purpose and scope are well-defined enough to guide appropriate use.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It discloses tool behavior (scans for vulnerabilities, returns grade and recommendations) but does not state whether it is read-only, has side effects (e.g., updates baseline file is mentioned in param but not in behavior), or requires specific permissions. For a tool named 'scan', read-only is implied but 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?

Single sentence that front-loads the core purpose and lists key vulnerability categories. No wasted words, every part adds information. Structure is optimal for quick understanding.

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 main purpose, scanning categories, and output format (grade A-F and recommendations). Given 4 parameters all described in schema and no output schema, the description is sufficiently complete. Minor gap: does not mention scope or limitations (e.g., whether it scans dependencies recursively), but overall adequate.

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%, but the description adds value by explaining the purpose of the manifest parameter (poisoning indicators) and update_baseline parameter (writes to .mcp-security-baseline.json). It also clarifies verbosity levels minimally. This goes beyond what the schema 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?

Description clearly states it scans MCP server source code for security vulnerabilities (overly broad permissions, missing input validation, etc.) and returns a grade with recommendations. This is specific to MCP servers, distinguishing it from siblings like scan_security or scan_project.

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?

Description implies use when scanning an MCP server's security, but does not provide explicit guidance on when not to use it or how it differs from sibling tools such as scan_security, scan_project, or check_package. No alternatives or exclusions are mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must disclose behavioral traits. It states health checking but does not specify whether the operation is read-only, requires special permissions, or has any side effects. The return type and structure are also omitted.

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?

Single sentence with clear front-loading of purpose. Every word is meaningful, 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 zero-parameter, no-output-schema tool, the description is adequate but not thorough. It covers the main function but omits details like return format or whether the check is instantaneous. Slightly above minimum viable.

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?

There are zero parameters, so baseline is 4. The description adds value by enumerating what is checked (engine status, daemon status, package data availability), which provides semantic context beyond the empty 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 checks plugin health and lists specific aspects (engine, daemon, package data). However, it does not differentiate from the sibling tool 'clawproof_health', which likely has a similar 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?

No guidance is provided on when to use this tool versus alternatives like 'clawproof_health' or other scanning tools. The description lacks context about prerequisites or excluded scenarios.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 only states the basic action (scan and check) without disclosing side effects, safety implications, or whether it is read-only. Significant gaps remain for a tool with no 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 two sentences: the first states the purpose, the second provides essential verbosity guidance. There is no fluff, and key information is front-loaded. 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?

Given the tool has 3 parameters, no output schema, and no annotations, the description adequately covers purpose and verbosity but misses context such as what 'hallucinated' means in output, expected return format, or any preconditions. It is minimally viable but not rich.

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 base is 3. The description adds value by explaining verbosity levels beyond the schema's enum descriptions (e.g., 'minimal for counts', 'compact for flagged packages'). This helps an agent choose the right verbosity for the task.

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: scanning code for package imports and checking for hallucinated (AI-invented) packages. The verb 'scan' and resource 'package imports' are specific, distinguishing it from sibling tools like check_package or sbom_check_hallucinations.

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 guidance on verbosity levels (minimal, compact, full) for using the tool, but does not explicitly state when to use this tool over alternatives or any exclusions. Usage context is implied but not directly addressed.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must disclose behavioral traits. It mentions scanning, .gitignore support, and grading, but does not explicitly state whether the tool is read-only, destructive, or requires permissions. The safety profile is implied rather than 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-loading purpose and then providing usage guidance. No redundant information; every sentence adds value.

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 7 parameters and no output schema, the description covers verbosity well but does not explain other important parameters like exclude/include patterns, diff_only, or cross_file. The schema provides details, but the description could better guide parameter usage for completeness.

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% (baseline 3). The description adds meaning by explaining verbosity levels, which is beyond the enum values. However, other parameters like 'diff_only', 'recursive', and 'exclude_patterns' are not elaborated, so value addition is partial.

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 scans a directory for security vulnerabilities with .gitignore support and security grading. It distinguishes from siblings like 'scan_packages' or 'scan_git_diff' by specifying 'entire directory' and unique features.

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 guidance on verbosity levels ('minimal' for grade+counts, 'compact' for top issues, 'full' for all details), but does not mention when to avoid this tool or alternatives among the many sibling scanning tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided. The description only mentions scanning behavior and rough token counts for verbosity levels, but lacks details on side effects, permissions, or error cases. Insufficient for a secure scanning 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 with clear front-loaded purpose. The second sentence adds actionable usage guidance for verbosity. Efficient and focused, 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?

No output schema exists; description does not explain return values or structure beyond vague 'actionable info' vs 'complete metadata'. Lacks details on result format, severity levels, or how to interpret output, making it incomplete for practical 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 covers 100% of parameters, so baseline is 3. Description adds token count estimates and default verbosity behavior, but other parameters like engine and output_format are not explained in the description, missing opportunity to add value.

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 scans a file for security vulnerabilities. It implies single-file scope, which distinguishes it from sibling tools like scan_project and scan_packages, but doesn't explicitly differentiate.

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 guidance on verbosity usage (~50, ~200 tokens) but fails to specify when to use this tool vs alternatives or when not to use it. No explicit context for tool selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 multi-layer analysis and a return grade A-F, but does not clarify whether the scan is read-only or if it saves state (the 'baseline' parameter suggests it might). Missing details on side effects or permissions.

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: the first defines the purpose, the second lists analyses and output. It is front-loaded, concise, and 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 3 parameters (1 required) and no output schema. The description covers the tool's purpose, types of analysis, and return format (grade A-F with findings), which is sufficient for an agent. The 'baseline' parameter is also explained in context.

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 value by explaining that the 'baseline' parameter saves the scan as a baseline for rug pull detection, and 'verbosity' controls detail level. This provides meaningful context 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 the tool performs a deep security scan of an OpenClaw skill, listing specific analysis types (prompt injection, code analysis, malware signatures, supply chain, rug pull). This distinguishes it from sibling tools like scan_security or scan_packages.

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 use when scanning a skill but does not provide explicit when-to-use or when-not-to-use guidance. No alternatives are mentioned, and the context does not exclude other related tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It states the tool returns scores and posture, but does not disclose potential side effects, authorization needs, or error behavior. For a read-like scoring tool, this is adequate but not thorough.

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, front-loaded with purpose. Each sentence adds essential information: purpose, input, and verbosity behavior. No fluff 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?

The description explains output structure based on verbosity, which compensates for lack of output schema. It covers input constraints and customization options. Missing error handling details, but overall complete for a scoring tool with 4 parameters.

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%, baseline 3. The description adds value by explaining verbosity levels and what each returns ('minimal' for posture, 'compact' for scores, 'full' for all metrics). It also clarifies overrides as manual AIVSS metric overrides and source_tool for normalization hints.

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 explicitly states the tool scores findings using OWASP AIVSS v2. It specifies the input type (any scanner output or raw findings JSON) and output (per-finding scores 0-10 and aggregate posture). This clearly distinguishes it from sibling scanning tools like scan_security.

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: use after obtaining findings from any scanner. It offers verbosity options to control output detail. However, it does not explicitly state when not to use or mention alternatives, though sibling differentiation is implicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.