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

Beyond the readOnly/openWorld annotations, the description discloses that the conversation is kept server-side per verification (statefulness), that calls must be sequential rather than parallel, and that it costs credits at the cheap rate. These are meaningful operational traits an agent cannot get from the annotations alone.

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-loaded with the core purpose, then prerequisites, cost, and sequencing constraints in compact order. Every sentence carries information, though a few details (language handling, id type) echo the schema descriptions rather than adding new content.

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 stateful, credit-costing follow-up tool with an output schema already covering returns, the description supplies everything an agent needs: what evidence it draws on, prerequisites, correct identifier, ordering constraint, and cost. Nothing material is missing.

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% and the schema descriptions already carry the key parameter guidance (leave language unset, 500-char limit, verification_id not task_id), so the description largely restates it. Baseline 3 is appropriate since the schema, not the description, does the heavy lifting for parameter meaning.

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 a specific verb (ask a follow-up question) and resource (grounded in a completed verify_claim result), and explicitly contrasts itself with siblings by noting it reads the FULL evidence the trimmed get_verification payload omits. An agent can distinguish it from get_verification, verify_claim, and assess_claim without opening any 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?

Gives explicit preconditions (only on a completed verify_claim, not assess_claim results), tells the agent which identifier to pass and which to avoid (verification_id from get_verification, NOT a task_id), and adds a sequencing rule (ask follow-ups sequentially, not in parallel). Nothing about when to choose this tool is left to inference.

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