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

No annotations are provided, so the description carries the full load, and it does well: it discloses the paywall ($0.01/call, USDC on Base eip155:8453), the x402 payment mechanism via params._meta['x402/payment'], and the HTTP GET endpoint. These are exactly the non-obvious traits an agent needs before invoking. It omits return shape and whether the call is read-only, but read-only is evident from 'public market-data APIs'.

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?

Three dense sentences that front-load the purpose before the pricing and payment mechanics—every element earns its place for correct invocation. Slightly packed, but no filler.

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 and no annotations, the description must convey the essentials, and it covers the critical payment/auth path fully. It leaves the 'batch' scope and the return format unexplained, but for a one-param paid read that is a minor gap.

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 single 'symbol' param is documented ('Asset symbol, e.g. BTC'). The description's 'BTC, ETH, SOL and more' hints at coverage breadth but adds no syntax or format detail beyond the schema. Baseline 3 is appropriate when the schema does the work.

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 (perpetual-futures funding rates and annualized carry) and source (exchange public market-data APIs), so the agent knows what it returns. However, it never distinguishes itself from the six sibling tools in the funding/fundinglens family (rates, funding, best, history), and 'batch' is confusing since the schema takes a single symbol. Clear purpose but no sibling differentiation.

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?

No guidance on when to use this versus funding_rates__rates, funding_rates__funding, funding_rates__best, or the fundinglens equivalents. The only implied usage is the 'batch' in the name, which the single-symbol schema contradicts. The agent must guess the routing.

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