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

Beyond the single destructiveHint annotation, the description discloses that the operation is asynchronous and returns immediately with an id, that it consumes material runtime capacity, that it does not create plan items, what the structured result contains, and how three distinct error classes (DATA_ACCESS_REQUIRED, DATA_PROVIDER_UNAVAILABLE, OPTIONS_DATA_SOURCE_REQUIRED) should be surfaced to the user without retrying or switching providers. This is substantially more than the annotation conveys, with no contradiction of destructiveHint.

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?

Front-loaded with purpose and async behavior, then organized under explicit IMPORTANT headings for error handling, so scanning works. It is verbose in places — provider routing is explained twice (once inline, once under the error sections) and the 'explain/offer/ask' instructions are wordy — but nearly every sentence carries operational value for a high-stakes async job.

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 complex, expensive, async tool with 8 parameters and no output schema, the description covers launch semantics, the shape of the structured result, prerequisite discovery, secret handling, provider resolution, and recovery paths for each error class. An agent has enough to call it correctly and to handle failures without guessing.

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 63%, but the description compensates thoroughly: it explains budget semantics (sets BACKTESTING_BUDGET so no code changes are needed), how envVarSetIds must be pre-created via saved_env_vars rather than passing raw secrets, that parameters become an immutable reusable parameter set, the exact-revision constraint on strategyParameterSetId, and the client-dependent behavior of dataProvider. It also clarifies that revisionId must come from the most recent successful file mutation, including the supersession rule.

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?

Opening sentence gives a specific verb+resource ('Start a new backtest for a revision with the provided date range') and immediately distinguishes itself from siblings by naming `backtest_status`, artifact tools, and `list_backtests` as the consumers/producers of the returned id. An agent can tell exactly what this does versus `stop_backtest`, `list_backtests`, or `start_parameter_experiment`.

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?

Explicit guidance on when to call it ('follow the user's instructions about whether to start one'), what to do when prerequisites are missing (call `list_backtests` for revisionId), and when not to call related tools ('do not call set_data_provider merely to reselect the default', 'do not call either tool to probe a provider already declared OFF'). It also routes provider changes to the correct alternative per client type, which is exactly the alternatives guidance this dimension rewards.

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