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

Annotations already establish the safe-read profile (readOnly, idempotent, non-destructive), so the bar is lower. The description adds genuinely non-obvious behavior: each operation must preserve dates, documents, and hypotheses as traceability context, and each requires a prior contract lookup via decrire_outil. It does not describe what the computation returns, but adds meaningful process context beyond the annotations.

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 traceability instruction is front-loaded and useful, but the decrire_outil guidance is stated twice in near-identical sentences, wasting space that could have explained 'arguments'. Short overall, but redundancy costs it.

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?

Deferring to decrire_outil is a coherent design for a twelve-operation dispatcher, and no output schema exists so return values need no explanation. However, for a tool with an opaque required 'arguments' object, the description leaves the agent without enough to construct a call and relies entirely on a separate tool call.

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% with two parameters. The description mentions only the operation name; the nested 'arguments' object (additionalProperties: true, shape unknown) is never explained, and an agent gets no guidance on how to populate it or whether it is operation-specific. This is the largest gap given the free-form 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 first clause names concrete subject matter — legal calculations, statistical series, and compensation — which distinguishes it from the sibling explorer_* tools that fetch doctrine, case law, or sources. It does not enumerate the twelve operations, but the enum in the schema carries that detail. Purpose is clear at the 'calculation engine' level without sibling differentiation being explicit.

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 explicit workflow: pick an operation, then call decrire_outil with that operation's name to get its exact contract before invoking. That is real when-to-use guidance. It does not, however, say when to prefer this over the other explorer_* tools, and the guidance is repeated twice rather than expanded.

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