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

readOnlyHint=true is consistent with a pure simulation, but the description adds nothing beyond it: it does not say whether the run is deterministic, how expensive it is, what is returned (equity curve, fills, balances?), or that missing or forward references to series and signal ids will fail. For a tool whose surface is a complete strategy DSL, this leaves nearly all behavior undisclosed.

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?

Both sentences are front-loaded and free of filler, so nothing is wasted. However, two sentences is under-sized for a parameter object this deep, so the brevity reads as omission rather than discipline.

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?

No output schema exists, so the description should explain what a run resolves to, yet it does not. Given the extreme nesting and zero parameter documentation, the definition does not provide enough for an agent to construct a valid run form without reading the raw schema end to end.

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%, and the single parameter is a deeply nested run object containing series, signals, simulation, positions, and sleeves. "Needs the full run form" conveys only that the whole object is mandatory, giving no meaning for the id-reference graph, the version const, or the fillTiming/feeBps/slippageBps fields that drive results.

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?

"Simulate historical fills and account balances" gives a concrete verb plus two concrete resources, so the agent knows this is a backtest engine rather than a data fetch. It never distinguishes itself from siblings such as report, save_strategy, or build_signal, so the agent must guess which of them to chain with it.

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 only guidance is the second sentence, "Needs the full run form," which states a requirement rather than a use case. There is no statement of when to choose simulate over report or get_prices, and no mention of prerequisites such as building series and signals by id first.

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