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

Annotations already disclose readOnlyHint=false, destructiveHint=false, idempotentHint=false and openWorldHint=false, so the safety profile is covered structurally. The description adds genuinely useful behavioral detail beyond that: 10 bps fees per side, deterministic Monte Carlo with a seed derived from the trade fingerprint, resampling to the declared timeframe, and a separate public quota pool of 8 per day per client. It also states explicit failure when the engine refuses or is unavailable. However, the meaning of 'sealed:false, is_keep:false, paper:true' is never explained, so part of the behavioral framing remains opaque.

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 most decision-relevant sentence ('Not a verdict; for a verdict use get_lab_desktop_handoff') is buried behind an unexplained jargon prefix, so it is not well front-loaded. The body is information-dense with little filler, but the French/English mixing and the parenthetical key:value fragments make it harder to parse than its length warrants.

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?

For a compute-heavy tool with an output schema, annotations, and a quota, the description covers cost (8/day quota), determinism, failure behavior, and the data source. An agent can decide and call correctly. The unexplained 'sealed/is_keep/paper' flags and the lack of any hint about runtime or input script constraints are the remaining gaps.

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 only 50%, but the description compensates: it explains that holdout_percent accepts 10 to 40, or 0 for no holdout, and what 0 implies (Monte Carlo becomes identical to monte_carlo). That is real semantic content missing from the schema. The arenascript parameter is only implicitly characterized (a script executed by the Rust engine), relying on the schema's own description for the 20,000-character limit.

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 concretely states what is computed: a backtest, a chronological holdout, and a Monte Carlo run executed by the Lab's Rust engine on server OHLCV candles. It also explicitly distinguishes itself from the verdict tool (get_lab_desktop_handoff) and from a KEEP decision. The opening string 'PAPER PREVIEW (sealed:false, is_keep:false, paper:true)' is internal jargon that obscures rather than clarifies the purpose.

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 an explicit routing rule: 'Not a verdict; for a verdict use get_lab_desktop_handoff', and reiterates 'Descriptif, pas un KEEP'. That names the alternative and the condition that selects it. It does not cover when to prefer monte_carlo or backtest_arenascript, which are the closest siblings for the individual components.

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