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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so safety needs no restating. The description's real contribution is the mandatory two-step discovery protocol (decrire_outil before use), which is behavior an agent could not infer from the schema. It says nothing about what each operation returns, whether results are exhaustive, or how the arguments object must be shaped for a given operation.

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?

Short overall and the purpose sentence is front-loaded. But the second and third sentences say essentially the same thing (call decrire_outil with the chosen operation name before use), so one of three sentences is pure redundancy.

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?

This is a 13-way dispatcher with no output schema, no parameter documentation, and a free-form arguments bag. The description leaves the agent unable to choose an operation without first round-tripping through decrire_outil for each candidate, and gives no hint about what any of the fonds/couverture operations cover.

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%, and the description explains neither the 'operation' selector (13 enum values, undocumented) nor the free-form 'arguments' object. It only redirects the agent elsewhere (decrire_outil) rather than compensating, and it never notes that arguments must match the chosen operation's contract — a significant gap given additionalProperties:true on a nested object.

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 topic area ('état des fonds, couverture documentaire, actualisation des sources') but uses no verb and no explicit resource framing, so it reads as a subject label rather than an action. The operation enum supplies the real granularity, but nothing in the prose tells an agent what calling this tool actually produces. It is distinguishable from data-oriented siblings (jurisprudence, procedure_penale), but not sharply from explorer_sources_francaises or explorer_sources_officielles.

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 gives an in-tool workflow — pick an operation, then call decrire_outil with that operation name to get its exact contract — which is genuine procedural guidance. However, it never states when to choose this tool over the 13 sibling explorers, nor which of the 13 operations fits which question. Usage is implied rather than routed.

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