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

Beyond the readOnlyHint and openWorldHint annotations, the description adds genuinely useful behavioral context: the BODACC data source, output grouping and recency ordering, and the cost model ('Paid via x402 ($0.01 in USDC or EURC)'). The payment disclosure is valuable because it signals the tool will not return data without a payment step. There is no annotation contradiction — payment is not a data mutation. The two-path payment behavior (x402 vs prepaid credits) is left to the schema, which slightly caps this dimension.

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 sentences, each earning its place: the first covers resource, source, content types, and ordering; the second covers cost and payment rail. The description is front-loaded with the core function and contains zero 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?

Given the presence of an output schema, 100% parameter coverage, and read-only annotations, the description covers the essential ground: source, content, ordering, and payment. The main missing piece is sibling disambiguation within a 65-tool set containing several near-overlaps, and executing the payment flow correctly requires the agent to read the x_payment/api_key schema notes. Mostly complete, but not maximally helpful.

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 of 3 applies: siren, api_key, and x_payment are each fully documented with format, purpose, and behavioral notes (e.g., 'Omit to receive the payment quote', 'Ignored when x_payment is provided'). The description's payment sentence adds marginal context for why x_payment or api_key is needed but contributes no parameter-level detail 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 resource type (legal alerts and legal notices for a French company), the authoritative source (BODACC), enumerates the content categories (insolvency proceedings, court filings, deregistrations, business sales), and states the ordering (grouped, most recent first). It is clearly about a specific thing, but it does not explicitly differentiate from overlapping siblings such as check_french_regulator_alerts or search_bodacc_announcements, so it stops short of a 5.

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 content enumeration implies a use case: any request for French insolvency proceedings, court filings, deregistrations, or business sales would route here. However, the description neither names alternatives nor gives exclusion criteria, and with several near-overlapping siblings (check_french_regulator_alerts, search_bodacc_announcements, get_french_company_changes), an agent receives no explicit routing help. This is implied usage at best.

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