ClaimGate

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

Annotations only flag openWorldHint/readOnlyHint=false; the description carries the real behavioral burden and does it well: $0.25 price, the exact PAYMENT-SIGNATURE header requirement, the five payment rails with amounts, the HTTP 402 challenge shape when unpaid, and the crucial guarantee that an unconfigured jury fails before payment so no charge occurs. The verdict computation (coherence = |sum(w*d)|/sum(w), weights 3/2/1) and the anti-hallucination substring gate are also disclosed. This is behavior an agent cannot infer from any structured field.

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 pricing is correctly front-loaded, but the sentence structure is a single sprawling parenthetical and the five payment rails are effectively enumerated twice (once in the price list, again in the 402 challenge). Tightening to state the price and header once would preserve all signal; as written, dense jargon like 'coherence-gated' and 'SML receiver' competes with the actionable instructions.

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?

For a paid, open-world tool with no output schema, the description covers the payment protocol, failure preconditions, and what the verdict consists of — enough to call it correctly. The remaining gap is the post-call story: it mentions a 'sealed stored receipt' but never says how the caller retrieves or references it, which matters given a dedicated receipt sibling.

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 claim, sources (max 8, HTTPS, fallback to web search under 2 usable), and sub_claims (max 4, sentence-split default). The description reinforces the decomposition behavior but adds no per-parameter syntax or formatting guidance beyond the schema. 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 ('Fact-check a claim against live web sources') and sketches the mechanism: sub-claim decomposition, live source fetching, juror entailment, coherence-gated verdict. That is clearly distinguishable from fact_check_receipt or fact_check_methodology by name alone. It stops short of explicitly contrasting itself with the preview/status siblings, so not a 5.

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?

Usage is only implied: you call it when you have a claim to verify, and the description notes a precondition (jury must be configured or the call fails before payment). There is no explicit routing to siblings — nothing says to run fact_check_preview first to see cost, or to use fact_check_status/receipt afterward, even though the tool mints a 'stored receipt' that a sibling presumably retrieves.

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 readOnly, idempotent, non-destructive, and open-world, so the safety profile is done. The description adds genuinely non-structured information: 'calibrated:false — thresholds are stated, not fitted', which tells the agent the thresholds are prescriptive rather than empirically derived, and 'honest limits' signals the document itself discloses caveats. It does not say whether the content is static or whether output is large.

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 sentences: the first front-loads the resource and then enumerates contents, the second delivers the calibrated:false caveat. The enumeration is long but each item is a substantive section of the document, so little is wasted; a slightly tighter list would earn 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 no parameters, no output schema, and annotations covering the safety profile, the remaining burden is telling the agent what it will get and how to treat it — which the description does via the content list plus the calibration caveat. Only the output format/stability and the exact usage relationship to fact_check_claim are left out.

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 tool takes zero parameters and the schema is an empty object with additionalProperties false, so there is nothing for the description to disambiguate. Baseline 4 applies; the description correctly makes no parameter claims that could mislead.

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 immediately establishes that this returns the complete ClaimGate methodology document and enumerates its contents (coherence formula, source-class weights, verdict thresholds, verbatim-quote gate, independence rules). The retrieval verb is implicit rather than stated, and no sibling tool is named or contrasted, but the resource is unambiguous.

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 says nothing about when to call this versus the other fact_check_* tools, nor does it suggest calling it before fact_check_claim to interpret verdicts. Usage is only inferable from the content list, which is a conspicuous gap given four closely named siblings.

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 establish readOnly, idempotent, open-world, and non-destructive behavior. The description adds useful context beyond annotations: the tool performs live source fetching or web search, returns no verdict, makes no jury calls, and requires no payment.

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 a single front-loaded sentence that leads with 'Free preview' and efficiently covers the workflow, source handling, and explicit exclusions. Every clause contributes useful differentiation or behavior.

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?

For a complex multi-step preview tool with no output schema, the description does well by explaining the pipeline and clarifying that no verdict is returned. It still leaves the response shape somewhat unspecified, though the 'show exactly what a paid fact_check_claim would check' phrasing provides reasonable expectation.

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 both the claim and sources parameters are already well documented. The description mentions live fetching/searching, which loosely reinforces the sources parameter fallback, but adds no syntax or constraints beyond the schema.

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 decomposes a claim, fetches/classifies sources, groups them into independent families, and previews what a paid check would verify. It explicitly contrasts itself with fact_check_claim by saying 'No verdict, no jury calls, no payment,' so an agent can distinguish it from the paid sibling.

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 clearly frames this as a free preview of what fact_check_claim would check, which gives strong usage context. However, it does not explicitly state when to choose this over fact_check_status, fact_check_receipt, or fact_check_methodology, nor 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 establish that this is a read-only, idempotent, non-destructive call, so the safety profile is covered. The description adds real value by enumerating the receipt's contents (sub-claims, sources, per-family verdicts with validated verbatim quotes, coherence, verdict, payment) and by noting that only a paid check yields a receipt, which is behavior the annotations cannot convey.

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?

A single front-loaded sentence: the action and resource come first, the parenthetical expands the return payload, and nothing is wasted. Its length is proportionate to a one-parameter lookup tool.

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?

Because there is no output schema, the description correctly shouldered the burden of describing return contents, and it does so well. The remaining gap is minor but real: it does not say what happens if the check is unpaid or the receipt_id is unknown (error versus empty), which matters for an openWorldHint tool.

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?

With only one parameter and 100% schema description coverage, the schema already carries the semantics, including the constraint range and the cg_..._........ example format. The description restates that receipt_id identifies a sealed record but adds no format, origin, or error-handling detail beyond the schema — baseline 3.

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 definition uses a specific verb and resource ("Fetch a stored ClaimGate receipt") and immediately qualifies the artifact ("the sealed record of a paid fact check"), so the agent knows exactly what comes back. It does not, however, distinguish itself from the fact_check_status sibling, even though the two could be confused when a user wants the current state of a check versus the sealed receipt.

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 requirement to hold a receipt_id (implicitly returned only after a paid fact check completes) suggests when the tool is applicable, but usage is only implied. There is no explicit statement such as "call after fact_check_claim completes" or "use fact_check_status while the check is still running," which would have removed the guesswork among four siblings.

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 declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint. Beyond that, the description usefully discloses what the call reports (live status, jury config, facilitator selection, receipt count, price) — return-value context that matters since no output schema exists. It does not state whether the call requires auth or whether price retrieval is free.

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?

A single front-loaded sentence that leads with the primary check ('whether ClaimGate is live') and then enumerates secondary facts. Dense but every clause names a distinct config surface, so there is no filler.

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 no output schema, the description carries the burden of describing return content, and it largely does by listing the five facts reported. A read-only, idempotent, zero-param tool needs little more, though a note that it requires no auth and is free to call would close the remaining gap.

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 tool takes zero parameters, so the baseline is 4; there is no parameter semantics an agent could get wrong. The description correctly implies no input is needed.

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 gives a concrete verb ('Check') plus an enumerated set of system facts (ClaimGate liveness, Jev jury configuration, x402 facilitator, receipt count, paid-check price), which makes clear this is a diagnostic/status tool. It is implicitly distinguishable from siblings like fact_check_claim and fact_check_receipt, though it never names them.

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?

Usage is only implied: an agent can infer this is a pre-flight/config check to run before invoking paid checks, but the description never says when to use it, when not to, or how it relates to the four sibling tools. No exclusions or alternatives are stated.

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