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

With no annotations at all, the description must carry the behavioral load: it discloses the data source (Hyperliquid), the metric cadence (hourly funding), and the default ranking dimension, which is useful. It does not cover data freshness/latency, rate limits, or what happens when an unknown coin is requested — all relevant for a market-data tool with zero annotation coverage.

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?

Two sentences, no filler, with the source and coverage front-loaded before the use cases. The long comma-delimited field list is dense but each item is informative rather than padding.

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?

The output schema exists, so return values need not be described, and the description correctly focuses on scope and source. But with 3 undocumented parameters and no annotations, the definition is not quite complete: limit behavior, coin identifier format, and valid sort tokens remain ambiguous.

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 0%, so the description must compensate, and it does partially: it establishes that a coins selector exists and that ranking can be by open interest, funding, or volume — notably supplying the sort vocabulary that the unconstrained `sort` string lacks. It leaves `limit` (default 30) unexplained and doesn't specify the coins string format or the exact accepted sort tokens.

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 names a specific resource (perpetual futures on Hyperliquid) and enumerates the exact fields returned: hourly funding rate and APR, open interest, 24h volume, mark/oracle price, max leverage. It also states the two access modes (chosen coins vs. ranked list), which separates it from generic price tools like exchange_ticker or crypto_candles. It loses a point only because the retrieval verb is implied by the colon structure rather than stated.

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?

'Use for funding arbitrage, leverage sentiment and basis trades' gives real task-level context for selecting this tool. However, it never says when NOT to use it or names an alternative sibling (e.g., defi_lending_rates for lending APRs vs. perp funding), so the agent must infer boundaries from the sibling list alone.

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