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

Annotations already mark the tool as read-only, idempotent, and non-destructive. The description adds valuable context: it emphasizes the tool outputs historical data, not predictions; explains the first-touch TP1 frame; and clarifies that timeout anchors are excluded from probability calculations. This goes beyond the annotations to describe edge case handling and the nature of results.

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 5 sentences, front-loaded with the core purpose. It uses caps for emphasis ('DATA', 'NOT') which is slightly informal but not detrimental. The route hint is included but not essential. It could be trimmed slightly, but overall it's efficient and well-structured.

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 the presence of an output schema (so return values need not be explained), the description covers key aspects: the historical frame, live gating, low-sample behavior, and timeout handling. It does not mention error conditions or symbol validation, but these are partially covered by the schema descriptions. Considering tool complexity, it is fairly complete.

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?

All 6 parameters have schema descriptions, but the description adds critical context beyond them: it explains that direction is inferred from tp/sl relative to entry, that tp can be an ordered list, and that max_hold_min clamping excludes timeouts from probability. This enriches the agent's understanding of how parameters interact and affect results.

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 replays a trading setup over historical candle data to compute P(TP1 before SL) and EV. The title reinforces this by labeling it 'Backtest a setup' and specifying the output metrics. It distinguishes from sibling tools like 'calc_ev' and 'get_accuracy' by focusing on historical replay rather than real-time or aggregated metrics.

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 labels the tool as 'LAB / RESEARCH', signaling experimental use, and warns that live results are gated behind a feature flag. It also notes that low-sample setups return a directional band instead of an error. However, it does not explicitly compare to sibling tools like 'calc_ev' or 'get_accuracy', leaving the agent to infer when to use this rather than those. Slight markdown for lacking explicit alternatives.

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