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

With no annotations, the description carries the full burden and does so well: it discloses asynchronous queued execution and the {id, state: queued} response, the polling path, cost ($2/run, USDC on Solana over x402), failure handling (failed runs rerun free on the same id), and the simulation model (fill at the pool after latency_s, all fees and fixed costs deducted, bankroll ceilings, eight-week split). These are exactly the traits structured fields cannot convey.

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?

It is information-dense with little pure filler, but the run-on, metaphor-laden sentences ('every coin in the window counted including the dead ones') are not front-loaded and force re-reading; the operational payload (polling, price, async contract) is buried mid-paragraph rather than placed first.

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 queued job with no output schema, the description supplies the immediate return shape and redirects to replay_result for the actual results, and it covers payment, failure, and cost semantics. It is close to complete; the only gap is that the result payload itself is left entirely to the sibling tool with no hint of its shape.

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 100%, so per the baseline this scores 3. The prose restates the semantics of picks, latency, bankroll, exit, and payment at a high level ('Picks with timestamps and sizes in', 'filled at the pool as it stood after your latency') but adds no format, unit, or boundary detail beyond the schema — for example, the 500-item cap is only in the schema, not the description.

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 opening ('Your picks, replayed honestly' plus 'Picks with timestamps and sizes in; what they made, pick by pick and in sum') states a specific verb and resource: a backtest replay of user-supplied picks producing per-pick and aggregate P&L. It is recognizable, though the stylized phrasing means the agent has to parse a paragraph to extract a one-line purpose, and it never contrasts itself with base_rate, launch_record, or wallet_records.

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 explicit operational context: a run is a queued job returning {id, state: queued}, and the caller should 'poll replay_result with the id' — naming a sibling and the condition for using it. It also explains the payment precondition (leave payment out to receive the offer). No when-not-to-use guidance is provided, so it falls short of a 5.

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