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

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?

With no annotations, the description carries the full burden. It helpfully discloses the return fields (legal name, ID, status, address, VAT ID, activity code, source link), implying a read-only lookup, but it says nothing about authentication, rate limits, quota costs, or result completeness/pagination.

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 in the opening sentence, and the country-code sentence and return-field sentence each add distinct value with minimal waste. It is compact and well ordered, though the country-code enumeration is dense.

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 3-parameter tool with no annotations and no output schema, the description is reasonably complete: it names the data sources and lists return fields. Gaps remain around the undocumented 'limit' parameter and any behavioral constraints (auth, rate limits), which leaves the agent guessing on edge cases.

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 explains 'query' (name or registry number) and richly documents 'country' with per-country identifier mappings (SIREN, org.nr, Y-tunnus, ICO, KRS, LEI/GLEIF), but the 'limit' parameter is left entirely unexplained in both schema and 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 states a specific verb and resource ('Look up a company in official European business registers by name or registry number'), which is far more informative than the name alone. It does not, however, differentiate itself from siblings like kyb_check, verify_vat, or verify_eori, so an agent must infer which lookup tool fits which task.

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?

Usage is implied by the description and the country-code list gives practical context for how to invoke it, but there is no explicit when-to-use guidance, no exclusion of when NOT to use it, and no routing to sibling tools such as verify_vat for VAT verification or kyb_check for onboarding.

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?

No annotations are provided, so the description carries the full burden. It does disclose a genuine behavioral constraint (the 100-number batch cap), but says nothing about partial failures, per-item error handling, rate limits, or what the 'requester' value is used for.

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 sentence with the verb and batch limit front-loaded, followed by parenthetical use cases; no filler. It is tight, though the terseness leaves obvious gaps unaddressed.

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 described. Still, for a 0%-coverage, annotation-free tool, the description omits VAT number format expectations, partial-failure semantics, and the meaning of 'requester' — leaving the agent guessing on real call-shaping details.

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 not. It implies the 'vats' array holds EU VAT numbers and caps the count at 100, but gives no expected format (country prefix, separators), and the 'requester' parameter — with a surprising default of HU33119856 — is completely 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 states a specific verb and resource ('Verify ... EU VAT numbers') and adds batch scope ('up to 100 ... at once'), which implicitly separates it from the single-number sibling verify_vat. It does not explicitly name verify_vat or verify_eori_batch as the alternatives, so the differentiation is inferred 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?

It lists business contexts (supplier/customer onboarding, KYB, invoice checks), which implies when the tool is relevant. However, it never says when to prefer this over verify_vat for a single number, or when verify_eori_batch is the right call instead — no exclusions or routing guidance.

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. It does disclose the authoritative source (official European Commission EOS API) and the shape of the result ('valid/invalid and name/address when disclosed'), which is genuinely useful given there is no output schema. It omits failure behavior for malformed input, rate limits, and any auth requirements.

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 short sentences with no filler; the core action is front-loaded and the supporting detail (API source, return content) follows. Every sentence earns its place.

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?

Since no output schema exists, the description correctly takes on the job of describing return values ('valid/invalid and name/address when disclosed'). For a one-parameter lookup this is nearly complete, with only input-validation and error behavior left undocumented.

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 supplies a concrete example ('SE5560360793') that communicates the expected format (country prefix plus digits), which is real added value, but it gives no constraints on length, allowed country codes, or handling of lowercase/whitespace.

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 ('Verify one EU EORI ... number'), names the domain (EU EORI), and the word 'one' implicitly separates it from the sibling verify_eori_batch. An agent can route between singular and batch verification without opening either 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?

Usage is implied rather than stated: verifying a single EORI. There is no explicit when-to-use vs. when-not guidance, no mention of when to prefer verify_vat or verify_eori_batch, and no stated prerequisites (e.g., the input must already be an EORI, not a VAT number).

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. It usefully discloses the 100-item cap and the authoritative EOS source, but says nothing about authentication, rate limits, partial-failure behavior, or how invalid EORIs are handled. Return values are covered by the output schema, so that gap is excused.

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 front-loaded sentence that states the action, the limit, and the data source with no wasted words. Ideal density for a one-parameter tool.

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 batch verifier with an output schema, the description covers the essentials an agent needs: what is verified, the batch cap, and the source of truth. Only the failure/invalid-number semantics are absent, a minor gap given the low complexity.

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% for the single 'eoris' array parameter, so the description must compensate. 'up to 100 EU EORI numbers' clarifies both the element type (EORI numbers) and a maximum batch size the schema does not enforce via maxItems, adding real information beyond the schema.

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 verb (Verify), resource (EU EORI numbers), batch scope (up to 100 at once), and data source (official EOS). It implicitly distinguishes itself from the single-record verify_eori via 'batch'/'at once', but never names a sibling explicitly, leaving the batch-vs-single and EORI-vs-VAT routing to inference.

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?

Batch context is implied by 'up to 100 ... at once', so an agent can infer this is for multi-number checks. However, there is no explicit statement of when to prefer this over verify_eori or the generic verify_batch, and no exclusions or prerequisites 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 burden and does well: it discloses the return payload (valid/invalid, registered name and address, consultation number), the conditional nature of the consultation number ('when a requester VAT is given'), and special-case behavior for Hungarian numbers. It omits failure modes, rate limits, and VIES availability caveats.

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, no filler: identity and scope first, then return values, then the country-specific nuance. Every sentence adds a distinct piece of 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?

With no output schema and no annotations, the description usefully enumerates the response fields and the conditional requester behavior, which is what an agent needs to interpret results. Error handling and the undocumented requester default remain gaps, but the core contract is covered.

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: it gives format examples for 'vat' and explains that 'requester' unlocks the consultation number (audit proof). It never mentions the surprising schema default of 'HU33119856' for the optional requester field, leaving that ambiguity 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?

States a specific verb and resource ('Verify one EU VAT number') plus the authoritative source ('against official VIES'), with concrete example values. The word 'one' implicitly separates it from verify_batch, and 'VAT' separates it from verify_eori, so an agent can route correctly without opening any 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 singular scope ('one EU VAT number') clearly signals the single-lookup case versus the batch sibling, and naming VIES indicates the authoritative path for VAT validation. It stops short of an explicit 'use verify_batch instead for multiple numbers' statement or any exclusions.

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