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

Annotations already declare readOnly, idempotent, non-destructive and openWorld, so the safety profile is covered. The description still adds real value by disclosing that this is a single-call aggregation of four otherwise separate lookups ('en un appel'). It does not say what happens when several input identifiers are supplied at once, which is the main behavioral unknown for a fan-out tool like this.

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?

Three short sentences, front-loaded with the priority instruction, no filler. The arrow chain 'toise_proprietaire → patrimoine → groupe → bodacc' is compact but mixes a full tool name with bare suffixes, which is slightly less crisp than naming the tools.

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?

An output schema exists, so return values need no explanation, and annotations cover safety. Against 11 parameters with none required, though, the definition never clarifies input precedence or the failure mode when no identifier is supplied, which is the main thing an agent needs before calling an aggregation tool.

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 only 27% across 11 parameters, so the schema does not carry the load. The phrase 'Entrée : adresse, parcelle, siren ou société' does map onto adresse, the parcelle fields, siren and denomination, which is meaningful compensation. However it says nothing about whether the inputs are alternatives or combinable, nor that zero parameters are strictly required, leaving the agent to guess the minimum viable call.

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 goal verb in substance ('savoir qui est derrière un bien et ce qu'il possède d'autre') plus the exact resources bundled: société, groupe, filiales, patrimoine, permis, BODACC. It explicitly positions itself against named siblings by saying it replaces the toise_proprietaire → patrimoine → groupe → bodacc chain.

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?

'À utiliser en priorité' gives an explicit precedence rule, and the replacement sentence tells the agent precisely which multi-tool chain this obsoletes. The only mild gap is that no 'when-not' case or prerequisite is given, but the routing guidance is otherwise unambiguous.

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