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

The description says the tool cancels (annule) a draft, i.e. removes/voids it, which is a state-changing operation. The annotations declare readOnlyHint=true ('does not modify its environment'), directly conflicting with a cancellation semantics. This is an annotation contradiction rather than useful added behavioral context.

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?

One short, front-loaded sentence with no filler or repetition. It is efficient, though its brevity is partly the reason for the missing usage and parameter context rather than a deliberate, complete rendering.

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 not be explained. But for a workflow tool in a family with confirmer_action/proposer_signalement, the description omits what happens on a confirmed action, error conditions, and reversibility, leaving real gaps for correct invocation.

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 never mentions action_id, so it adds no explicit parameter meaning. The single parameter name is largely self-explanatory given the tool acts on an action, which keeps this from being a low score, but the description still fails to compensate for the coverage gap (e.g. whether it must reference an existing draft).

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 and resource (annule un brouillon de signalement) and constrains scope to unconfirmed drafts, which implicitly separates it from confirmer_action. It never names a sibling tool explicitly, so an agent must infer the routing from the 'non confirme' qualifier.

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 phrase 'non confirme' functions as a usage precondition (only unconfirmed drafts can be cancelled), which is meaningful guidance. However, it gives no explicit when-not rule (e.g. what to do with a confirmed action, or which sibling to use instead), leaving the agent to infer the workflow relationship with confirmer_action and statut_actions.

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