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

Annotations already declare readOnlyHint/destructiveHint=false and openWorldHint=true, and the description adds material context beyond them: x402 USDC billing at $0.002/call, a card-key (/credits) alternative, first 25 free, failed calls free, and an explicit explanation of why repeats are not free — which is exactly what makes idempotentHint=false intelligible. It also credits the upstream source (alternative.me) for the Fear & Greed data. Rate limits, latency and partial-failure behavior are the remaining gaps.

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 payload inventory is front-loaded in the first clause before pricing and use cases, and every section earns its place. Minor redundancy between "Cheaper than the five tools bought one by one" and the later per-call pricing sentence, and the sentence is long enough that the x402/credits detail runs on.

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?

With no output schema, the description carries the return-value burden and does so by enumerating each data block the caller gets back, plus the cost model and read-only guarantee. For a composite tool that fans out to several upstreams it is nearly complete; it stops short of saying what happens when one upstream (e.g. fee rates) is unavailable.

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% and the single parameter already documents the comma-separated format, the three-coin cap and the BTC,ETH,SOL default. The description only restates that with an example ("coins=BTC,ETH,SOL"), so it adds confirmation rather than new meaning — the baseline 3 for a fully described parameter set.

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?

"Market sentiment, prices and signals in one call" is followed by an explicit itemization of the payload: Fear & Greed with 7-day change, the 10 most traded Hyperliquid perpetuals with price/24h change/funding/open interest, RSI/MACD/moving averages for up to three coins, and BTC fee rates. This distinguishes it from single-purpose siblings like crypto_fear_greed, hyperliquid_indicators or btc_fees without the agent needing to open a 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 names concrete situations ("daily market brief, a trading agent's context or a dashboard") and states the economic rationale for choosing it over "the five tools bought one by one." What it omits is the inverse rule: if the agent only needs one signal, it should call the individual sibling, which is only weakly implied by the pricing comparison.

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