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

Annotations only declare readOnlyHint and openWorldHint; the description adds material operational facts beyond them: data scope ('Hyperliquid public data only'), freshness window ('~3 min refresh'), a billing guarantee ('stale data never charged'), the payment rail and payer ('$0.008 USDC via x402 from YOUR wallet'), and a disclaimer. For a paid tool this is exactly the kind of cost/freshness disclosure an agent needs before invoking.

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?

Dense but front-loaded: the deliverable and its contents come first, then data freshness, then price/payment, then the disclaimer. Each clause carries information; 'Not financial advice' is boilerplate but short and conventional for a paid market-data tool.

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 must characterize the return value, and it does ('one compact JSON' covering funding extremes, whale positioning, liquidation clusters). The main remaining gap is the absence of any mention of symbol/asset scoping — it is unclear whether the brief covers all perps or a specific market — which matters for a market-data tool with no parameters to narrow scope.

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 description coverage is 100% for the single optional payment_signature parameter, and that schema text already explains the omit-to-receive-402 behavior. The description's 'via x402 from YOUR wallet' reinforces the payer identity but adds no syntax or format detail the schema lacks, so the baseline 3 applies.

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 composite deliverable ('one-call ... market brief') and enumerates its contents: funding extremes, whale positioning, liquidation clusters. This implicitly separates it from the sibling single-signal tools (hyperliquid_funding_extremes, hyperliquid_whale_positioning, hyperliquid_whale_liquidation_levels), though it never names them directly.

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 phrase 'one-call' implies this is the aggregated alternative to the three per-signal siblings, so the usage intent is inferable. However, there is no explicit when-to-use/when-not statement, no guidance on choosing this over hyperliquid_funding_extremes or the positioning tools, and no prerequisite framing beyond what the schema already says about payment_signature.

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