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

Annotations only declare readOnlyHint and openWorldHint, so the description carries real added weight: it states the cost ($0.003 USDC per call over x402), that failed calls are free, and the two-step payment flow (call without `payment` to get a quote, then sign and call again). That is substantive auth/cost context an agent needs before invoking. It stops short of describing latency, caching, or partial-failure behavior, so it is strong rather than exhaustive.

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?

Usage and alternative routing are well front-loaded, but the payload contents are enumerated twice — once in the opening sentence and again in the 'Returns:' sentence — which is pure duplication. The cost and payment details are the only novel content in the middle block; trimming the repetition would make this much tighter.

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?

There is no output schema, so the description is right to enumerate the returned fields in detail, and it does so thoroughly enough for an agent to know what it will get. The payment prerequisite and its quote-first workflow are also covered. The only gap is that quantities/shape of the aggregates (e.g. how many gainers/losers, formatting of the index) are unspecified.

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?

There is a single optional parameter with 100% schema description coverage, so the baseline is 3. The description reinforces the quote/payment workflow already documented in the schema, but adds no syntax or format detail beyond it. The line 'Takes no parameters' is a slight overstatement given the optional `payment` field, though it is defensible as 'no required 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?

Names a specific verb ('Get') and an enumerated resource (Fear & Greed, BTC/ETH/SOL perp data, funding extremes, gainers/losers, Hyperliquid totals) rather than a vague 'market data'. It also explicitly distinguishes itself from siblings by naming perps_market and crypto_news as the alternatives for narrower or adjacent needs.

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?

Contains an explicit 'When to use' clause ('you want the state of the crypto market in one call, for example before deciding anything else') and an explicit 'Use instead' clause routing to perps_market for specific coins/more markets and crypto_news for headlines. Both the selection condition and the alternatives are stated, leaving nothing to inference.

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