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

Annotations already cover the safety profile (readOnly, non-destructive, closed-world), and the description adds genuinely useful behavior beyond them: billing ("Every delivered result is charged"), the pagination contract (next_cursor is null on the last page), and format-dependent shaping (markdown/csv return asked columns as one table with a source link per value). What is missing is any hint of rate limiting, result-size ceilings, or what a row looks like in json format.

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?

It is short and front-loads the core action, but the phrasing is dense and oblique: "the source behind each condition a page states" and "A condition no page states yet is listed on its result" require re-reading to parse. The cost warning is buried mid-paragraph rather than surfaced early.

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 five-parameter tool with no output schema and no schema descriptions, the definition leaves too much unexplained: the meaning of find_id, the 1-100 limit cap, and the evidence short/full tradeoff (which likely ties directly to the per-result charge) are all absent. It is adequate on pagination and format but incomplete overall.

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 0%, so the description carries the full burden for five parameters. It only addresses format (markdown/csv behavior), cursor (indirectly via next_cursor), and evidence loosely ("the source behind each condition"), while limit, find_id, and the short/full evidence enum are never explained.

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?

"Reads the delivered results, one page at a time" conveys a read/list operation over a paginated result set, but it never ties the tool to a find (the required find_id) or distinguishes it from siblings such as get_find, export_find, get_delivery, or get_find_decisions. The opening phrase "delivered results" is the only anchor, and it is not defined here.

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 implies paging through results but gives no explicit when-to-use versus export_find (bulk export) or get_delivery (delivery metadata). The only conditional guidance is "next_cursor is null on the last page," which is a loop-termination hint rather than a selection rule.

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