backtest_strategy

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

With no annotations, the description carries the full burden of behavioral disclosure. It discloses the return metrics and optional outputs (trade log, equity curve), but it does not describe important behavioral traits such as data source reliability, potential look-ahead bias, execution assumptions, or the fact that no data is modified. It implies read-only behavior but does not state it explicitly.

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 well-structured with an Args section and a Returns section, using bullet points and bolded parameter names. It is longer than necessary but every line adds value, especially the strategy definitions. The purpose is front-loaded. It could be slightly more concise, but the structure aids readability.

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?

Given 9 parameters, no output schema, and no annotations, the description is quite complete. It covers all parameters, provides examples, and lists the returned metrics. However, it does not specify the exact structure or format of the trade log and equity curve, nor does it mention any limitations (e.g., data availability for certain symbols). This is a minor gap but not critical for a backtest tool.

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?

The input schema has no descriptions (0% coverage), so the description fully compensates by providing thorough explanations for all 9 parameters, including valid values (e.g., symbol examples like 'AAPL', 'BTC-USD'), strategy definitions with explanations, default values, and the effect of each parameter. This goes far beyond the schema.

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 clearly states the tool's purpose: 'Backtest a trading strategy on historical data with institutional-grade metrics.' It specifies the verb (Backtest), the resource (trading strategy), and the output (metrics). It distinguishes from sibling tools like compare_strategies and walk_forward_backtest_strategy by focusing on a single strategy backtest.

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 clear context about what the tool does and lists many strategies, but it does not explicitly state when to use this tool versus alternatives like compare_strategies or walk_forward_backtest_strategy. There are no usage exclusions or prerequisites, but the use case is implied through the description. No explicit 'when not to use' or 'use this instead' guidance is present.

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