EU Business Data (VAT, EORI, company, sanctions, KYB)

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

No annotations exist, so the description carries the load and does well: it enumerates the return payload (on_official_list, status values, scored matches, list date, source) and discloses a critical caveat that this is an unofficial copy and the official lists prevail. It omits any statement about rate limits or freshness of the snapshot beyond 'list date'.

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 core question is front-loaded and every clause adds information, though the embedded examples, date parentheticals and legal disclaimer make it a dense run-on that could be split for scanability.

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 successfully enumerates the return shape and status enum, and covers the identity-matching ambiguity via the 'possible_match' status. Only the limit/pagination behavior is left unexplained.

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 0% with three parameters. The description explains name and website with concrete examples and a 'give at least one' constraint, but the 'limit' parameter is never mentioned in either schema or description, leaving one parameter fully opaque.

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?

Opens with a specific yes/no question ('Is this e-invoicing platform on France's official list of Plateformes Agréées') naming the exact resource and authority (DGFiP lists on impots.gouv.fr). This is clearly distinguishable from lookup_company or verify_vat, which check different registries.

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?

Gives a concrete usage context ('supplier due diligence before the French reform') with the regulatory timeline, plus an input rule ('give at least one') and an important negative case ('A solution compatible is not a PA itself'). It does not name which sibling to use instead when the target is not a PA, which keeps it below a 5.

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

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

With no annotations present, the description carries the full behavioral burden. It usefully discloses that totals and VAT breakdown are computed and that the return is {valid, xml, totals, errors}, which is real information even without an output schema. However, it says nothing about side effects, persistence, auth requirements, rate limits, or what 'valid' truly gates.

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 purpose is front-loaded before the dense field spec, and every line carries information with no filler. It is delivered as one long unbroken paragraph with sparse structure, which hurts scannability given the volume of nested fields.

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 tool with no annotations, no output schema, and 0% schema coverage on a nested object, the description supplies the input contract in detail and even sketches the return shape. Missing pieces are auth/permission requirements, whether anything is persisted, and richer error semantics beyond the generic 'errors' key.

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 0% and the single parameter is a deep object, so the description must compensate — and it largely does, enumerating format enum values, date formats, currency, line items with vat_category codes, and payment fields, with optionality marked by '?'. The buyer/seller '...' ellipsis and unclear required-vs-optional within nested objects leave some residual ambiguity, capping this below 5.

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 gives a specific verb+resource+standard: 'Create a validated EU e-invoice (UBL 2.1) from simple JSON'. This clearly separates it from validation/sending siblings by signalling generation of the document. It stops short of explicitly naming an alternative like validate_einvoice or send_einvoice_sandbox, so sibling differentiation is left implicit.

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?

Nothing states when to use this tool versus validate_einvoice, send_einvoice_sandbox, or einvoice_route, nor any prerequisites or ordering in the workflow. The use case is inferable from 'create' and the 'returns {valid, xml...}' note, but no explicit context or exclusions are given.

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

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

With no annotations, the description carries the full behavioral burden and does well: it discloses the deterministic nature of the assessment, the 0-100 risk score, the pass/review/fail verdict, and that sources plus a UTC timestamp are returned. It does not mention side effects, whether the call is read-only, latency/cost from multiple external registry lookups, or error behavior when an ID is not found.

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 dense sentences with the value proposition front-loaded ('in one call'), followed by the source and output enumeration and then parameter hints. Every clause carries information — the source list doubles as the effective output contract — with no filler.

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 and no annotations, the description is the only place the return contract can live, and it covers sources, flags, score, verdict and timestamp adequately; it also resolves both parameters. Gaps remain around failure modes (invalid VAT, no registry match) and whether partial results are returned.

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 document both parameters, and it does: company accepts a VAT ID (preferred), registry number or name, and country is the ISO code needed when supplying a name. It adds real precedence guidance beyond the bare schema, though exact formats (VAT prefix conventions, ISO 3166 alpha-2 vs alpha-3) are unspecified.

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 states a specific deliverable — a counterparty due-diligence report — and enumerates the exact sources it aggregates (VIES, business register, EU/UN/OFAC/UK sanctions, EORI, GLEIF LEI, Peppol), which implicitly distinguishes it from the single-purpose siblings like verify_vat and screen_sanctions. It stops short of naming a sibling explicitly, so the routing is inferable rather than stated.

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 phrase 'in one call' implies this is the aggregated alternative to the narrower sibling tools, but the description never states when to prefer it over kyb_check, verify_vat or screen_sanctions, nor any exclusion or prerequisite. Usage is left to inference from the source list.

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

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

With no annotations, the description carries the behavioral burden and does well: it discloses the data sources checked, the Peppol lookup fallback order, BIS 3 support, mandate information returned, and the France PPF limitation. It does not discuss authentication, rate limits, latency, or error behavior, so it is not fully complete.

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 front-loaded with the core question, then packs the return details and limitation into compact prose. Every clause contributes useful information, and there is no filler.

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 single-parameter tool with no output schema, the description explains what information is returned and where it comes from. It could be more complete about response structure or error cases, but no critical invocation detail 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 description coverage is 0%, so the description must explain the sole parameter. It does exactly that by defining 'id' as an EU VAT number or Peppol id and giving concrete examples for both formats.

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 states a specific capability: determining whether a company can be e-invoiced and returning VAT, Peppol, mandate, and recommended-format information. It also distinguishes itself from create_einvoice by returning a recommended format rather than creating an invoice, and from France PPF coverage by explicitly noting that limitation.

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 opening question implies the use case: checking e-invoice eligibility for a company. The mention of 'recommended format for create_einvoice' and the France PPF limitation hint at workflow and scope, but the description does not explicitly state when to use this versus verify_vat, lookup_company, or check_fr_pa_registry.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does usefully disclose the return shape (a pass/review/fail verdict with reasons), which is the single most important behavioral fact given there is no output schema. However, it says nothing about cost, latency, external-registry dependencies, failure modes when the register is unavailable, or whether it is a read-only operation.

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?

Front-loaded with the core purpose and scope in the first sentence, followed by parameter hints in the second. The '+' separated component list is dense but readable. Slightly run-on, with no whitespace separating the parameter guidance from the capability statement, but nothing is wasted.

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 annotations and no output schema, the description does the heavy lifting: it lists the underlying checks, discloses the verdict format, and gives input formats for two parameters. The gaps are the undocumented 'requester' parameter and any operational context (cost, failure handling) for a tool that fans out to multiple external registries in one call.

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 it does for two of three parameters: 'company' is documented as accepting a VAT ID ('FR40303265045'), a company name, or a registry id, and 'country' is documented as an optional ISO code (e.g. 'NO'). The third parameter, 'requester' (defaulting to 'HU33119856'), is never mentioned and its cryptic default is unexplained.

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 a specific operation on a specific resource ('One-call KYB check of a supplier/customer') and enumerates exactly what it covers: VIES VAT validation, official business register lookup, and EU/UN/OFAC/UK sanctions screening, plus the pass/review/fail verdict it returns. This composite scope implicitly separates it from the single-purpose siblings (verify_vat, screen_sanctions, lookup_company) that perform only one of those 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?

'One-call' frames the tool as the consolidated alternative to running the individual checks, and 'KYB check of a supplier/customer' makes the onboarding/verification use case clear. It stops short of explicitly naming the sibling tools or stating when-not to use this (e.g., for a VAT-only lookup where verify_vat is cheaper), so the routing condition is implied rather than stated.

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

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

No annotations exist, so the description carries the full burden. It usefully enumerates the returned fields (legal name, ID, status, address, VAT ID, activity code, source link), which substitutes for the missing output schema, but says nothing about read-only nature, permissions, rate limits, or what happens when country is omitted.

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?

Four compact lines, front-loaded with the core action before the country enumeration and return list. The dense country code list earns its place, though it slightly dominates the description relative to the two undocumented parameters.

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 annotations and no output schema, the description covers the essentials an agent needs: the lookup key, the supported registries, and the returned fields. Remaining gaps are the meaning of an empty country default and limit/pagination behavior, which are minor for a read-style 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 description coverage is 0%, so the description must compensate. It does this well for 'country' by enumerating FR/NO/FI/CZ/PL/EE plus ISO codes and 'LEI', but adds nothing for 'query' (name vs number matching behavior) or 'limit' (default 3, paging semantics), leaving two of three parameters undocumented.

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?

States a specific verb and resource ('look up a company in official European business registers') and scopes it by input type (name or registry number). It is clearly a registry lookup rather than a verification, which distinguishes it from verify_vat/kyb_check in spirit, though it never names a sibling to make the boundary explicit.

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 final sentence gives three concrete use cases (confirm existence/active status, find a registry number, map a name to a VAT ID), which is clear context for selection. It stops short of naming alternatives or exclusions, e.g. when to prefer verify_vat over mapping a name to a VAT ID.

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

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

With no annotations, the description carries the full burden and does well: it discloses fuzzy matching with transliteration, the 0-100 scoring model, and the returned fields (list, programme, DOB), plus an explicit human-review requirement. It omits auth/prerequisite and rate-limit behavior, but for a read-only screening operation that is a minor gap.

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?

Three sentences, zero waste, correctly front-loaded: purpose first, then matching/return behavior, then the risk caveat. Every sentence earns its place and nothing is repeated from the schema.

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?

No output schema and no annotations, so the description must cover behavior and returns, which it largely does. But with 4 parameters at 0% schema coverage, the missing explanation of threshold/country/birth_year leaves an agent under-informed on how to construct a correct call.

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 it only partially does: the name input is implied by 'Screen a person or company name' and the 0-100 output scores loosely relate to threshold. The country, threshold (default 85), and birth_year parameters are entirely unexplained in both schema and description, leaving three of four parameters opaque.

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?

States a specific verb (Screen) and resource (sanctions lists) and names the exact list sources (EU, UN, OFAC SDN, UK). None of the sibling tools (verify_vat, verify_eori, lookup_company, kyb_check) do sanctions screening, so an agent can route unambiguously without opening the schema.

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 intended scenario is implied (screen a person/company name) and the description adds the key operational caveat that a match needs human review and is a screening aid rather than legal advice. However, it never names alternatives or states when NOT to use this tool (e.g., vs kyb_check for broader KYC), leaving selection guidance to inference.

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

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

With no annotations, the description carries the full burden and does so richly: it discloses that it never reaches a real buyer, that some transports really submit the UBL to a partner's Peppol sandbox addressed to W System's own sandbox company, the side effects of each transport value, and the signed evidence receipt output. This is unusually complete behavioral disclosure.

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 critical constraint (SANDBOX ONLY) is front-loaded and the pipeline is laid out in sequence. It is dense with parenthetical asides and long run-on sentences, but nearly every clause adds operational information rather than filler.

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 no-annotation, no-output-schema, nested-object tool, the description is sufficient: it describes the pipeline, the transport-dependent side effects, and what is returned (evidence receipt JWS, partner document id). An agent has what it needs 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?

Schema coverage is 0%, so the description must compensate, and it does for 'transport', spelling out the meaning and effect of each value ('mock' simulated/default, 'recommand', 'e-invoice-be' with real sandbox submission and partner document id returned). The 'invoice' parameter is only referenced indirectly as 'same JSON as create_einvoice', leaving its internal semantics to another tool.

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?

States a specific verb (send) and resource (e-invoice) with an explicit scope qualifier (SANDBOX ONLY) and enumerates the exact pipeline it runs. It explicitly relates to the sibling create_einvoice by noting it takes the same JSON, so an agent can place it without ambiguity.

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?

Clearly states the intended context: 'Use it to build and test an integration before live sending exists,' which tells the agent when this tool is appropriate. It does not name an alternative live-send tool or state exclusions, but the sandbox framing provides strong usage context.

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

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

With no annotations, the description carries the full burden and does so well: it discloses the validation basis (CEN EN 16931 plus KoSIT XRechnung 3.0), the shape of the result (valid plus each error's rule ID, message, XPath, fix hint), and an explicit known gap ('Peppol-specific rules are not checked yet'). Those caveats are exactly the behavioral context an agent needs to trust or discount the output.

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?

Dense but front-loaded: the core purpose and rule scope come first, then return shape, then regional extensions and the Peppol caveat, with the REST redirection last. Slightly overloaded with regional detail, but every clause conveys selection-relevant information.

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 read-only validator with no annotations and no output schema, the description covers inputs, rulesets, return contents and known limitations. Minor gaps remain around input size limits, whether validation is purely local/stateless, and no explicit guidance for the other einvoice siblings, but nothing essential 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 0% and neither parameter is described in the schema, so the description must compensate. It explains the xml parameter's accepted formats and spells out the allowed rules values (auto | en16931 | xrechnung), which the schema does not expose as an enum. Both parameters are effectively documented.

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?

Names a specific verb and resource (validate an EU e-invoice XML) and enumerates the accepted syntaxes (UBL 2.1 Invoice/CreditNote, UN/CEFACT CII, XRechnung, Factur-X/ZUGFeRD), which clearly separates it from create_einvoice and send_einvoice_sandbox. The agent can identify the tool without opening the schema.

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?

States which rulesets apply and when extended checks kick in (Slovak sellers get eFaktúra checks, Norwegian sellers get NO-LAW checks), and routes PDFs to the REST endpoint POST /einvoice/validate. It does not phrase usage relative to the sibling MCP tools (e.g. create_einvoice), but the context is otherwise unambiguous.

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

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

With no annotations, the description carries the full burden and does much of it: batch cap of 100, VIES dependency, per-item result granularity, transient-failure retry semantics, GB staying unavailable until HMRC access, and a billing note ('not charged'). It stops short of stating rate limits, authentication needs, or error/partial-failure 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 core capability and the batch limit are front-loaded in the first clause, with exceptions (retry, GB, billing) packed into a compact follow-up. Dense but every sentence carries information; the stacked parenthetical lists are slightly heavy but not wasteful.

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 values need not be explained, and the behavioral caveats are solid. What remains missing is material for a billed batch tool: the meaning of the 'requester' parameter, VAT string format, and what happens on partial or total failure.

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 for both parameters. It partially does for 'vats' by stating the 100-item limit, but never explains the format expected per entry (country prefix, spacing) and says nothing at all about 'requester', which carries a default value an agent cannot interpret.

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?

States a specific verb and resource ('Validate up to 100 EU VAT numbers in one call via VIES'), including the batch size cap and the backing service. It also explicitly relates itself to the sibling verify_vat by promising the same per-item result, so an agent can tell them apart immediately.

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?

Names concrete scenarios (supplier/customer list cleanup, onboarding, invoice runs) and gives retry guidance for member_state_unavailable items plus the GB/HMRC exception. It does not explicitly say 'use verify_vat instead for a single number', leaving that inference to the reader, so it falls short of full when/when-not coverage.

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

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

With no annotations, the description carries the full burden and does well: it discloses the external dependency (official EC EOS service) and the conditional return behavior ('trader name/address only when the trader consented to publication'). It says nothing about rate limits, auth requirements, or failure modes for malformed numbers, so it is not complete.

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?

Three sentences, front-loaded with purpose, then usage, then behavior – no filler. The final clause ('XI EORIs are') is truncated and ambiguous, which slightly undercuts the structure.

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?

No output schema exists, and the description does explain the return shape (valid/invalid plus conditional trader name/address), which is the key thing an agent needs. Missing error semantics for invalid formats or service outages, but nothing essential to making the call is absent.

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 0% and the single property is bare ('Eori' string), so the description must compensate. It supplies two concrete format examples and the GB/XI scope carve-out, which materially helps an agent construct a valid input, though it never states the expected format rules explicitly (length, country prefix pattern).

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?

States a specific verb and resource ('Validate an EU EORI number') with concrete format examples ('SE5560360793', 'DE1234567890123') and names the authoritative source (European Commission EOS). It does not explicitly distinguish itself from the sibling verify_eori_batch, though the singular/batch naming makes the split reasonably inferable.

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?

Gives concrete use contexts ('import/export, customs declarations and freight-forwarder onboarding') and useful exclusions ('UK (GB) EORIs are not in EOS (HMRC checks those)'). It stops short of naming alternatives such as verify_vat or verify_eori_batch for related-but-different checks.

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

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

With no annotations, the description carries the full burden and does add valuable context: the upstream source (official EC EOS service) and a hard batch cap of 100. It omits any auth requirements, rate limits, or behavior on invalid/partial EORI inputs.

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?

A single tight sentence with the core action and scope front-loaded. Nothing is wasted.

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 values need no explanation, and the batch input is adequately framed. What remains thin is error/partial-failure behavior for a validation tool, but the essentials for correct invocation are present.

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 0% for the single required 'eoris' parameter, so the description must compensate. It does so reasonably by defining the content (EU EORI numbers) and the cardinality ceiling (up to 100) in one call, though it gives no format/validation rules for individual entries.

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?

States a specific verb (Validate), resource (EU EORI numbers), and scope (up to 100 in one call), which distinguishes it from the single-item verify_eori. However, it does not clarify how it differs from the generic verify_batch sibling, leaving some overlap.

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 parenthetical '(customs / import-export KYB)' implies the domain of use, but there is no explicit when-to-use guidance or routing away from verify_batch/verify_eori. Usage is inferable but not stated.

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

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

No annotations are provided, so the description carries the full disclosure burden, and it does so well for outcomes: it enumerates all status values, explains that member_state_unavailable means retry later with valid=null, and notes name/address are only returned when the member state discloses them (DE/ES often don't). The remaining gap is that it is silent on auth/credentials, rate limits, and billing for non-GB calls, so it falls short of a top score on the broader behavioral surface.

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?

Purpose and trigger are front-loaded, then input format, then the status vocabulary, then the GB caveat. Dense and mostly earned, though the parenthetical asides and the long inline status enumeration make it longer than it needs to be.

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?

Covers the input shape, the full status vocabulary including degraded-service semantics, the conditional disclosure of name/address, the audit-proof field, the GB/HMRC pending behavior with its non-billing note, and the batch alternative. For a 2-parameter lookup with no output schema, this is enough 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?

Schema coverage is 0%, so the description must compensate. It does for 'vat': country-prefix format, worked examples, and tolerance for spaces/dots. For 'requester' it only hints that a consultation_number is returned 'when requester is set', without saying whose VAT number it is or why a default exists, leaving one of two params under-specified.

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?

States a specific verb and resource (validate an EU VAT number) against a named authoritative service (European Commission VIES) with scope (27 EU states + XI Northern Ireland). It also disambiguates from the sibling verify_batch by pointing multi-number lookups there.

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?

Gives three concrete triggering scenarios (validity/active check, pre-zero-rated reverse-charge invoicing, retrieving registered name/address) and an explicit exclusion rule routing more than one number to verify_batch. Nothing about when to call it is left to inference.

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