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

The annotations already establish read-only, idempotent, open-world, non-destructive behavior, so the description correctly focuses on additional context: paid x402 endpoint at $0.002, no charge for unknown symbols, HIP-3 symbol support, and that payment requirements and a URL are returned. It still does not describe the full payment flow or rate limits, but it adds meaningful behavioral detail beyond annotations.

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 description is dense but front-loads the payment cost and then enumerates the returned fields, symbol coverage, error behavior, x402 response, and sample URL. Every sentence contributes useful information, though the parenthetical funding breakdown is somewhat dense for a single-parameter 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?

There is no output schema, and the description compensates by listing the key returned metrics (funding intervals, annualized, next_funding_time, time_to_next_seconds, OI USD, 24h volume, mark/oracle, premium, top-10 flag). It also covers payment requirements and invalid-symbol behavior, leaving only minor gaps such as the exact error payload format.

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%, so the baseline is 3; the description adds useful meaning beyond the schema by noting that unknown symbols return an error and incur no charge, and that HIP-3 builder-dex symbols use the dex:TICKER form with rank null. The schema already documents the pattern and examples, so this is an incremental rather than essential addition.

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?

The description states a clear verb and resource: retrieve current metrics for one Hyperliquid perp, including funding, OI, volume, prices, and premium. It scopes the tool to a single symbol and supports HIP-3 builder dexes, but it does not explicitly differentiate this from siblings such as get_perps_context, get_extreme_funding, or get_oi_history.

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?

Usage is implied by the description: call this for a single perp's current metrics, and invalid symbols will error without charge. However, it gives no explicit when-to-use/when-not-to-use guidance or direct alternatives, so the agent must infer its role relative to the many perps and funding siblings.

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