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

Goes well beyond the annotations: names the upstream sources and the Coinbase→CoinGecko fallback with a source field, discloses the ~1 min data refresh, that labels are fixed rules rather than forecasts, that errors are free on Base, the $0.002 x402/USDC-on-Base cost, and links buyer terms. The read-only/open-world hints are supplemented with exactly the operational and billing context an agent needs before spending money.

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 correctly with what it does and the returned fields, which is the right order. The tail is bloated and parenthetical ('Errors are not charged on Base (other rails may charge)... USDC on Base (MCP payments are Base only)') repeating rail/cost constraints twice and bolting a terms URL into the same sentence.

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 zero-parameter, no-output-schema tool, the description carries the return shape (field-by-field), freshness, cost and provenance, which is close to everything an agent needs. The one hole is that its documented single-coin mode has no matching schema entry, leaving the agent unsure whether symbol is real.

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?

The schema declares zero properties, yet the description instructs 'or one coin via symbol= (bad symbol: 400)'. That references a parameter that cannot be passed, so an agent following the description would emit an invalid call. The return-field list (priceUsd, change24hPct, momentum, sentiment, direction) is genuinely useful since there is no output schema, but the phantom input parameter is a real defect rather than a baseline-4 no-param case.

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?

Opens with a concrete verb+resource: a current USD price snapshot for BTC, ETH and SOL, and states the use case ('quick market context'). It does not name or exclude any sibling (market_quote, tokenized_stock, signals), so an agent cannot tell from this text alone which price tool to prefer, which keeps it below a 5.

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 utility-level guidance ('for quick market context', a ~1 minute refresh so repeat calls are wasted, and the 400 behavior for a bad symbol), which is more than nothing. However, it never states when to use this over the price-adjacent siblings, and the one single-coin instruction it offers points at a parameter that does not exist.

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