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

Goes well past the annotations by disclosing a polling cadence, the failure semantics (unknown coin → 400 with supported list, stale source → 503, neither billed), and the cost/payment model (0.004 USDC per call, x402, five chains). Annotations only cover read-only/idempotent safety; the billing and error behavior are pure added value an agent needs before calling.

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 the purpose, and the bundled-fields parenthetical, while long, is doing real work. It is a single dense paragraph though, and the cost/error details at the tail could be split out for faster scanning.

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 single-parameter paid composite endpoint, everything an agent needs is present: scope, coin universe, freshness guidance, cost, and both documented failure modes; return values are already covered by the output schema and annotations cover safety.

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 parameter already documents examples, so the baseline is 3; the description adds that the coin is not a fixed whitelist ('or any other Hyperliquid perp') and explains what happens with an unrecognized symbol. That meaningfully reduces wrong-input risk but stops short of format/symbol-syntax guidance beyond the examples.

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 concrete verb+resource ('Signal for one Hyperliquid perp') and then enumerates exactly what the payload contains (price changes, funding, OI, liquidations with z-score, whale positioning, cascade probability, liquidation clusters, top 3 whale positions). An agent can distinguish this composite 'everything for one coin' tool from siblings like get_signal_board, get_perp, or get_liq_heatmap without opening 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?

Gives a clear operating context ('for trading bots', 'Poll every 1-5 minutes') and an explicit input universe (BTC, ETH, SOL, HYPE or any other Hyperliquid perp). What it lacks is an explicit routing statement — it never says 'use this instead of get_signal_board / get_perp / get_hl_whales', leaving the sibling trade-off to inference.

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