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

With no annotations, the description carries the full burden and does disclose the non-obvious operational facts: a $0.01 USDC charge on Base, x402 payment passed in a params._meta key that is not declared in the schema, and the HTTP endpoint. It stops short of saying what 'best' selection logic is, the freshness/cadence of the data, or what happens on an unpaid call.

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 dense sentences, front-loaded with the capability before the commercial and transport details. Every clause carries information (coverage, price, payment mechanism, endpoint), though the coin list 'and more' is slightly wasteful.

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?

For a single-parameter tool with no annotations or output schema, the description covers cost, payment, and transport well, but leaves the central semantic gap: what 'best' means (best rate across venues? highest carry?) and what the response contains. An agent can invoke it, but cannot confidently predict or frame the result.

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% and the sole declared parameter (symbol) is already documented, so the baseline is 3. The description earns above baseline by surfacing a required-but-undeclared payment parameter (params._meta["x402/payment"]) that the schema does not mention at all — without that sentence an agent would fail its first paid call.

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 resource and what is returned: perpetual-futures funding rates plus annualized carry for BTC/ETH/SOL, sourced from exchange public market-data APIs in one call. The scope is clear, but nothing distinguishes it from close siblings such as funding_rates__rates, funding_rates__funding, or fundinglens__best — the word 'best' is never explained (best across exchanges? lowest rate?).

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 only implied: the agent can infer 'call this when you want funding rates for one asset', and the mention of a free /preflight sample hints at a trial path before paying. There is no explicit when-to-use versus funding_rates__batch/history or fundinglens__best, and no stated prerequisites beyond payment.

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