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

Annotations declare readOnly/openWorld/idempotent hints, and the description meaningfully elaborates each: 'Read-only; nothing is stored', same-payload-within-10-minutes charging, and the open-world 'unknown, never invalid' semantics. It also discloses the metered pricing model (1 credit per answered row, charged once after the call) and edge behavior (member state down, rate limit, 40-second time budget → `unknown` with reason), which annotations alone cannot express.

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 one dense unbroken paragraph, which hurts scannability, but it is aggressively front-loaded (core purpose in the first clause) and every sentence carries hard operational information — pricing, retries, coverage, requester behavior. For a tool with this much behavioral complexity the length is justified; structured sections would earn a 5.

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?

With no output schema, the description carries the full burden of explaining return semantics, and it succeeds: per-row answer values (`valid` with registered name, `invalid`, `unknown` with reason, `not_covered`) and the `retry.indexes` mechanism are all specified. Coverage boundaries, the 40-second time budget, the pricing model, and the tax-opinion disclaimer are all present — nothing an agent needs to invoke this tool correctly is missing.

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 baseline is 3, but the description adds real semantic value: the row-for-row response ordering contract, the functional consequence of requesterVatId (EC consultation number per answered row; a refused requester costs nothing), and the coverage taxonomy per vatId prefix (`not_covered` for GB/CH/NO/non-EU). These go beyond the schema's syntax-level documentation.

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 opens with a specific verb+resource: 'Check a whole LIST of EU VAT numbers against the EU VIES register in one call — up to 20 rows of { reference?, vatId }'. It clearly delineates the batch live-register check from mere format-level work by spelling out the two-tier design (local normalization vs live VIES lookup), which prevents confusion with the sibling check_vat_list_format.

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?

Operational guidance is extensive and precise: retry semantics ('send ONLY the rows listed in retry.indexes'), idempotent re-send ('the same payload re-sent within ten minutes is charged once'), the balance pre-requirement, and coverage boundaries (GB/CH/NO are `not_covered`). However, the description never names an alternative or states when not to use this tool — with check_vat_list_format overlapping on format validation, an explicit exclusion would push this to a 5.

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