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

No annotations exist, so the description carries the full burden, and it delivers meaningful operational facts: this is a paid endpoint at $0.002 USDC on Base or Solana, needs no account or API key, and failed calls are not charged. It also discloses the upstream data source (DefiLlama). What it omits is the response shape (fields per pool row) and any rate limits or freshness guarantees.

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?

It is front-loaded with the billing flag, then purpose, then cost and access terms, then the endpoint URL — a sensible order with no filler sentences. The pricing and URL clauses are dense but each carries real operational information for a paid tool.

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 annotations and no output schema, the description must cover cost, access, and data provenance — and it does, which is the main risk an agent faces when calling a paid endpoint. The remaining gap is that nothing describes the returned record fields (pool, protocol, chain, APY, TVL) that the purpose sentence promises, leaving the caller to discover the shape empirically.

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?

All three parameters are fully documented in the schema (100% coverage, including defaults for sort, limit, and min_tvl_usd), so the schema does the heavy lifting. The description adds no further constraint semantics, such as how min_tvl_usd interacts with the returned rows or what 'live' means for filtering. Baseline 3 applies when schema coverage is complete.

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 specific resource and scope: live yield pools holding STEAKUSDG across protocols and chains, with APY and TVL. That is concrete enough that an agent can tell it apart from the token-agnostic siblings (buy_yields_chain_*, buy_yields_protocol_*) and from the adjacent buy_yields_token_steakusdc without opening any schema.

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 resource scope (want yield on STEAKUSDG -> call this), but the description never states when to prefer it over a sibling such as buy_yields_stablecoins or a chain- or protocol-specific yield tool, and gives no exclusions. The agent must infer the routing decision from the token name alone.

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