compatibility

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered; the description adds real behavioral context instead of repeating it. It discloses the verdict taxonomy, that answers come from a small documented rule table with rule ids R1-R12 cited, that reasoning is included, and the AGPL network-clause caveat. It also states the non-obvious rule that a multi-licensed project must be compatible with every option.

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 core question is front-loaded and the following sentences each add distinct information: input formats, output vocabulary, rule provenance, and worked examples. It is dense but not padded; the parenthetical examples and the Apache-2.0/GPL illustration earn their space by disambiguating real edge cases. Slightly packed into one block rather than separated into structure.

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 two-parameter reasoning tool, the description covers input syntax, sentinel values, output categories, reasoning content, multi-license semantics, and the AGPL caveat, and it clarifies the tool accesses no files. With an output schema present it need not detail return structure, and nothing an agent needs 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 0% -- the schema offers only titles -- so the description carries the full burden and does so thoroughly. It specifies that both parameters accept SPDX ids or expressions as well as common spellings, gives concrete examples ('MIT', 'Apache 2', 'GPL-3.0-only', 'MIT OR Apache-2.0'), and introduces the 'proprietary' sentinel for closed-source projects, none of which is discoverable from 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 frames the tool as a direct question -- can code under `dependency_license` be used in a project licensed `project_license` -- which is a specific, unambiguous verb/resource statement. It also names the four possible verdicts, so the agent knows exactly what comes back. It does not explicitly contrast itself with the sibling `check_policy`, which is the most likely source of confusion.

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?

Usage is clear: this is a pure reasoning tool for the project-license vs dependency-license relationship, and 'Does not read any files' implicitly routes file-scanning tasks to siblings like `find_license_files` or `license_inventory`. It stops short of naming an alternative for policy evaluation (`check_policy`), so the boundary with that sibling is left to inference.

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