verify_response

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

Without annotations, the description fully discloses behavior: it explains the 4-signal fusion cascade (WITNESS, ECE, EPR, Spectral), states all computation is 100% local with zero LLM/API calls, and details the return structure. This is exemplary transparency.

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 front-loaded with the core purpose and method, then details return values and computation characteristics. While slightly long, every sentence adds value; it could be tightened but is well-organized.

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 is provided in the input, the description compensates by listing all output fields (fused_risk, verdict, per-signal scores, flagged_claims, recommendation) and explaining the overall pipeline. This makes the tool complete enough for an agent to understand its capabilities and results.

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 0%, so the description must add meaning. It defines 'response' as 'the AI-generated text to verify', 'context' as 'the source context provided to the AI', and 'prompt' as 'the original user prompt/query (helps calibrate verification).' This adds value beyond the schema properties with defaults.

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 specifies the tool's purpose: 'Verify an AI-generated response for hallucination using the 4-signal fusion cascade.' It distinguishes itself by noting it uses the same pipeline as the proxy but is directly callable from MCP clients, setting it apart from sibling tools like eicv_verify_claim or verify_and_repair.

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 advises: 'Use this after generating a response to check for factual claims that aren't grounded in the provided context.' This provides clear usage context. However, it does not explicitly mention when not to use it or name alternative tools, missing some guidance for an agent.

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