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

Even though annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false, the description adds significant behavioral context: the routing logic, the return verdict vocabulary, the meaning of could_not_verify vs unsupported, citation format, and that it replaces multiple calls. No contradiction with annotations.

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 description is long but every part earns its place: trigger phrases, routing rules, return details, and critical caller warnings. It's front-loaded with natural-language query examples, and the 'IMPORTANT for callers' section is clearly highlighted. No filler or redundancy.

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?

Given the tool has only 2 parameters, no output schema, and moderate complexity, the description is remarkably complete: it explains input style, internal routing, output verdicts, evidence citation, error semantics, and alternatives. It fully prepares an agent to invoke and interpret results correctly.

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 adds extra meaning beyond the schema by explaining how tolerance_pct interacts with 'the tolerance implied by the claim wording' and by giving concrete claim examples for the claim parameter. This enriches parameter understanding without replacing 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 description starts with a clear verb—validate—and resource (claim), then gives natural-language trigger examples and explicitly contrasts with siblings like ask_pipeworx_grounded and deep_research by noting it replaces 4–6 sequential calls. It clearly distinguishes the tool's purpose from other list/entity/search tools.

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?

States 'Use whenever the agent needs to check whether something a user said is factually correct.' It also gives explicit when-to-use paths: company-financial claims go through SEC EDGAR, any other factual claim routes to the grounded pipeline. It provides strong exclusions and warnings, like 'could_not_verify means the check did not happen... must not be shown as one.'

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