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

Annotations already declare readOnlyHint=true, openWorldHint=false, idempotentHint=true, and destructiveHint=false. The description adds substantial behavioral context beyond this: it details the exact return structure, emphasizes 'IMPORTANT: relay each finding's source string,' explains the cost and rate limits, and describes the deadline and implications of type K addresses. This significantly enriches the agent's understanding of the tool's behavior.

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 lengthy but well-structured with clear sections: main purpose, USE WHEN, DO NOT USE, RETURNS, IMPORTANT, and COST. It front-loads the core functionality and then adds necessary details. While it is longer than ideal, every sentence provides value, and the structure helps an agent parse the information efficiently. It earns a 4 because it is slightly verbose but excellently organized.

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 the tool's complexity (QR-bill validation, structured vs combined addresses, reference type checks, output schema, cost details), the description is exceptionally complete. It covers when to use, what it returns, the output structure, the source requirement, and the cost model. It also explains the regulatory deadline and its implications, leaving no critical information missing for an agent to call it correctly.

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?

The input schema has one parameter 'payload' with a description, and schema coverage is 100%. The description goes further by explaining the exact format of the payload: 'The Swiss QR Code text with real line breaks: SPC, 0200, 1, IBAN, creditor (7 lines), ultimate creditor (7 empty lines), amount, currency, ultimate debtor (7 lines), reference type, reference, message, EPD, optional billing information and alternative schemes.' This adds meaning beyond the schema's basic description.

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 tool's purpose: 'Check a Swiss QR-bill payload' and specifies it checks rule-by-rule with citations. It also distinguishes itself from sibling validate_iban by explicitly stating 'DO NOT USE to learn which bank holds the account or its payment-rail participation: that is the paid validate_iban.' This gives a specific verb, resource, and differentiates from alternatives.

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 provides explicit 'USE WHEN' conditions (e.g., holding a scanned or generated QR-bill, needing to know if it is well-formed, reference type matches IBAN, and address structure) and 'DO NOT USE' conditions with a named alternative (validate_iban). This is clear guidance on when to use this tool vs. alternatives.

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