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

Annotations cover the safety profile (readOnly, idempotent, non-destructive), and the description adds materially beyond them: this is a paid endpoint, it requires an x402 payment, and it returns payment requirements and a URL rather than the data itself. That non-obvious behavior is the most valuable sentence here. No cost, rate-limit or retry detail, so not a 5.

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 tightly packed sentences, front-loaded with the paid nature and the data payload, ending with the actionable payment instruction. No filler or redundancy.

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 does explain that the response contains x402 payment requirements and a URL rather than price data, which is important. But it omits the actual x402 flow — what the agent should do with the URL, whether the data arrives after payment, or the response shape — leaving a paid-tool interaction under-specified.

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?

The single 'symbol' parameter has an enum but 0% schema description coverage, so the description must compensate. 'For one coin' establishes cardinality but adds nothing about symbol syntax, case, or what values beyond the enum map to; the self-documenting enum keeps this at baseline 3.

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 specific verb and resource ('Coin lookup'), and enumerates the exact data returned (perp mark, funding, OI from Hyperliquid, OKX spot) for one coin. It is clear on its own, though it never differentiates itself from the sibling get_pricing, which an agent could easily confuse it with.

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 'Paid endpoint' framing implies the condition for choosing it — you need price data and are willing to pay via x402 — and 'pay with your own x402 client' tells the agent what is required. However, no alternative is named despite siblings like get_pricing and get_extreme_funding, and no when-not-to-use guidance is given.

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