verify_citation

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

No annotations are provided, so the description carries the full burden. It discloses the core behavior (re-query and compare) and the anti-hallucination purpose, which is useful. However, it does not state whether the tool is read-only, what happens on mismatch, or any side effects. The description adds some context but lacks completeness for a tool with no annotation support.

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 two concise sentences, front-loaded with the action and purpose. It avoids redundancy and earns every word, mentioning both the mechanism and the recommended usage scenario.

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 no output schema, the description should explain return values or match criteria, but it does not. It also has conditional parameters (standard vs qna) that are not explicitly explained in the description, though the schema covers them. The tool's complexity is moderate, but the description omits critical behavioral details like what constitutes a successful verification.

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 description coverage is high (83%), so the baseline is 3. The description adds minimal value beyond the schema: it maps source parameter values to get_paragraph/get_qna, but the schema already explains the enum (standard/qna). Claim's requirement for exact quoting is also already in the schema, so the description does not meaningfully enhance parameter understanding.

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 clearly states the tool re-queries and compares quoted sentences against K-IFRS sources (get_paragraph/get_qna), with a specific verb and resource. However, it does not distinguish itself from the similarly named sibling 'verify_citations', leaving ambiguity about whether it handles single vs. multiple citations.

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 suggests using this tool after writing reports for key citations, which gives a clear usage context. However, it does not explicitly mention when not to use it, nor does it differentiate from the sibling 'verify_citations' which likely overlaps in functionality. The alternative tools get_paragraph/get_qna are referenced only as data sources, not as alternatives.

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