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

Annotations only cover readOnlyHint and openWorldHint, so the description carries real extra weight: it discloses the data provider (DefiLlama), the billing model ($0.002 USDC per successful call via x402 on Base/Solana/Arc), and critically that failed calls are not charged. That charge/failure semantics is exactly the kind of behavior an agent needs before calling and is not derivable from structured fields.

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 with the core purpose and result shape, then mode behavior, then data source and billing. Dense but orderly. The 'Information only, not financial advice' sentence is boilerplate that does not help tool selection, a minor bit of padding.

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?

An output schema exists, so return details are largely covered, and the description still helpfully summarizes the payload. Pricing, provider and the chain/no-chain split are all present. The only real gap is sibling differentiation against defi_tvl and defi_stablecoins.

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 already 100%, so the baseline is 3, but the description adds meaning the schema does not: 'chain' switches the response shape (single row plus 1/7/30-day history) and the ordered-list semantics behind 'limit' (

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+resource (total value locked by chain from DefiLlama), the sort order (largest first), and the extra fields returned. However it never names or contrasts itself with the obvious siblings defi_tvl, defi_stablecoins or defi_dex_volume, so an agent must infer the boundary between chain-level and protocol-level TVL.

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 does explain the two modes: omit 'chain' to get the ranking, pass 'chain' to get that chain's row plus 1/7/30-day TVL change. That is useful contextual guidance, but there is no explicit when-to-use-this-instead statement relative to the many other defi_* tools, leaving the selection decision to inference.

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