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

Adds material behavior beyond the annotations: exact agreement from two public RPCs, safe-finality requirement, a determinism guarantee ('without fuzzy guessing'), a 10-credit cost, and automatic refund on RPC or unsafe-range failure. These are precisely the operational facts an agent cannot infer from readOnlyHint/destructiveHint/openWorldHint alone — the mutation annotations are explained by the credit charge rather than a chain write. The failure/refund path is disclosed rather than left implicit.

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?

Front-loaded with the core action and tightly written; the exception list and the cost/refund clause each carry real information. The first sentence is heavily packed with clauses across two verbs (scan, compare) and could be split for faster parsing, but no sentence is 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 multi-step, cross-RPC reconciliation tool, the description covers the mechanism, the safety model, the credit cost and refund path, and the result categories; an output schema exists so return structure need not be restated. Remaining gaps are parameter-level: block-range boundary rules and the notAfterBlock/lateness semantics implied by the 'late' exception category.

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 must compensate. It does map the top-level intent — 'one receiver', 'bounded block range', 'up to 25 expected receivables' — which corresponds to receiver, fromBlock/toBlock, and expected. However it never explains the expected item fields (payer, amountAtomic, id, notAfterBlock) or that comparison is against expected amounts, leaving the nested semantics and the atomic-amount format undocumented anywhere.

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?

States a specific verb and resource chain: scan a bounded Base Mainnet block range for native Circle USDC transfers into one receiver, cross-check two RPCs at safe finality, and diff against expected receivables. It is unmistakable against the sibling info/balance tools, which do no chain scanning. The exception taxonomy (matched, missing, underpaid, overpaid, wrong-sender, late, duplicate, needs-review) further pins down what the tool produces.

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?

Gives clear operating context: bounded block range, one receiver, up to 25 expected receivables, two-RPC agreement at safe finality, and the cost/refund condition. There are no sibling tools that overlap in function, so no alternative routing is required. It stops short of explicit when-not-to-use conditions (e.g. unsupported chains, unsafe/unfinalized ranges are only implied).

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