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

With no annotations, the description carries the full burden and does well: it enumerates the returned facts — latest and latest stable version, yanked/deprecated status, count of newer stable versions, registry deprecation message, and the replacement target. The read-only nature is implicit in "look up," and no error behavior for unknown packages is described, which keeps it short of a 5.

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 sentences: the payload is front-loaded on the verb and the usage rule is isolated at the end where it is easy to find. The first sentence is a long comma-separated list of return fields, which reads as a run-on but every clause carries distinct information.

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-parameter lookup with no output schema and no annotations, the description supplies the return shape, the registry scope, and the staleness use case — enough to call it correctly. What is missing is failure behavior (nonexistent package, ambiguous registry) and an explicit statement that the call is side-effect free.

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 100% and the property description already gives the accepted forms, so the baseline is 3. The description adds one meaningful semantic the schema does not spell out: when no version is supplied the tool resolves to latest, and the registry prefix (npm:/crates:) selects the source.

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?

Opens with a specific verb+resource: "Look up one NEAR npm or crates.io package, optionally at a version." That is far more precise than the sibling names (check_deprecation, get_breaking_changes) and the registry scope is explicit. It stops short of naming which sibling to use instead, so an agent must infer the boundary with check_deprecation itself.

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?

Ends with a concrete trigger: "Use before adding or upgrading a dependency," which tells the agent the workflow moment this tool belongs to. No exclusions or alternatives are stated, so an agent comparing it against check_deprecation or find_known_issues gets no routing rule.

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