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

Annotations only declare readOnly and openWorld; the description adds substantial context beyond them: matching semantics (all aliases, word match, accents ignored), what VIES returns (valid flag, registered name and address where shared), the billing model ($0.004 USDC via x402 on Base/Solana/Arc, failed calls uncharged) and the critical caveat that a hit is a lead, not a legal determination.

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?

Two sentences, front-loaded with the core operation and consequences, with zero filler. The parentheticals are dense (matching rules, VIES output) but each carries operative information; slight compression loss from cramming pricing and legal caveat into the same block.

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?

An output schema exists so return structure needn't be spelled out, and the description nonetheless summarizes the key return fields (matched entities with EU reference, programme, regulation, link). Payment requirements, failure billing, matching scope and the interpretive caveat are all covered for a three-parameter screened lookup.

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 already 100%, so the baseline is 3, but the description adds real semantics: the 'vat' parameter triggers a distinct VIES validation path and yields specific fields, and 'name' is clarified as screening a person or company. Only 'limit' is left to the schema, which it documents adequately.

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?

Uses a specific verb ('screens') against a named resource (EU Consolidated Financial Sanctions List) and adds a second named operation (VIES VAT validation). This is clearly distinguishable from sibling EU tools like gov_ted_eu_procurement and gov_eu_funding_tenders, which cover procurement/funding rather than sanctions screening.

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 implies when to use it ('EU counterparty check in one call') and explains that supplying a VAT number unlocks the VIES leg. However, it never names an alternative tool or states exclusions, so an agent must infer that this is the sanctions/KYC path rather than a company-registry lookup.

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