Claim Grounding

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the bar is lower. The description still adds valuable non-obvious behavior: it abstains rather than guessing, and critically that this MCP call returns payment instructions while POST /v1/check_answer returns results, plus the $1.00 USDC/x402 cost. Per-claim return detail is somewhat redundant with the output schema.

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?

Purpose is front-loaded, followed by return contents, usage, and payment mechanics in a logical order. It is dense and slightly run-on with a long enumerated return list, but nearly every clause carries real information.

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?

An output schema exists, yet the description still adequately signals the response shape; it also documents the source-usage behavior, abstention semantics, and the payment/endpoint split an agent must understand to invoke it correctly. Nothing needed to call it is missing.

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 three parameters are thoroughly documented in the schema (including fetch timeouts, URL restrictions, char caps). The description adds no parameter-level detail beyond what the schema already provides, so the baseline of 3 applies.

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?

States a specific verb and resource ('Fact-check a whole answer') and immediately differentiates scope: it extracts every checkable claim and verifies each against Wikipedia plus Wikidata. The 'whole answer' framing clearly separates it from siblings like verify_claim (single claim) and extract_claims.

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?

Gives a concrete use case ('Use to audit chatbot or RAG output') and implies the scope condition (whole-answer auditing), which distinguishes it from the single-claim siblings. However, it never names the alternatives (verify_claim, deep_verify, extract_claims) or states when NOT to use it.

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

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

Annotations already cover safety (readOnly, idempotent, openWorld), but the description adds genuinely non-inferable behavior: asynchronous execution with a free polling endpoint (GET /v1/jobs/{job_id}), a concrete price and payment rail ($0.75 USDC on Base via x402), and the full response shape (verdict, confidence, pro/con evidence with URLs, contradiction flags). These are traits no annotation or schema field conveys.

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?

Five tight sentences, front-loaded with the usage trigger before capability, output, and cost details. Slight redundancy: 'Read-only' merely echoes readOnlyHint=true, and the pricing clause is wedged mid-paragraph, but overall density is high and waste is minimal.

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?

With a rich output schema covering return values and annotations covering the safety profile, the description fills the remaining gaps an agent needs: when to select it over siblings, the async/polling flow, and the paid-invocation cost. Nothing required to call it correctly is missing.

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%, so the schema already documents `answer`, `sources`, and `sources_only` in detail, including URL/text tradeoffs and limits. The description only restates the 'up to three claims' cap and adds nothing about parameters beyond the schema, so the baseline of 3 applies.

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?

States a specific verb and resource — 'Verifies up to three claims' — and enumerates the exact public sources consulted (Wikipedia, Wikidata, Google News, Europe PMC, FRED, SEC EDGAR). It also names sibling tools (check_answer, extract_claims) and the conditions that route to this one, so an agent can distinguish it without opening the schema.

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?

Explicit when-to-use: 'when a claim is high-stakes, or when check_answer or extract_claims marks it unsure (their next_step gives the exact request).' This names both trigger conditions and the upstream tools whose output drives the call, leaving nothing to inference.

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

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

Annotations cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false), and the description goes well beyond them: hedges stripped, pronouns resolved across sentences, compound sentences split, and specific classes (questions, greetings, opinions, predictions) marked grounding_required false. It also discloses the paid flow ($0.05 USDC on Base via x402, MCP call returns payment instructions while POST /v1/extract_claims returns claims) — material behavior an agent cannot infer.

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?

Information-dense and front-loaded: purpose and output shape come first, behavioral transformations next, routing last. The pricing glossary ('MCP call returns payment instructions and POST /v1/extract_claims returns the claims') is a slightly dense clause, but every sentence carries operational value.

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?

Covers input, the paid invocation protocol (critical, since a naive call only yields payment instructions), and the pipeline relationship. An output schema exists, so explaining return values is optional, and the description still summarizes them without bloating the definition. Nothing needed to call this correctly is missing.

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% for the single 'text' parameter, so the schema already carries the input semantics; the description's mention of an AI-generated answer and character limits largely duplicates it. The extra detail provided describes the output fields (span, claim_type, check_worthiness) rather than the input, so the baseline 3 applies.

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?

States a specific verb+resource ('Split a text into atomic factual claims') and immediately qualifies the scope with 'atomic factual claims' rather than generic extraction. The sequencing note 'Use before verify_claim' positions it relative to the sibling pipeline, so an agent can place it without opening another schema.

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?

Explicitly says 'Use before verify_claim,' which tells the agent where this fits in the workflow, and names the input type ('for example an AI-generated answer'). It does not state exclusions or when to route elsewhere (e.g. vs deep_verify), so it stops short of a full when/when-not treatment.

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

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

Annotations already cover read-only/idempotent/open-world, but the description adds material context beyond them: the $1.00 USDC-on-Base x402 price, the two-step flow (this MCP call returns payment instructions, the paid HTTP route POST /v1/verify_claim returns the verdict), and the fallback behavior of returning insufficient_evidence rather than guessing.

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?

Front-loads the core action and its return values in the first sentence, then appends payment/route mechanics and sibling routing. Dense but every clause is load-bearing; the payment sentence is slightly tangled and could be split, keeping it short of a 5.

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?

With an output schema present, return values need not be detailed, yet the description still names the verdict set and the evidence fields. Combined with cost/route disclosure and source-handling semantics, an agent has everything needed to invoke it 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, but the description adds value on how caller-supplied sources are treated: they are extra evidence alongside public sources, cited with provider and source_type "caller", and listed back in sources_used. It does not itself explain the url/text/title source shapes, which the schema handles.

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?

States a specific verb+resource ('Check one factual claim against public Wikipedia sources') and enumerates the exact verdict values returned. It also names the sibling it is not: multi-source work belongs to deep_verify, so the agent can distinguish single-claim scope without opening the schema.

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?

Gives explicit routing to deep_verify for multi-source checks and clarifies the sources_only condition (judge only against caller sources). It does not address when to prefer check_answer or extract_claims, and the 'use when' framing is implied by the singular-claim constraint rather than stated.

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