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

Annotations already mark it read-only and non-destructive, and the description adds substantial behavioral context: reports come from a verified cache with a 180-day usability gate, the tool honestly reports no usable scan, and the SUBJECT GATE explains the meaning of a no-score reply. This goes well beyond the structured annotations and prevents misinterpretation of empty results.

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 long but front-loaded with the usage trigger and output summary, then covers cache behavior and gate semantics. Information is well organized, though the closing caveat about sentiment reflecting volume not quality is slightly redundant with the earlier 'Not for' sentence.

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?

There is no output schema, so the description must explain return content, which it does in detail (sentiment label, per-source positivity, pros/cons, themes, mention volume, scan date). It also covers failure modes and the distinction between no data and a disproved subject, making the tool fully understandable for an agent with no additional context.

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%: both 'tool' and 'response_format' already have detailed descriptions in the input schema. The description does not add extra parameter semantics beyond what the schema provides, so the baseline 3 is appropriate.

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 opens with a precise use case ('what people actually think of a specific AI tool'), names the resource ('AI tool'), and specifies the exact output: a synthesized sentiment report with label, per-source positivity, pros/cons, themes, and mention volume. It explicitly distinguishes itself from compare_tools by saying it is 'Not for product quality rankings or head-to-head choices'.

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?

It gives clear 'Use this when' triggers (likes, reputation, reviews, community feedback, complaints) and an explicit 'Not for' exclusion that routes head-to-head comparisons to compare_tools. It also details internal gates (cache usability, subject gate) that determine when results are returned or not, so an agent knows exactly when this tool is appropriate.

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