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

With no annotations, the description carries the burden and does well: 'Pure computation; nothing is stored or sent' is exactly the side-effect disclosure an agent needs, and it enumerates what gets flagged vs. merged. It omits whether validation failures throw or are returned as issues, which keeps it from a 5.

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?

Single dense sentence, front-loaded with the purpose and the 'before paying' trigger, with the side-effect guarantee closing it. Nearly every clause earns its place, though the list of checks could be tightened.

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 an output schema exists, return-value explanation is optional, yet the description still previews totals, clean CSV, and fee estimate. Combined with the no-side-effect statement and the merge/flag semantics, an agent has enough to call it correctly; only the failure-mode behavior is unstated.

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 schema already documents rows, decimals, and mergeDuplicates. The description reinforces the accepted row formats and merge behavior but adds little parameter-level detail the schema doesn't already provide (e.g., it never mentions the decimals tolerance it enforces). Baseline 3 applies.

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 ('Validate a payout list') plus the full scope of checks performed: CSV/TSV/space parsing, EVM format and EIP-55 checksums, zero/invalid amounts, duplicates. It does not name or differentiate from the sibling payout_links, so it stops short of a 5.

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?

'before paying many wallets' gives a clear triggering context, and 'clean CSV ready to paste into the batch-payout card' clarifies the workflow position. No explicit when-not condition or named alternative is given, so it lacks the routing clarity of a 5.

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