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

The annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the description's 'never installs or fixes' reinforces the safety profile rather than being new information. However, it adds valuable data-egress context by stating that package versions are sent to the configured npm registry, which tells the agent that this run has network side effects and depends on registry configuration.

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 short, front-loaded sentences: the core action first, then the data-egress behavior, then the negative guarantee. No filler.

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 description covers purpose, safety, and network behavior, which is good for a simple one-parameter tool. However, with no output schema and no parameter documentation, it should still indicate what the audit returns (a vulnerability report) and what projectPath defaults to.

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 has 0% description coverage and one parameter (projectPath) that the description never mentions. It does not explain whether the path is optional, what the default is, or whether it must be an absolute path, so the description does not compensate for the schema gap.

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 states a concrete verb and resource ('Run read-only npm audit') and makes the capability clear without the agent opening the schema. The sibling tools (dependency_inventory, dependency_outdated, package_health) are not named, so the agent must still infer that this is the vulnerability-checking one rather than the outdated-version report.

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 agent must infer when to use this tool relative to alternatives, such as dependency_outdated for version drift or package_health for a broader picture. No explicit trigger conditions or exclusions are given, so the guidance is only implied by the tool name.

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

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

Annotations already declare readOnly, idempotent, closed-world, non-destructive, so the safety profile is covered. The description adds a genuinely useful trait beyond annotations: it reads from npm lockfile v2/v3 only and requires no network — but it does not say what happens for v1 lockfiles, missing lockfile, or non-npm projects.

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?

Two short, front-loaded clauses — what it reads, then the constraint — with zero filler.

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 single-param read tool with full annotations, the core is covered, but there is no output shape description (no output schema exists), no default-path behavior, and no note on lockfile-version or error handling.

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?

One parameter (projectPath) with 0% schema description coverage and no required fields; the description never mentions the parameter or whether it defaults to the current directory. With low coverage the description should compensate and does not.

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?

Specific verb+resource: reads declared dependencies and exact installed versions from npm lockfile v2/v3. It clearly distinguishes itself from siblings (audit, outdated, health) by naming its data source and scope.

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 usage (when you need declared/installed versions from a lockfile) and the 'No network' note hints at a local-source constraint, but it never explicitly says when to prefer this over dependency_audit or dependency_outdated.

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

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

Annotations already declare read-only, idempotent, non-destructive, and open-world behavior. The description adds a useful network requirement and reinforces that dependencies are never changed, but most safety context is already covered by 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?

Two short sentences, front-loaded with the core action and followed by critical operational constraints. Every sentence carries useful information with no filler.

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 is simple and annotations cover safety, but the sole parameter is undocumented and there is no output schema. The description says what it reads but leaves projectPath semantics and return shape under-specified.

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?

There is one parameter, projectPath, with 0% schema description coverage, and the description does not explain it at all. The description gives no guidance on whether projectPath is optional, what default is used, or how it affects npm outdated.

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: 'Read available updates' via 'npm outdated.' This clearly frames the tool around outdated dependency detection, though it does not explicitly distinguish itself from siblings like dependency_audit or package_health.

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 implied by the purpose of reading available updates, and the description adds that network access is required. However, it does not explicitly say when to choose this over dependency_audit, dependency_inventory, or package_health.

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

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

Annotations already declare read-only, open-world, idempotent, and non-destructive behavior. The description adds a useful caveat that requirements are reported but not certified compatible, which clarifies the tool's output is informational rather than a compatibility guarantee.

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 two efficient sentences with no wasted language. The inspection scope is front-loaded, and the compatibility caveat is clearly separated.

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 simple read-only tool with rich annotations and no output schema, the description gives enough context about what is inspected and what the results mean. Remaining gaps are minor: it does not describe return structure or specify the expected package name format.

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 single required parameter is named 'name' with no schema description, so the schema offers no semantic detail. The description partially compensates by implying the parameter identifies a public npm package, but it does not clarify expected format, scoped package handling, or version 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 states a specific verb and resource: inspect a public npm package for deprecation, release age, Node engine, and peer requirements. It is clear what the tool reports, though it does not explicitly distinguish itself from siblings such as dependency_audit or dependency_outdated.

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 scopes the tool to public npm packages, but provides no explicit guidance on when to use it versus alternatives. The sibling tools dependency_inventory, dependency_audit, and dependency_outdated are not mentioned or differentiated.

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