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

With no annotations, the description carries the full burden of behavioral disclosure. It details the complete response structure, including the verdict, rating groups (REACH, USE, TRUST), cluster tag, distinctiveness score, and not_claimed block, giving the agent a clear picture of what to expect. However, it does not explicitly mention error handling or prerequisites beyond the exact name requirement, but the read-only nature is strongly implied by 'evidence behind the verdict'.

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 moderately long but efficiently packs the tool's purpose, usage, and return structure into a few sentences. The detailed REACH/USE/TRUST breakdown may be dense, but every clause adds value, making it appropriately sized for a complex evidence-returning 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?

This tool has no output schema, so the description must explain return values, and it does so extensively by listing all rating groups and their fields. It also provides context on how to use it relative to should_i_use, covering the main operational decisions, though it omits explicit error/not-found behavior.

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 contains a description for the 'name' parameter with an example, and the tool description reinforces 'by exact registry name'. Since schema coverage is 100%, the description adds minimal additional param semantics beyond restating the exactness requirement, meriting the baseline score.

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?

Description opens with 'The FULL evidence behind the verdict for ONE server, by exact registry name', which clearly identifies the tool's function as retrieving complete evidence for a single server. It explicitly differentiates from sibling should_i_use by stating 'call should_i_use first for the one-word decision; call this when you want the whole record.'

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 provides explicit usage guidance: 'call should_i_use first for the one-word decision; call this when you want the whole record.' This directs when to use this tool versus the sibling tool, making the usage context unmistakable.

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