backtest_strategy

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description does not need to cover safety. It adds useful behavioral context through constraints like the SMA200 warmup requirement and the optional include_trade_log/include_equity_curve flags. However, it does not disclose output format, failure modes, data range limitations, or performance characteristics beyond what the parameter list implies.

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 opens with a clear one-sentence purpose, then uses a structured Args block that is efficient for nine parameters. It is appropriately sized and front-loaded. Minor vagueness like 'institutional-grade metrics' is the only non-essential element, preventing a perfect score.

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?

The description thoroughly covers all input parameters and usage constraints, which is essential given 9 parameters and no output schema. However, since there is no output schema, the description should also explain what the backtest returns, such as the performance metrics included in the report, but it only vaguely references 'institutional-grade metrics' and optional trade log/equity curve flags.

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%, so the description carries the full burden for parameter meaning. It does this well: it gives valid examples for symbol, enumerates strategy names, defines period options, states defaults, explains commission/slippage as per-trade percentages, and specifies interval choices. It also adds the critical warmup-period constraint for two strategies. This fully compensates for the missing schema descriptions.

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 uses a specific verb and resource: 'Backtest a trading strategy on historical data' with 'institutional-grade metrics.' It clearly identifies what the tool does, but it does not distinguish itself from sibling tools like compare_strategies or walk_forward_backtest_strategy, so it falls short of a 5.

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 description provides implied usage guidance by listing allowed strategies, periods, intervals, and constraints such as 'rsi_pullback and triple_ema need period >= 1y for SMA200 warmup.' However, it does not explicitly state when to use this tool versus alternatives like compare_strategies or walk_forward_backtest_strategy, and gives no explicit when-not-to-use guidance.

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