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

Annotations already declare readOnly/openWorld/idempotent/non-destructive, so the description's job is to add operational context — and it does: per-call cost ($0.002/call), the conditional behavior that funding_history is only populated when exactly one symbol is requested, and the sortable dimensions. It stops short of describing pagination or defaults when no arguments are supplied, so it isn't exhaustive.

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 core routing and field list are front-loaded, but it's delivered as one dense run-on with parenthetical asides and a legal disclaimer ("Not affiliated with Coinbase or Deribit") that doesn't help an agent decide or invoke. The pricing line earns its place; the disclaimer and duplicated sort enumeration do not.

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 usefully documents the items[] return shape and the funding_history sub-object, and cost is disclosed. But for a four-parameter tool with no required args and thin schema coverage, the absence of any statement about defaults, limit/pagination, or min_volume_usd filtering leaves a real gap for correct invocation.

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 only 25%, so the description must carry parameter meaning, and it largely does not: it recites the sort enum values verbatim without explaining neg_funding, abs_funding, or gap, and never mentions limit or min_volume_usd at all. Only the single-symbol funding_history behavior adds real parameter-level meaning beyond the schema.

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 the exact resource and scope ("Every Deribit perpetual") and frames the venue (Coinbase Advanced international perps), enumerating the returned fields so the agent knows precisely what data class this supplies. It also explicitly differentiates itself from hl_basis and derivs_for for Hyperliquid-only queries, so selection is unambiguous without opening the 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?

It gives an explicit when-to-use clause ("Use for Deribit / Coinbase Advanced international perps ... funding, OI, premium, gap vs Hyperliquid") and an explicit when-not-to-use alternative ("for Hyperliquid only use derivs_for or hl_basis"). The routing decision is fully spelled out with named siblings.

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