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

Annotations only declare readOnly/openWorld/idempotent; the description adds substantial context the annotations cannot: price ($0.009 USDC via x402), the exact payment choreography (402 challenge, template, PAYMENT-SIGNATURE header), that failures after payment settle nothing, and the simulation mechanics (signals at close executed at next close, no look-ahead, feeBps per trade, long-or-flat only). The purchasing flow is fully disclosed without contradicting readOnlyHint, since no market state is mutated.

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 payment model and purpose, and every clause carries information the schema does not. It is long and somewhat list-dense, and the strategy enumeration is repeated verbatim from the schema's enum description, which is mild redundancy rather than a real defect.

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 12-parameter, zero-required, paid, output-schema-backed tool, everything an agent needs is present: cost, payment handshake, error/charging semantics, defaults, and window bounds. Return values are summarized but the output schema exists, so that redundancy does not create a 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 100%, so the baseline is 3, and the description largely mirrors the schema's strategy explanations. It adds one genuinely new composition the schema lacks: the empty-body default bundle (BTC, SMA 20/50, 180 days), plus execution semantics ('signals formed at one close are executed at the next') that give meaning to the strategy parameters.

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 — backtest a stated trading rule on a crypto asset's daily USD closes from Coinbase Exchange — and names the comparison baseline (buy-and-hold over the same window). This clearly separates it from price/report siblings like token_price or token_report, which return data rather than simulate a rule.

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?

Gives explicit entry conditions: an empty body tests BTC with SMA 20/50 over 180 days, the window is constrained to 30-365 days, and a ticker without a Coinbase USD market returns an uncharged 404. It does not name alternative sibling tools for related questions, so it stops just short of full when/when-not routing guidance.

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