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

Annotations declare readOnlyHint=false, destructiveHint=false, openWorldHint=false; the description adds real context beyond that: strategies are not modified, capital/dates are ephemeral ('used for this run and not saved'), one backtest per strategy is consumed, and prior finished-month results are reused. It does not, however, address what the result looks like or any failure conditions.

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 the core action in the first sentence, with mechanics and defaults following. It is dense and long, and the parenthetical clauses about per-trade slicing add some drag, but every sentence carries operational 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 4-parameter, side-effecting run tool with no output schema and 75% schema coverage, the description covers mutation semantics, ephemerality, cost, and date defaults. The only gap is the shape of the returned 'combined result', which is left vague.

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 75%. The description adds genuine meaning beyond the schema: capital is the split pool, and start/end default to the first day all markets have data through the start of this month, plus a note that these values are not persisted. That defaulting behavior is not in the 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?

States a specific verb and resource ('Run every strategy in a portfolio... show the combined result') and defines the scope of the run. This cleanly separates it from run_backtest (single strategy) and optimize_portfolio without requiring the agent to open their schemas.

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 is implied by the mechanics described (running a whole portfolio as a combined simulation), but no sibling is named and there is no explicit when-to-use versus run_backtest, compare_backtests, or optimize_portfolio. The defaults for dates/capital are given, which helps selection but is not routing guidance.

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