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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered without help from the text. The description adds two pieces of non-annotated behavior: the requirement to preserve the facts and reference date, and the mandatory decrire_outil introspection step before invocation. It says nothing about NATINF lookup coverage or result shape, so it is useful but not rich.

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 text is short and front-loads the domain, but the final two sentences say the same thing twice — choose an operation and call decrire_outil with its name — so roughly a third of the description is redundant repetition that should be collapsed into one instruction.

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?

With no output schema, 0% parameter documentation, and a nested free-form arguments object gating four distinct operations, the description carries a heavy burden and discharges it by pointing at another tool. An agent still cannot tell what each operation consumes or produces without an extra round trip, which is a significant completeness gap for a multi-operation dispatcher.

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 parameters are non-trivial: an 'operation' enum of four values plus a free-form nested 'arguments' object with additionalProperties=true. The description never enumerates the operations or explains what arguments each expects, instead deferring entirely to decrire_outil, leaving the agent unable to construct a valid arguments payload from the definition alone.

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 is a noun-phrase list of subject matter ('Qualification pénale, nomenclature NATINF et peines encourues ou observées') rather than a verb+resource statement, so the agent must infer from the tool name that this is a read/exploration dispatcher. It is clear about the legal domain but does not say what the tool actually returns or does with those topics, and it does not distinguish itself from siblings like explorer_procedure_penale or explorer_methodes_et_actes.

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?

It gives a workflow rule — pick an operation, then call decrire_outil with that operation name to get its exact contract — which is genuine routing guidance. However, it gives no when-to-use vs. when-not guidance relative to the many sibling explorers, and no preconditions such as needing facts and a reference date before qualifying an offence.

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