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

Beyond the readOnly/openWorld annotations, the description discloses cost mechanics (\$0.01/call via x402 USDC or card key), the 25-free-call allowance, that failed calls are free, and that repeats are not free because each call is charged — an unusual and highly decision-relevant trait. It also disclaims 'not investment advice' and affirms 'reads or computes only and changes nothing', and with no output schema present it still previews the return payload (APY base and reward, 30-day mean, TVL, exposure, risk flags).

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?

Purpose, coverage and use case are front-loaded, and every clause carries information (filters, output fields, pricing, safety). The single run-on paragraph mixes commercial and legal caveats into the functional description, which slightly dilutes scanability, but there is 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?

For a 5-parameter read-only lookup with no output schema, the description covers purpose, filters, return fields, payment model and safety. The remaining gap is inter-tool disambiguation from defi_yields and defi_yield_history, and the ranking/sort semantics implied by 'best'.

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%, so the baseline is 3, but the description adds meaning on top: it clarifies that chain, project and symbol are all optional filters ('Filter by chain, protocol or another stablecoin'), that USDC is the implicit default, and gives a concrete call example (symbol=USDC). It does not explain ordering/scoring logic behind 'the best' or how limit interacts with minTvl ranking.

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 opens with a specific verb and resource ('USDC yield right now: the best stablecoin APY across DeFi lending, vault and LP pools'), enumerates the covered protocols and chains, and states the returned fields. An agent can tell this is a ranked stablecoin-yield lookup rather than a general TVL or historical-yield tool.

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?

'Use to find where an agent can earn yield on USDC or any stablecoin' plus the note that it can be re-scoped to USDT/DAI/other chains gives clear trigger conditions. It stops short of naming when NOT to use it — the siblings defi_yields and defi_yield_history are never mentioned, so the agent must infer the boundary between this curated USDC view and the generic/historical yield tools.

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