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

The annotations already indicate a safe, read-only, idempotent operation, so the bar for added value is lower. The description goes well beyond annotations by clarifying the meaning of 'could_not_verify' (an error, not evidence) and 'unsupported' (no source covered), describing the two routing paths, and explaining that the tolerance can override the claim wording. This is rich behavioral context that is essential for correct invocation and interpretation.

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 longer than average, but every sentence contributes essential information: trigger phrases, routing logic, return verdicts, error semantics, and efficiency gain. It is front-loaded with the most crucial usage context and then layers details. The only minor issue is that the final note about replacing sequential calls could be trimmed, but it adds persuasive context. Overall, it is well-structured and not wasteful.

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, so the description must explain return values and error conditions. It fully covers this by listing verdict types, mentioning the actual value with citation, and explicitly distinguishing 'could_not_verify' from 'unsupported'. It also addresses the two distinct input categories (financial vs. non-financial) and the tolerance override. Given the tool's complexity, the description is complete.

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?

The input schema already provides thorough descriptions for both parameters (claim with examples, tolerance_pct with range and default), so baseline is 3. The tool description adds value by explaining the intended use of tolerance_pct ('set 1–2 for hallucination detection where any material error must be refuted') and by giving concrete claim examples that clarify the expected format. This extra guidance justifies a 4.

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 opens with concrete natural-language triggers ('Is it true that…', 'fact check', 'verify the claim that…') and explicitly states the tool's function: natural-language claim verification against authoritative sources. It clearly differentiates this from sibling tools by emphasizing the verdict-based output and the two routing paths (SEC/XBRL for company financials, grounded pipeline for everything else).

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 explicitly tells the agent when to use the tool: 'Use whenever the agent needs to check whether something a user said is factually correct.' It also subdivides use cases (company financial claims vs. all other factual claims) and explains the fallback behavior. However, it does not explicitly name alternative sibling tools or say 'when not to use' beyond the inferred scope, so it earns a 4 rather than a 5.

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