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

Beyond the readOnly/idempotent annotations, the description discloses pricing ($0.005 per call in USDC on Solana via x402, or a free key) and the payment handshake — omitting payment returns the offer as error content and _meta['payment-required']. It also defines measurement semantics (a crossing is a first trade inside the band; peak is highest cap in the following 3h; USD valued at the trade hour's SOL price), which materially affects how results should be read.

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?

The core metric set is front-loaded in the first sentence, with cost and protocol details trailing where they belong. It is dense — several clauses chained with semicolons — but no sentence is filler.

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 5-param analytics query with no output schema, the description covers the metric definitions, the band-snapping behavior, the truncated-window caveat, and the payment flow. The return shape is only implied ('the answer says the band used'), which is the main remaining 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 coverage is 100%, so the baseline is 3; the description adds real meaning on top by defining what a 'crossing' is (and that a coin jumping the band in one trade has none), how USD conversion is done, and that the snapped band is echoed in the answer. It does not expand on the venue or payment parameters beyond 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?

The description names a concrete computation: counts of coins whose first trade fell in a market-cap band, how many then hit 2x/5x/10x/20x within 3h, and the median peak. That is specific verb+resource. It never names or contrasts a sibling tool, so it stops short of full sibling differentiation.

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 'For:' clause gives concrete motivating questions ("what are the odds a $20K coin does 10x, how often does it happen anyway"), which clearly signals the intended use. There is no explicit when-not guidance or pointer to an alternative tool for related questions.

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