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

Beyond the annotations (readOnly, openWorld, non-idempotent), the description discloses the things an agent actually needs to know: a 0.10 USDC charge per call on Base via x402 exact, a shared pool of 10 signed-wallet free calls per rolling 30 days, the exact POST route, the required X-Wever-Wallet-Proof binding to the JSON arguments and route, and an Ed25519 signed receipt in the response. That is far more than the annotations carry, and it flags the billing consequence of non-idempotent repeated calls.

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 paragraph is front-loaded with purpose and inputs, then moves to output shape, then payment/auth details, in a sensible order with no filler sentences. It is dense and packs pricing, route and signing into a single block, which is efficient but slightly harder to scan than a short bulleted split.

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?

There is no output schema, and the description compensates fully by enumerating what the brief contains (fair price, all inputs, per-venue spread in points, reasoning summary, engine reasoning when available). Combined with the payment, auth and receipt details, an agent has everything needed to call it correctly and anticipate the result.

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 property descriptions already document both fields well; the prose adds the operational constraint that exactly one market is accepted per call and reinforces that the identifier must belong to the named platform. It otherwise restates the schema's ticker/slug/URL options, so the added meaning is modest rather than substantial.

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 opening sentence names a specific resource (a deep brief on a single prediction market's fair value) and explicitly positions it against the lighter free lookup that shares its name, so an agent can distinguish it from the 'fair-value' sibling. It also names the two supported venues and the one-market-per-call scope, making the operation unambiguous.

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 establishes the paid/free relationship ('the deep brief behind the free fair-value lookup') and the 'one market per call' constraint, which implicitly tells an agent when to reach for this heavier tool versus a simple lookup. It stops short of an explicit exclusion such as 'use fair-value instead when you only need a single number', leaving that inference to the caller.

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