dep_outdated

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

With no annotations provided, the description carries the full burden of behavioral disclosure. The verb 'List' implies a read-only operation and the description states what output to expect (updates and breaking change warnings), which is useful context. However, it does not disclose whether network access or a lockfile is required, whether any files are modified, or how breaking change warnings are determined.

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?

A single 12-word sentence with no filler. The verb and core deliverable ('outdated dependencies') are front-loaded, followed by the two value-added output details (available updates, breaking change warnings). Every word 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 no annotations, no output schema, and a moderately specialized function in a large sibling family (dep_audit, dep_license_check, dep_update_plan). The description covers the core action but omits preconditions (supported package managers, lockfile presence), side-effect behavior, the meaning of 'breaking change warnings', and the role of api_key. An agent could call it, but would be operating on assumptions for several non-trivial aspects.

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 67%: directory and include_dev are documented in the schema, but api_key has no description and the tool description adds nothing about parameters. The api_key parameter is a genuine ambiguity — an agent cannot infer its purpose (e.g., registry authentication) from either the schema or the description. The description's mention of 'breaking change warnings' relates to output, not parameter semantics.

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 ('List') and clear resource ('outdated dependencies') and adds a distinguishing detail: 'available updates and breaking change warnings'. This differentiates it from sibling tools like dep_audit (security), dep_license_check (licenses), and dep_update_plan (planning updates), so an agent can identify its function without inspecting schemas.

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 given on when to use this tool versus its dep_* siblings (dep_audit, dep_license_check, dep_update_plan). The description never states exclusions such as 'for security auditing use dep_audit' or 'to apply updates use dep_update_plan'. Usage is only implied by the name and phrasing, leaving the selection decision to inference.

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