EU Counterparty Check (VIES + Peppol)

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

Annotations already declare readOnly/idempotent/openWorld/safe, so the bar is lower, yet the description adds real semantics: the three-valued vat.status and specifically that 'unavailable' is not 'invalid', and that peppol.listed:false means not-found-by-VAT in an opt-in index rather than proof of non-membership. Those are exactly the non-obvious behavioral traits an agent needs to interpret output correctly, plus a pointer to `sources` and a non-advice disclaimer.

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 value proposition is front-loaded, then each following sentence handles a distinct interpretation pitfall (status semantics, Peppol false-negative, sources, disclaimer) with no filler. Minor formatting quirks aside, 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?

An output schema exists, so return-value structure need not be described, and the description nonetheless covers the ambiguous output values and their limits. Combined with full schema coverage and annotations, an agent has everything needed to call and correctly interpret this tool.

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 100% and both parameters already document prefix/format handling and the GR/EL, XI country-code quirks, so the schema carries the parameter burden. The description adds no additional parameter meaning beyond naming that the VAT number drives both lookups, matching the baseline-3 expectation.

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 concrete verb+resource framing ('does this EU supplier exist and can I send it an e-invoice?') and names the two underlying operations it performs (validate_vat/VIES and Peppol Directory search by VAT number). This distinguishes it clearly from the siblings validate_vat and peppol_lookup, which each do only one of those halves.

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 'One call for ...' framing implicitly routes the agent here when it wants both checks at once rather than invoking validate_vat and peppol_lookup separately, and it explains the Peppol caveat that selects interpretation of the result. It does not, however, explicitly state when NOT to use it or name the alternatives as such.

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?

Annotations already cover safety (readOnly, idempotent, non-destructive, open world), but the description adds substantive behavioral traits beyond them: absence is not proof of non-membership, VAT queries have coverage limits, company names are returned only with legal-form marks (otherwise personal_data_omitted), contacts are never read, and the output is not legal/tax advice.

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 and every clause carries information (result interpretation, opt-in caveat, privacy behavior, disclaimer). The single dense paragraph is slightly heavy and could be split for scannability, but 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?

Even though an output schema exists, the description usefully summarizes the shape of `accepts` and the privacy marker, and it supplies the caveats an agent needs to avoid misreading a negative result. Nothing material is missing for correct invocation and interpretation.

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 100%, so the baseline is 3; the description earns an extra point because it adds real semantics to the query parameter by explaining that VAT-based queries only find companies that published a VAT, which is not visible in 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?

States a specific verb (searches) and resource (the Peppol Directory / OpenPeppol participants) plus the distinctive output (which document types each participant accepts). This clearly separates it from validate_vat and vies_country_status, which are VAT-status checks rather than directory/document-capability lookups.

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 strong interpretive context for when the result is meaningful: the directory is opt-in, VAT search only matches companies that published a VAT, and listing does not imply invoice reception. It does not explicitly route the agent to or away from the sibling tools, so it is clear context without named alternatives.

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?

Annotations already cover read-only, idempotent, open-world, and non-destructive behavior. The description adds substantial value beyond that: it explains the three possible status values, clarifies that `unavailable` does not mean invalid, describes when name and address are disclosed (legal-form marks) and when `personal_data_omitted` is true, notes that some countries never disclose them, and includes a legal disclaimer.

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 purpose, then efficiently layers in critical output semantics and caveats without wasted words. Every sentence contributes necessary context for interpreting the tool's results.

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 existence of an output schema and rich annotations, the description need not explain return formatting. It nevertheless completes the picture by explaining status semantics, data omission rules, country-specific disclosure behavior, and a legal caveat, leaving no major behavioral ambiguity for an agent.

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 100%, and both parameters have detailed schema descriptions covering format, prefix handling, and country code specifics. The description does not add any parameter-level meaning beyond what the schema already provides, so the baseline of 3 applies.

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: checks an EU VAT number in the European Commission's VIES. It is clear what the tool does, but it does not explicitly distinguish itself from sibling tools like check_eu_counterparty, peppol_lookup, or vies_country_status.

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 gives no explicit when-to-use guidance, no prerequisites, and no comparison to alternative tools. It only implies usage through its stated purpose, leaving an agent to infer when this tool is appropriate versus its siblings.

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?

Annotations already declare readOnly, idempotent, open-world, and non-destructive, so the safety profile is covered. The description adds real value beyond them: it is a 'live snapshot, not a history' and disclaims legal/tax applicability. It omits any note on caching, freshness windows, or rate limits, which keeps it short of a 5.

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 tight sentences, front-loaded with what it reports, then the routing hint, then scope caveats. Every sentence carries distinct information 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?

An output schema exists, so return values need not be described. For a zero-parameter read-only status probe, the description covers purpose, routing, scope limits, and the nature of the snapshot (live, not historical) — everything an agent 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. No parameter-related claims are made or needed.

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 ('Reports whether... VIES... is answering right now') and clarifies the scope of the resource by including each member state's national system behind it. It explicitly distinguishes itself from validate_vat by noting it 'says nothing about any specific VAT number', so an agent can separate it from the sibling that does per-number validation 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?

Gives an explicit trigger ('Use it to explain a `validate_vat` result of `unavailable`') naming the exact sibling and condition, plus an exclusion (it says nothing about any specific VAT number). This is textbook when-to-use/when-not routing.

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