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

No annotations are present, so the description carries the behavioral disclosure burden. It does disclose the paid nature ('PAID $0.02'), the data source ('public venue params'), and that the ranking uses GROSS rather than net bonus. It does not state the return format, pagination behavior, or whether the call has any side effects, which is a meaningful gap for a paid 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?

The description is extremely compact and front-loaded: cost first, then the ranked purpose, then the use-case framing. Every phrase contributes information and there is no fluff. The standalone 'PAID $0.02' fragment is structurally unusual but earns its place as a critical cost signal.

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 paid tool with no output schema, the description should explain what the caller receives, how chain/limit/minBonusUsd affect results, and how the x402 payment flow proceeds; it explains none of these. The x402 field is documented in the schema, but the description itself provides almost no invocation guidance. An agent familiar with the domain could use it, but it is not self-sufficient.

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 25%, so the description needed to explain chain, limit, and minBonusUsd, but it does not address them by name. It does define the underlying bonus metric ('debt × close-factor × venue bonus'), which helps interpret minBonusUsd, but chain filtering and limit behavior remain undocumented in both the schema and description.

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 states that the tool returns liquidation targets ranked by GROSS seize-bonus USD and gives the exact ranking formula, so the deliverable is clear. It lacks an explicit verb like 'list' or 'get', but 'Liquidation targets ranked by...' and 'ready funnel' make the intended output unmistakable. The specific ranking criterion also distinguishes it from vaguely similar siblings like farm_liquidations.

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?

'A ready funnel of the biggest opportunities' implies this is for surfacing top liquidation candidates, and 'PAID $0.02' warns about cost before calling. However, the description does not name alternative tools or state when to prefer farm_liquidations, farm_hot, or farm_storefront instead. Usage guidance is implied rather than explicit.

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