software_composition_audit

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 a key behavioral trait: explicit authorization is required because engines may consult advisory databases, implying external network access. However, it does not state whether the tool modifies files or only reads, nor does it describe any other side effects. The disclosure is useful but incomplete.

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 front-loads the core purpose and then adds the critical authorization note. There is no fluff or redundancy; every word contributes to understanding the tool's function and a key prerequisite.

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 is incomplete for a tool that audits lock files. It does not explain what 'audit' means in terms of output (e.g., vulnerability report, risk score), what happens during the audit, or how parameters like 'authorize_advisory_lookup' affect behavior. With no output schema and only minimal description, an agent would struggle to correctly invoke and interpret results.

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 0%, so the description must compensate. It barely touches on the 'authorize_advisory_lookup' parameter via the authorization mention, but it does not explain either parameter's purpose or how to set them. The description adds minimal value beyond what the schema shows (names and defaults). This is insufficient for a tool where parameters are not self-explanatory.

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 audits Python/npm/Go locks, specifying the verb 'audit' and the target resources. It distinguishes from generic audit tools like deep_analyzer_audit by focusing on lock files for specific ecosystems. However, it does not explicitly name sibling alternatives, so it falls short of a 5.

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: use when you need to audit lock files for Python, npm, or Go. It does not provide explicit when-not guidance or mention alternatives, but the scope is clear enough to infer the primary use case. No exclusions or alternative suggestions are given.

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