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

With no annotations, the description carries the full burden and does disclose substantive behavior: the price and chain of payment, that the submitted description is discarded and only its hash retained, that no composite score is produced, and which data classes are barred or excluded. It stops short of stating failure modes, latency, or what happens if a submitted leg is not loaded beyond the NOT-ASSESSABLE label.

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?

One long, densely parenthetical block that front-loads pricing instead of purpose and packs output-enumeration, exclusions, and retention policy into a single sprawling construction. Much of it is legible only to someone already fluent in this service's internal vocabulary.

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, describing the returned verdict contents is appropriate and reasonably thorough, including explicit exclusions. However, undefined jargon (H1, A1, cleared legs, grades) and the absence of any usage context leave an agent unable to reason confidently about inputs or when to call it.

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 baseline is 3; the description does add some meaning by tying 'legs' to per-leg demand claims with a data-date and grade, and by introducing the H1/A1 class distinction that maps loosely to question_class. It never states what a valid leg id looks like or what values question_class accepts, so it does not clearly exceed 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?

The first sentence states a concrete action: it returns one demand verdict for a tool or service description the caller submits, priced at $0.02 USDC on Solana. The verb+resource are identifiable, but the purpose is buried under payment framing and undefined domain jargon (H1 legs, A1, ASKED-FOR), and nothing distinguishes it from demand_verdict_criteria or demand_verdict_precheck.

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?

No when-to-use guidance, no prerequisites (wallet/payment setup, what a 'leg' is, how legs get 'cleared'), and no routing to the criteria or precheck siblings. The description explains what the paid output contains rather than when an agent should choose this tool over adjacent ones.

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