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.