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

Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds valuable beyond-annotation context: per-venue unreachable/not-listed reporting (error behavior), the x402 payment mechanism and cost, and automatic payment by x402 clients. It doesn't mention rate limits or auth beyond payment, but the payment disclosure is the key behavioral trait for an agent.

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?

Front-loaded and information-dense, but the long run-on return-value list and the payment/sample sentences make it bulky. Much of the return enumeration would be better in an output schema (which is absent), so it earns its place, but the sentence structure is overloaded.

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?

No output schema exists, so the description must explain returns, and it does so thoroughly. It covers defaults, per-venue error reporting, payment, and a sample invocation. What's missing is a clearer statement of when to prefer it over crypto_prices or hyperliquid, and it lacks output field format details, but for a 2-param read tool it is largely complete.

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 50%: coins has a description in the schema but venues does not (though its enum values document it). The description states defaults (coins default BTC, ETH, SOL; venues default all), which adds meaning the schema lacks, but doesn't elaborate on the venue enum or the 10-coin cap beyond what schema maxItems shows. Baseline 3 due to partial coverage plus some added default info.

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 specific verb+resource (perpetual futures funding rates) and enumerates the exact venues (Binance, Bybit, OKX, Hyperliquid), clearly distinguishing it from siblings like crypto_prices or hyperliquid. It also lists precisely what is returned (APR, mark price, open interest, spread) so the agent knows exactly what data comes back.

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 description gives concrete usage context: defaults (BTC/ETH/SOL, all venues), a free sample input, and the cost mechanism. It implies when to use it (multi-venue funding comparison) but does not explicitly name when-not to use it or an alternative sibling (e.g., hyperliquid for single-venue). The free sample and defaults are strong practical guidance.

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