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

Annotations only declare readOnlyHint, so the description carries most of the load and does: it discloses the hard 30-round-trip sample gate, next-bar-open re-pricing, closed-trade drawdown basis, the absence of multiple-testing correction, default cost assumptions, and the API Pro tier requirement. All of that is behavior an agent cannot infer from the schema.

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?

Front-loaded with the core question and the verdict semantics, then the caveats. It is dense and parenthetical-heavy (fill_rule, max_drawdown_basis, verdict_reason field names interleaved), which costs some scanability, but nearly every clause carries decision-relevant 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?

No output schema exists, and the description compensates fully by explaining the verdict enum, metrics/flags/caveats, verdict_reason {code, have, need}, to_change semantics, below_buyhold, and oos_usage. For a nested five-parameter validation tool, an agent has enough to call it and interpret the result.

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%, so baseline is 3, but the description adds real semantics: what each strategy type means in practice, how signals/trades are re-priced, and that oos_usage reports whether the split deviates from defaults. It stops short of explaining every param (e.g. no guidance on sensible window lengths or split_frac trade-offs), so not a 5.

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?

States a concrete operation (honest, look-ahead-aware backtest of a strategy or signal list) and its output shape (an EVIDENCE verdict, not a buy/sell call). It also explicitly separates itself from generic backtest tools ('not reproducible via generic backtest tools that ignore overfitting') and from arena_run_backtest's drawdown basis, so an agent can tell the siblings apart.

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?

'Call this before acting on a strategy or signal list' gives an explicit trigger, and the description names the three accepted input shapes (rules / signal_list / trade_list) so the agent knows which entry path applies. The exclusion 'NOT a buy/sell recommendation' and the warning about generic backtest tools give clear when-not guidance.

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