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

Goes well beyond the annotations: discloses a deterministic seed derived from the trade fingerprint, a minimum of 10 trades, the returned artifacts (equity percentiles, input_scope, quota), a public rate limit of 8/day per client shared with play_public_round, and an explicit epistemic caveat that historical win frequency is not predictive. This quota-consumption context also explains why readOnlyHint=false despite the operation being a simulation.

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?

Three dense sentences that front-load the core operation (block bootstrap resampling) before secondary details like quota and the sibling equivalence. Every sentence carries substantive information, though the phrasing is packed and could be slightly easier 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?

An output schema exists, so return-value explanation is not strictly required, yet the description still names the percentiles/input_scope/quota returned. Combined with the trade-count precondition, determinism note, rate limit, and sibling equivalence, nothing an agent needs to call it correctly is missing.

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% for the single arenascript parameter, so the schema already carries the definition (20000-char limit). The description adds the 'minimum 10 trades' precondition, which is useful, but no format or syntax detail beyond the schema. Baseline 3 is appropriate when the schema does the heavy lifting.

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+resource: block bootstrap resampling of net-of-fee trades from a full backtest. It names the exact engine (Lab Rust engine), the minimum trade count, and explicitly equates itself to a named sibling (engine_robustness_check with holdout_percent=0), so an agent can distinguish it without opening any schema.

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?

It gives clear context for use (post-backtest resampling of an ArenaScript strategy) and names an alternative, engine_robustness_check(holdout_percent=0), stating the two produce exactly the same Monte Carlo. However, it never states when to prefer this tool over that sibling or when not to use it, leaving the choice to inference.

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