Packages

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

The readOnlyHint annotation is supported by the 'Search and inspect' wording, and the description adds useful behavioral context such as supported ecosystems and queried data types. It does not mention rate limits or return format, but the annotation covers the safety profile and the added context is substantial.

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 well-structured with a front-loaded purpose, bulleted actions, query formats, and a final alternative note. Every sentence contributes information without unnecessary repetition or padding.

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 tool with two parameters and no output schema, it covers all actions, query formats, ecosystem aliases, and exclusions. An agent can correctly select the action and construct a valid query without needing external documentation.

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?

Input schema already documents both parameters at 100% coverage, but the description adds value with ecosystem aliases, concrete examples like 'pypi/requests@2.32.3', and the rule that query format depends on action. This goes beyond the schema's generic property descriptions.

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 opens with a specific verb-resource pairing: 'Search and inspect software packages across language ecosystems via deps.dev' and lists concrete data types (version history, licenses, security advisories, etc.). It also distinguishes itself from sibling tools by explicitly naming alternatives for repository details.

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 includes 'Use this for package lookups' followed by specific use cases, then a clear exclusion: 'For repository details ... use web_fetch_incisive or github.' The action/query format section provides per-action guidance on when to use each operation.

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