Scan dependency manifest

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

Annotations already declare readOnly, idempotent and openWorld, so the safety profile is covered; the description adds real context beyond that: lock files pull in transitive dependencies, GitHub dependencies are scored as repositories, and large lock files should be passed by path. It does not explain the scoring scale or what fields the ranked results contain, which keeps this from a 5.

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, zero filler, with the core action and ordering behavior front-loaded, followed by the format list and the path-vs-content preference. Every sentence carries information an agent needs at call time.

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 read-only five-parameter tool with annotations covering the safety profile and a fully documented schema, the description covers what it does, what inputs are accepted, how large inputs are best supplied, and the shape of the output ordering. Nothing needed to call it correctly is missing.

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, but the description adds genuine guidance beyond the schema by recommending `path` over `content` for large lock files and noting the inclusion of transitive dependencies, which contextualizes max_packages. It does not clarify `filename` detection or `include_dev` behavior.

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 gives a specific verb and resource: 'Score every dependency in a manifest or lock file and list the riskiest first.' Combined with 'GitHub-hosted dependencies are scored as repositories,' the agent knows this operates on whole manifests rather than single packages, which is enough to distinguish it from check_package and compare_packages without naming them.

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?

It states the use case ('Use to audit a project's dependencies for abandoned or risky packages') and gives explicit routing between parameters ('Prefer `path` for local files, especially large lock files; otherwise pass content'). It never names when not to use it or points at the sibling tools, so the alternative-routing is left implicit.

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