Verify a list of IBANs

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

No annotations are provided, so the description carries the burden. It discloses the maximum batch size (500), pricing structure ($0.005 base + $0.005 × N), and the field name ('ibans'). It does not disclose what happens on mixed valid/invalid input, error behavior for the max limit, or response format, which would be valuable for a validation tool. However, the core behavioral facts (limits, cost) are disclosed.

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?

The description is compact and front-loaded with the core purpose in the first sentence, followed by pricing and docs in two additional lines. Every sentence adds value. The pricing and docs info could arguably be moved out of the description proper, but it's still efficiently presented.

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 there's no output schema, the description doesn't explain what results look like or how to interpret failure states, and it doesn't address batch error handling for a tool that validates up to 500 items. It covers purpose, limits, and cost well, but the absence of mention of return format or per-item vs batch-level failures is a gap for a tool that could produce partial results.

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?

With 0% schema description coverage and only one parameter (ibans), the description partially compensates by naming the field and stating the max 500 items. The description adds the count/limit context that the schema alone doesn't provide. However, it doesn't explain the expected format of array items (raw IBAN strings, format variations) or batch splitting strategy.

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 clearly states the verb+resource: 'validate up to 500 IBANs', resolving bank/BIC, and checking SEPA reachability. It distinguishes from sibling iban_resolve (singular/batch distinction) and iban_screen (screening vs resolution) by specifying the batch context ('Before a payment run') and the SEPA scheme checks.

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 gives a clear usage context ('Before a payment run') and specifies capabilities (validate, resolve bank/BIC, check SEPA reachability) that distinguish it from iban_screen and iban_repair siblings. It doesn't explicitly state when NOT to use it (e.g., use iban_resolve for single items), though the batch naming makes that reasonably inferable.

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