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

With no annotations, the description carries the full disclosure burden and does real work: it states that invalid input is a normal 200 with valid:false and a reason rather than an error, that each lookup costs €0.005 billed to the API key, and that auth is via Authorization: Bearer. That is exactly the kind of context an agent needs before calling a metered external service. It stops short of the 5 because rate limits, retry/error behaviour on transport failure, and whether the call is free of side effects are not addressed.

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?

Content is dense and front-loaded: capability first, then error semantics, then cost/auth, then parameters. The long parenthetical enumerating IBAN subfields is somewhat crowded but each element carries information. No filler sentences.

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 two-parameter, zero-annotation tool with an output schema, the definition covers the expensive parts — cost, auth header, and the crucial non-error semantics of invalid input — so return values need not be explained. The remaining shortfall is the unstated at-least-one-parameter constraint, which an agent could get wrong.

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 and largely does: iban accepts any formatting with spaces ignored, and bic is an alternative or supplement to iban. The one meaningful gap is that both parameters are optional at the schema level, yet the description never says that at least one of iban or bic is required for a sensible call.

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 names the resource (IBAN and/or standalone BIC) and what is produced: structure, checksum, country, bank/branch/account codes, derived BIC, and bank name from the registry. That is specific enough to distinguish it from neighbours such as vat_check or phone_validate without opening the schema. It loses a point only because the opening is a noun fragment rather than a clear verb ('Structure and checksum of...') and the explicit validation verb lives in the tool name, not the description.

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?

It clarifies the iban/bic relationship — 'alternative or in addition to iban' — which is genuine usage guidance for choosing inputs. There is no statement of when to prefer this tool over siblings (e.g. a full company or VAT check) and no exclusions. Usage is implied rather than explicitly framed.

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