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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description is free to add what they can't: the data source (public OpenReview decisions), the estimation method (kernel estimate over past score profiles), and the important caveat that the result is historical, not predictive. This is meaningful context beyond the structured fields, though it doesn't address output granularity (e.g., whether a confidence measure or sample size accompanies the rate).

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, front-loaded with what is computed, then the input rule, then the scope disclaimer. No filler and nothing buried; every sentence carries a distinct piece of 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?

With no output schema, the description carries the burden of explaining the return value; it identifies the output as an acceptance rate derived from a kernel estimate, which is enough to know what comes back conceptually. It stops short of saying whether the response includes a sample size or uncertainty range, a modest gap for a statistical estimate tool.

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%, so 3 is the baseline; the description earns above that by clarifying that ratings must be given 'as the reviewers gave them' — i.e., raw reviewer scores, not converted/normalized values — which matters directly given the sibling convert_score. The 3–6 count repeats the schema's minItems/maxItems rather than adding new information.

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 states a specific computation (historical acceptance rate for papers with similar reviewer ratings) over a specific resource (OpenReview decisions), which is clearly distinct from every sibling tool (convert_score, get_review_form, list_venues, etc.). An agent can tell immediately this is an odds/lookup tool, not a score converter or form fetcher.

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 a clear input condition ('Give 3–6 ratings as the reviewers gave them') and an explicit boundary ('Not a prediction of any decision'), which tells the agent when the output is and isn't appropriate to lean on. It does not name an alternative tool, but no sibling competes for this use case, so the omission is minor.

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