npm_license_check

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

The description discloses significant behavioral details beyond the annotations: it issues 2 requests per direct dependency (10 in flight), has a 60s cap, returns 'NOT_CHECKED' for unreached deps, and flags those as not allowed. It also explains that SPDX expressions are not decomposed and must be added verbatim to 'allowed'. These details are critical for understanding tool performance and output interpretation, and they fully align with the read-only/idempotent annotations.

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 dense but every sentence earns its place: it leads with the core purpose, then explains the matching semantics, then the network constraints and failure mode. There is no fluff or repetition; the length is justified by the informational density needed for this tool.

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?

Given the tool's complexity (network requests, timeouts, concurrency, special handling of SPDX expressions), the description covers the key operational aspects and even hints at output via the 'NOT_CHECKED' status. However, it does not describe the full return structure (e.g., whether results are a list, map, or report) since there is no output schema. This is a minor gap for an agent needing to interpret the result, but the description provides enough to anticipate common cases.

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?

The input schema already documents all three parameters with 100% coverage, so the baseline is 3. The description adds value by explaining how the 'allowed' parameter behaves (exact verbatim matching, default list, case-insensitive matching), which is not fully evident from the schema alone. It also clarifies the 'version' default implicitly by not contradicting it, though no extra syntax guidance is given for name/version.

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's action: 'Check the license of a package and its direct production dependencies. Flags missing or non-standard licenses.' It also specifies the scope (direct production dependencies) and the matching behavior, distinguishing it from other npm tools that inspect dependencies or audit security. The details about SPDX expression handling further clarify the exact resource and operation.

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 the tool is for license compliance checking but does not explicitly state when to use it over siblings like npm_audit, npm_dependencies, or npm_dep_tree. No alternatives are mentioned, so an agent must infer the use case from the name and description. There is clear context but no exclusions or routing guidance.

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