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

Annotations indicate readOnlyHint=false, so the tool may have side effects, but the description only mentions a payment cost, not what exactly happens with payment_signature, whether it triggers a charge, or what the response contains. The description does not contradict annotations, but it fails to explain the payment mechanism or any behavioral implications beyond the price.

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?

The description is concise and front-loaded with the paid nature and core purpose, but it repeats the title almost verbatim and adds only one new piece of information (the $0.01 cost). It could be better structured to explain payment flow or usage context without being overly long.

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 8 parameters, no output schema, and only 13% schema coverage, the description leaves significant gaps: how payment works, what the response looks like, how to use the filters in combination, and what the 'sort' values mean. The description is too thin for an agent to confidently invoke this tool correctly, especially given the payment_signature parameter.

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 only 13%, so the description carries some burden for explaining parameters. The description explicitly mentions filters (chain, protocol, token, stablecoin-only, minimum TVL) which maps to several parameters, but does not explain the 'sort' enum, 'limit' semantics, or the crucial 'payment_signature' parameter's role. The schema has minimal descriptions, so the description only partially compensates.

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 clearly states the tool's function: retrieving best DeFi yields from 15,000+ pools with filters by chain, protocol, token, stablecoin-only, and minimum TVL. The verb is implicit ('get') and the title is nearly identical to the description, but the description adds specific filter details and the payment cost, making it distinct enough from siblings like genesis402_scan or genesis402_call.

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?

The description says it is paid ($0.01 USDC) and suggests it is for querying yields, but provides no guidance on when to choose it over alternatives like genesis402_multi_chain_scan or genesis402_prove. There is no mention of when not to use it, no context about payment flow aside from the cost, and no comparison to sibling tools.

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