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

Annotations already declare readOnlyHint=true and openWorldHint=false. The description layers on real behavioral detail the annotations cannot: exact venues read per chain (Aave, HyperLend, Kamino, Morpho), that DefiLlama selects the largest market per chain and reports its size, and that DefiLlama only substitutes when a direct contract read fails. That fallback/provenance disclosure is valuable and does not contradict the closed-world annotation (the venue set is fixed).

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?

A single dense paragraph that front-loads what is compared before the caveat and then the data provenance. Every clause carries information, though the long parenthetical venue mapping makes it heavier to read than a short bulleted structure would.

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, yet the description conveys what the caller gets (a rate per chain plus market size) and where each number originates, including the degradation path. Only the exact response shape beyond that is left unspecified, which is a minor gap for a read-only comparison tool.

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% for the single index enum parameter, so the schema already documents it fully. The description adds only indirect meaning — that these markets are never index constituents, clarifying the filter means 'comparable to' rather than 'member of' — which is marginal beyond the schema wording.

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 a concrete resource (lending-market rates on Ethereum, Base, Hyperliquid, Solana plus SOFR, US repo, and BTC-collateral dollar borrow cost) and frames it as a comparison against Stacks rates, so an agent knows what data comes back. It does not, however, explicitly distinguish itself from the sibling compare_rate, which an agent would have to disambiguate by other means.

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 a clear interpretive constraint — 'Context only: none of these is ever a constituent of an SBOR index' — which tells the agent these numbers must not be used for index composition and pairs naturally with the index filter. No named alternative or when-not-to-call rule for the sibling compare_rate, but the usage context is unambiguous.

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