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

Annotations already declare the read-only, idempotent, open-world profile, yet the description adds substantial non-redundant behavior: redirect resolution, malformed rows counted in offset, nextOffset honored after short results, null facts, per-row probability caveats with hasOmittedAnnotations, and an explicit 60 req/IP/min limit with 429 Retry-After handling. This is well beyond what the annotations carry.

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?

Purpose and sibling routing are front-loaded, then a tight bulleted block covering pagination, errors, probabilities, and rate limits. Dense but every line carries operational consequence; no filler.

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?

For a 4-parameter paginated index reader with an output schema, the description covers the remaining gaps an agent needs: cross-call pagination discipline, failure modes, non-returned fields (no article prose/images), and throttling 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?

Schema coverage is 100%, so the baseline would be 3, but the description adds meaning the schema cannot express: page resolves redirects and '#variant' belongs only in variant, which must match a returned sourceReference, omission means all variants, offset counts skipped malformed rows, and limit bounds rows rather than kills/rolls.

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?

Opens with a specific verb and resource: 'Read indexed RS3 drop items, quantities and listed rarities.' It immediately distinguishes itself from the two most confusable siblings by naming them and their domains (combat stats vs GE identities).

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?

Explicitly routes the agent away to get_wiki_entity_facts and lookup_item for adjacent needs, and states the conditions that yield errors or empty results ('Missing/non-article sources error; unindexed articles yield empty rows'), which tells the agent when this tool will not deliver.

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