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

Annotations cover only the safety profile (readOnlyHint, openWorldHint, idempotentHint=false). The description adds substantial context the annotations cannot convey: the x402 USDC Base payment requirement, the three ways to supply the payer, the structured payment_required challenge on unpaid calls, the no-fabricated-data guarantee, and the refund-on-refusal policy. It loses a point only for not clarifying whether the polling endpoint implies async/partial results or how long horizon_end takes.

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 sentence 'after paying, poll /v1/resolutions/:id until horizon_end' appears verbatim twice in the description, which is pure redundancy. The payment alternatives are also listed three times over, and the dense x402/rail jargon crowds out the actual purpose, so the payload is not front-loaded.

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?

An output schema exists, so return values need not be described, and the paid-call lifecycle is well covered. Against a 5-parameter tool with nested required objects and only 20% schema coverage, though, the description omits the shape and meaning of most required inputs, leaving the agent under-equipped to build a valid call.

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 20% across 5 parameters with a nested candidate object, so the description must compensate. It does explain 'payer' precisely (Base address 0x…, plus the header alternative), but says nothing about the required 'asset', 'address', or the structured 'candidate' object, leaving the majority of low-coverage parameters undocumented.

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 it returns a liquidation-proximity distribution as 'the same account liquidation-proximity distribution as account risk, labelled with the token subject kind', which does distinguish it from account-risk siblings by subject kind. However the phrasing is dense jargon and never plainly says the action is 'retrieve token risk', so an agent must parse two layers of internal vocabulary to grasp the purpose.

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?

It implies the choice condition (token subject vs account subject) and points to tollbridge_pricing for exact USDC, which is useful routing. But there is no explicit when-to-use vs when-not guidance, no statement of what the tool is unsuited for, and the payer/payment conditions are mechanics rather than usage guidance.

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