Vulnerabilities

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds real context beyond that: data provenance (NixOS tracker + OSV advisories), update cadence ('hourly' digest), and result ordering ('worst first'). The phrasing about the digest is murky, keeping it from 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?

Everything is packed into a single run-on sentence with heavy parenthetical nesting, and phrases like 'the vulnerabilities digest, hourly' are hard to parse. The core purpose is front-loaded, but the structure could be considerably cleaner.

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?

With no output schema, the description helpfully pre-announces what each record contains (issue, severity, affected versions, master and release-branch status), which compensates for the missing return documentation. Combined with the query modes and default ordering, an agent has enough to call it correctly, though edge cases (e.g., combining severity with package) are unaddressed.

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 100%, so the baseline is 3. The description adds value above baseline by describing default behavior when no parameters are supplied (CVEs affecting packages, worst first) and by mapping the query modes onto the parameters. It does not, however, explain parameter interaction or precedence explicitly.

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 names the resource precisely (CVEs from the NixOS security tracker plus OSV advisories for language packages) and enumerates the three query modes: one package's CVEs, one CVE/advisory id, or CVEs affecting a package sorted worst-first. This clearly separates it from siblings like issues or build_failures. It stops short of naming any sibling tool, so it earns a 4 rather than a 5.

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 three query modes imply when each parameter applies, but there is no explicit when-to-use/when-not guidance and no routing to or from alternatives like issues or find_packages. Usage is inferable but left to the agent to reconstruct.

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