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

Beyond the readOnly/destructive hints, the description discloses meaningful behavioral details: real charges and slippage, the honesty panel components, refusal thresholds, and that the OPEN STRATEGY form can simulate changing positions while a trade is live. It also addresses tiering ambiguity by stating that paid tiers only widen the date window. This substantially exceeds what the annotations alone provide.

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 front-loaded, opening with what the tool does and what it returns. The long list of capabilities is mostly justified by the tool's complexity, and each clause adds useful information. Still, the paragraph is quite dense and could be trimmed slightly without losing essential meaning.

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?

With no output schema present, the description wisely covers the return value: P&L after charges and slippage, return-on-margin, and the honesty panel. It also clarifies spec forms, refusal conditions, and tier behavior. It does not explain how `detail` or `lots` affect calls, but the schema covers those, and it doesn't connect to `get_backtest` for retrieving past results, so a small completeness gap remains.

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 67%, so the description shares the burden of explaining parameters. It adds high-level meaning for `spec` by explaining the preset vs. open-strategy split, strike selection modes (percent, points, premium, delta), and live-changing rules. However, it never names top-level parameters like `lots` or `detail`, leaving much of the detailed param semantics to the schema. This is adequate but not fully compensating.

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 an Indian index option strategy on real 1-minute NIFTY options data.' It also enumerates the return contents (P&L, return-on-margin, honesty panel), so the tool's purpose is unmistakable. However, it never explicitly contrasts this tool with siblings like get_backtest or build_report, so it stops short of full sibling differentiation.

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 gives clear in-tool guidance: use a PRESET for common shapes or an OPEN STRATEGY 'for anything else,' including concrete examples such as rolling a leg or adding a hedge. It also sets expectations about when it refuses to run (narrow windows, fewer than 30 trades) and how tiering works. It does not name sibling-tool alternatives explicitly, so it is not a perfect 5.

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