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

Annotations already declare read-only, open-world, non-destructive behavior. The description adds important non-annotation context: calling the tool returns terms only, while the actual answer is sold over x402 or ERC-8183 escrow, with a holder pass option. Some phrasing such as 'the paid half' is opaque, but the payment behavior is unusually well disclosed.

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 a long, run-on sentence with nested parentheticals that bury the payment terms and core purpose. Some methodology detail is useful, but it is not front-loaded or cleanly structured.

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 output schema, the description does explain that rows and a summary are returned, what agreement/divergence means, and that break-even days are computed. It also covers payment and terms, though the exact task input packaging and sold-answer mechanics remain somewhat vague.

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 single task parameter is already documented as 'What you want, with the address in it.' The description adds that an amount and current earnings are needed, but it does not clarify the task string format or how those inputs should be packaged beyond the schema.

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 verb and resource: ranks Venus core-pool markets by supply APY and computes whether moving pays for itself. The purpose is clear, but the description never names or distinguishes the sibling tool venus_supply_rates.

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?

Implies usage when comparing Venus markets and evaluating gas break-even from an amount and current earnings. However, it gives no explicit when-to-use guidance, no exclusions, and no comparison to the alternative venus_supply_rates.

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