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

Beyond the annotations (idempotentHint, readOnlyHint=false) it discloses execution semantics an agent could not infer: app sandbox validation, supported market/timeframe/date rules, 10,000 simulated capital, zero fees, zero slippage, next-bar-open fills, and the idempotent-recovery mechanism (identical request_key and inputs). It also explains what comes back and how to proceed (run ids plus poll_after_seconds).

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?

Purpose and baseline behavior are front-loaded, and the simulation assumptions are packed efficiently into one sentence. The final sentence on the acceptance receipt and poll interval is somewhat long and slightly overlaps the output schema, but most sentences carry distinct 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?

For a mutation tool with an output schema, the description covers the execution model, constraints, idempotency and next-step polling well. Remaining gaps – optionality of end_date, failure/validation-error behavior, and the exact meaning of strategy_id – are minor given the output schema documents the response.

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 only 20% (just request_key), so the description must carry most parameter meaning. It usefully clarifies that revision must be the exact saved revision and that request_key plus identical inputs drive idempotency, but strategy_id, start_date and the optionality/behavior of end_date are left to the bare 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 opens with a specific verb and resource: 'Queue a backtest of any saved strategy ... and a matched buy-and-hold baseline.' It scopes the operation precisely (saved or existing app strategies, custom code) and its output (acceptance receipt with run ids), letting an agent distinguish it from retrieval siblings like get_run_report or get_run_data without inspecting either schema.

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?

Usage context is clear: any saved strategy in the connected workspace, custom code or existing app strategies, with the exact saved revision required. It also flags a boundary versus an alternative surface ('No plugin-only daily test or history caps'), but it never names a sibling tool or states an explicit when-not/fallback condition.

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