backtest_forecast

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

No annotations are provided, so the description carries the full burden. It discloses that the tool performs multiple model fits, has a 10000-point result cap with truncation, reports MAPE=null for near-zero actuals, and appends a limitations disclaimer. It also reveals internal details like _prepare_series and leakage prevention. This is exceptional transparency.

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 long but densely packed with valuable information, organized with clear headers (参数, 门槛链, 指标, 局限声明, 示例). It front-loads the core purpose before diving into details. Some redundancy exists (e.g., E1001 mentioned twice), and the docstring maintenance note is meta-information that could be trimmed, but every section earns its place.

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 7 parameters, no output schema, no annotations, and a complex statistical tool, this description covers validation rules, output metrics, error codes, edge cases, and usage examples. It even addresses potential concerns like computational cost and data leakage. This is as complete as a text description can reasonably be.

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 description coverage is 0%, so the description must compensate. It explains each parameter with types, defaults, constraints, and semantic alignment with time_series_forecast. For method, it enumerates all three options and their behaviors. The only minor gap is that inline_data's exact shape is deferred to SPEC.md, but the description gives enough context to use it.

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 begins with a clear statement: '时序组 · 滚动回测' and immediately explains it is a rolling-window backtest for time_series_forecast, computing MAE/RMSE/MAPE. It distinguishes itself from the sibling time_series_forecast by emphasizing it provides '历史表现' credibility. The purpose is specific and unmistakable.

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 explicitly states this tool is for validating time_series_forecast, and notes it shares preprocessing with forecast. It provides parameter constraints, validation thresholds (E1010, E1005), and even notes inline_data is an alternative to file_path. It gives explicit examples and explains fallback behavior for seasonal_naive. This is comprehensive usage guidance.

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