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

The description goes well beyond annotations by disclosing that source records are not modified, that successful calls consume an x402 payment, that the payment-required challenge is free, and that repeated calls may require a new payment. It also notes source-driven data limitations such as missing or incomplete person/role fields. This aligns with annotations rather than contradicting them.

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 well-structured with clear sections: purpose, use when, avoid when, limitations, price, paid-call behavior, and accepted networks. It is somewhat verbose, but every section carries useful decision-making or side-effect information, and the core purpose is front-loaded.

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 one-parameter paid tool with an output schema, the description covers purpose, usage boundaries, limitations, payment side effects, idempotency nuance, and accepted networks. An agent has everything needed to select the tool and understand the consequences of calling 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 schema already fully documents the only parameter, identifier, with a pattern and a description of '9-digit SIREN or 14-digit SIRET'. The tool description merely restates SIREN/SIRET as the input source and adds no new parameter-level meaning, so the baseline 3 for high schema coverage 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 opening sentence clearly states what the tool does: returns publicly listed directors and legal representatives for a French company from a SIREN or SIRET. It also distinguishes itself from ownership-related endpoints via the 'Avoid when' note, though it does not explicitly name a sibling alternative like company_fr_director_mandates.

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 provides explicit 'Use when' and 'Avoid when' conditions, including exclusions for beneficial owners, shareholder ownership, and personal contact details. It does not name alternative sibling tools, so the routing guidance is strong but not fully explicit about the alternative to pick.

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