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

Annotations already indicate a read-only, idempotent, non-destructive operation, but the description adds crucial behavioral detail: it removes lines rejected by the engine's preflight and lists each removal; 'valid' comes only from the engine; and if no executable condition remains it returns ok=false instead of inventing a strategy. It doesn't mention whether the repair is logged elsewhere or if the input is modified in place (though readOnlyHint covers non-mutation).

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 description is compact and front-loads the main action and scope. However, the sentence structure is dense with nested clauses, and some phrases ('chaque retrait est listé') could be clearer if placed earlier. Still, there is no extraneous information.

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 the description references 'ok=false' and 'valid', which align with the output. For a one-parameter repair tool with annotations, it provides sufficient context on behavior and failure mode, though it doesn't detail what the repair may fail to fix or any limits beyond the engine's refusal.

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 coverage is 100% and the single parameter is documented (max 20,000 characters). The description adds context about the input being a 'pseudo-ArenaScript' script and that it must contain conditions, but does not elaborate on syntax, expected format, or examples beyond what the schema states.

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 clear verb ('Répare', corrects) and resource ('pseudo-ArenaScript'), with the scope defined as mechanical corrections and removal of engine-rejected sections. It distinguishes itself from the sibling validate_arenascript by implying it fixes rather than just checks, though it doesn't name that sibling explicitly.

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 usage context is implied (feed a pseudo-script to repair it before the engine can use it), and it explains what happens if nothing executable remains. However, it does not explicitly say when to use this instead of validate_arenascript, generate_arenascript_strategy, or backtest_arenascript, leaving the agent to infer the workflow.

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