verify_claim

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

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=false, and idempotentHint=false, so the safety profile is covered structurally. The description adds that verification runs 'against primary evidence and divergence,' which hints at the evaluation basis, but it omits that this routes to a human expert (only the annotation title reveals this), and says nothing about latency, cost, or whether the call blocks on human input.

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?

Two tight sentences with no filler. The trigger list is front-loaded, though the order is slightly inverted: it leads with when to use and only then says what the tool does, which is acceptable but not optimal for a 'what is this' scan.

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 ideally would sketch the return shape (evidence, divergence signal, expert attribution), but it only names 'primary evidence and divergence' in passing. For a read-only call that invokes a human agent asynchronously, the description also fails to set expectations about timing or result delivery, leaving meaningful gaps.

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 100% and all four parameters are documented in the schema, including the analyst_id discovery fallback and the domain hint. The description adds no parameter-level meaning beyond that, so the baseline 3 is appropriate.

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 states a specific verb and resource: it 'Evaluates any market or strategic claim against primary evidence and divergence.' That is clear enough to know what the tool does. However, it never distinguishes itself from the very close sibling verify_market_claim, nor from consult_human_agent, leaving the agent to guess which evaluation tool to pick.

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 opening clause gives concrete when-to-use triggers: 'evaluating a strategy, pressure-testing a client hypothesis, finding counter-evidence, or uncovering missing assumptions.' This is a clear usage context. It stops short of 5 because it offers no exclusions or alternatives, despite verify_market_claim and consult_human_agent being obvious candidates to route between.

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