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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds value by clarifying statelessness ('No list is saved on the server'), the data source (published research only), and output handling ('Preserve unavailable rows'). These are behavioral details not captured by annotations, so a 4 is appropriate.

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 sentences, each carrying distinct value: main output, statelessness/client-side comparison, and data-source exclusion plus row-preservation instruction. The most critical information (what it returns) is front-loaded. No redundancy.

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?

Given a single simple parameter and an output schema, the description covers the essential context: data source, statelessness, input limits, and handling of missing rows. It doesn't mention authorization or error handling, but for a read-only tool with an output schema those are likely covered elsewhere. Missing a note on expected symbol format is a minor gap.

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 schema only defines an array of strings with 0% description coverage, so the description must compensate. It adds the '1-20 companies' bound and implies the symbols are tickers by saying 'Compare revisions'. However, it doesn't specify symbol format, case, or how to handle invalid symbols, so it only partially compensates for the lack of schema documentation. Baseline for 0% coverage is low, so a 3 is fair.

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 clearly states what the tool returns (latest model revisions, review status, checkpoints) and its scope (1-20 companies). It also distinguishes itself from other tools by specifying 'reads published research, not new source checks or live quotes' and 'No list is saved on the server', which differentiates it from any stateful or live-data siblings.

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 provides usage context: 'Compare revisions with your own last-seen markers' and instructs to 'Preserve unavailable rows'. It also excludes live quotes and new source checks, implying when not to use it. However, it doesn't explicitly name alternative sibling tools or state the exact condition for choosing this over get_company_revisions or check_company_forecasts, so a 4 rather than 5.

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