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

Annotations already declare the safety profile (non-destructive but not read-only, open-world), so the description's job is to add context beyond them — and it does by disclosing the price ("PAID 0.10 USD via MPP") and the conservative, source-backed nature of the verdict. It does not, however, explain billing semantics (per-call charge, failure charging) or what happens if the claim is not verdict-eligible, both relevant for a paid non-idempotent 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?

Front-loads the critical operational fact (paid, 0.10 USD) and then the behavior, keeping it to a few sentences. There is mild redundancy: sentence two and sentence three both restate that the tool adjudicates concrete claims, and the described verdict sets overlap without matching (partially verified/insufficient-evidence vs uncertain).

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 an output schema present, return values need not be explained, and the description covers cost, input shape, verdict philosophy, and exclusions. The remaining gap is the inconsistent verdict taxonomy and undefined jargon ("verdict-eligible maintained atomic claims"), which an agent cannot map onto expected outputs.

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% with a single well-documented param, so the baseline is 3. The description adds meaningful constraint the schema does not: the input must be one concrete proposition, not an open-ended question, which directly shapes how the agent must formulate the string it passes.

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 a specific verb and resource — evaluate one specific Bitcoin factual proposition and return a verdict — plus the exact verdict vocabulary and evidence metadata returned. It explicitly contrasts itself with siblings that compose answers to broader questions (answer_bitcoin_question, deep_ground_bitcoin), so an agent can route correctly without opening a schema.

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 gives an explicit inclusion rule ("Use only for a concrete proposition that needs supported, contradicted, mixed, or uncertain adjudication") and an explicit exclusion rule ("Do not use for open-ended explanation or general evidence collection"). It also frames the calling context ("upstream agent already has a concrete factual Bitcoin claim and needs adjudication" rather than a composed answer), which is exactly the decision an agent must make.

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