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

No annotations are provided, so the description carries the full disclosure burden. "Right now" implies live/snapshot data and the field list signals this is a read-only query, but it says nothing about data freshness/caching latency, rate limits, or whether results are paginated — meaningful gaps for an unannotated tool.

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 resource and metric payload, then filters, then use case — no filler sentences. The returned-field enumeration is dense but each item earns its place by telling the agent what it can screen on.

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 an output schema present, the description need not explain return shapes, and it still summarizes them usefully. The missing pieces are the limit/pagination behavior and precise sort and stablecoin semantics, which leave a small but real gap for a 7-param no-default-required 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 0% with 7 parameters, yet the description only implies chain, protocol, token (symbol), min TVL and sort by APY/TVL. It omits the limit parameter entirely and never enumerates valid sort values or clarifies whether stablecoin is a filter or purely a returned field.

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 resource (DeFi yields: lending, staking, liquidity pools) with scope (all chains and protocols) and the metric set returned (APY base+rewards, 30-day mean, TVL, stablecoin flag, IL risk). An agent can distinguish it from siblings like defi_lending_rates or defi_protocols_tvl by the aggregate, cross-protocol scope.

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 to earn on USDC, ETH etc." gives a clear positive use case, and the filter/sort clause tells the agent how to narrow. However, it never names an alternative tool or states when NOT to use it, so routing against defi_lending_rates remains inference.

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