tool_optimize_strategy

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

With no annotations provided, the description carries the behavioral burden. It discloses that the tool is asynchronous by returning an optimization_id and requiring polling via get_optimization_status. It also specifies ranking behavior and optional constraints, which helps the agent anticipate the operation's scope.

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 well-organized: a one-line purpose, then concise parameter documentation with bullets and an example, then the asynchronous workflow. Every sentence contributes necessary information, and the structure makes it easy for an agent to parse.

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?

The description covers the essential workflow, key parameter shapes, and the ranking metric options. It is somewhat incomplete on the structure of the strategy object and the expected date format, but the presence of an output schema and the clear async flow keep this from being a significant gap.

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 does so well for the most complex parameters, explaining param_ranges structure, constraint format with an example, and rank_by options. It does not document every remaining parameter such as strategy, date formats, commission, or initial_cash, but those are more self-explanatory from their names.

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 clear verb and object: 'Run a strategy optimization / parameter sweep.' It further clarifies by saying it tests multiple parameter combinations and ranks by a metric, which distinguishes it from the backtest siblings. The follow-up pointer to status/results tools completes the purpose picture.

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 makes the tool's role clear as a parameter-sweep operation, implicitly differentiating it from single-run backtests. It explicitly names the follow-up tools get_optimization_status and get_optimization_results, giving the agent a full workflow. It stops short of listing explicit when-not conditions or comparing against run_backtest, so it does not earn a 5.

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