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

Annotations are sparse (readOnlyHint=false, idempotentHint=false, destructiveHint=false), so the description carries the burden. It discloses that succession links are declaration-based and may be incomplete per INSEE, that cursors are direction-specific and must not be reused across SIRETs/directions, and that paid calls consume x402 payment while the challenge is free. This is meaningful behavioral context beyond the annotations. It doesn't fully describe what happens on repeated calls, but the paid-call behavior is well covered.

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 (Use when, Avoid when, Limitations, Price, Paid-call behavior, Accepted networks). It is slightly long but every section earns its place, and the core purpose is front-loaded in the first sentence.

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?

The description covers purpose, usage, limitations, pricing, payment behavior, and network constraints. With an output schema present, return values don't need to be described. The only minor gap is that it doesn't explicitly state what happens if the SIRET has no successions, but the limitations section already sets expectations about data completeness.

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 schema already documents all four parameters. The description adds context about cursor direction-specificity and the declaration-based limitation, but it doesn't add much per-parameter meaning beyond the schema. Baseline 3 is appropriate.

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 ('Returns'), a precise resource ('official Sirene predecessor and successor links for a French establishment'), and the key data fields (effective date, headquarters-transfer flag, economic-continuity flag). It clearly distinguishes this from the sibling company_fr_establishments by naming what it is not.

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 explicitly says 'Use when: You need official predecessor or successor establishment links for a French SIRET' and 'Avoid when: You only need the current establishments of a company; use company/fr/establishments.' This gives the agent a clear decision rule and names the alternative tool.

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