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

The annotations already declare readOnlyHint=false and destructiveHint=true, so the write nature is known. The description adds useful context beyond them: user confirmation is required, external calls execute directly under the apikey identity, and each run has a concrete credit cost (≈27 per 90d·1H). It stops short of explaining post-submission behavior (task ID, polling, or whether the task can be cancelled), so it is not a 5.

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 write-operation warning is front-loaded and the parameter notes are dense and useful, but the write-op status and external-execution identity are restated twice (at the start and at the end), and the cost parenthetical is awkwardly buried mid-sentence. The content mostly earns its place, but the duplication costs clarity.

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 6-parameter write tool with no output schema, it covers the required inputs, the timeframe values, the params-merge semantics, the cost, and the confirmation requirement. It does not explain what the call returns (a task or backtest ID) or how to fetch results afterward, which matters given that no output schema exists.

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 100%, so the baseline is 3. The description goes further by listing the timeframe values (1m/5m/15m/30m/1H/4H/1D) that the schema leaves as a free string, by explaining that a numeric strategy value is treated as an ID, and by specifying how params merge with # @param defaults and which source takes precedence.

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 states a specific verb and resource: submit a backtest task (提交回测任务), with the strategy input, symbol, and timeframe spelled out. This is enough to distinguish it from a list or history tool, but the description never names a sibling such as platform_backtest_result, platform_backtest_history, or platform_explain_backtest, so the boundaries remain implicit.

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 decision-relevant context: this is a write operation that requires user confirmation, and each run costs about 27 credits. However, it does not say when to choose this tool instead of platform_backtest_result (fetching results) or platform_explain_backtest (explaining results), so the agent must infer those relationships.

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