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.