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

With no annotations supplied, the description carries the full burden and does well on the commercial/operational side: it declares the tool is paid, prices it at $0.002 USDC, names the accepted payment chains (Base, Solana), states no account or API key is needed, and that failed calls are not charged. It says nothing about rate limits, pagination behavior, or the response shape, which keeps it below a 5.

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 most decision-relevant token ("Paid."), then scope, then cost/auth terms, then the endpoint URL. Every clause carries information, though the telegraphic fragments and trailing URL make it slightly less readable than a single well-formed sentence would be.

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 zero-required-parameter read tool with no output schema and no annotations, the description covers what an agent needs to decide and pay: data source (DefiLlama), covered metrics, price, payment rails, and auth-free access. Return structure and failure modes beyond billing are not described, but the listed metrics cover the essentials.

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 description coverage is 100%, so sort, limit, and min_tvl_usd are already documented with defaults and value ranges in the schema. The description adds no parameter-level meaning beyond listing the returned metrics (APY, TVL, 7d APY change), which only loosely hints at the sort values. Baseline 3 is appropriate.

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?

"Live DeFi yields for euler-v2: its pools across chains with APY, TVL, 7d APY change" gives a concrete resource, a named protocol, and the exact data fields returned, which cleanly separates it from the buy_yields_chain_* and buy_yields_token_* siblings. It stops short of an explicit routing sentence (e.g. use buy_yields_chain_base for chain-wide views), so it is clear but not fully differentiated by statement.

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 implied by the protocol name rather than stated: an agent must infer it should call this when it wants Euler-v2 pool yields. The description does add genuinely useful preconditions (paid, no account/API key, failed calls not charged), but it never names an alternative or a when-not-to-use condition among the hundreds of sibling yield tools.

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