SCRIPTMASTERLABS — ClaimGate

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

Adds major context beyond annotations: exact price ($0.25 USDC, amount 250000, Base), the required PAYMENT-SIGNATURE header, the HTTP 402 challenge shape, and the safety property that a misconfigured jury fails before payment is requested. It also discloses the coherence formula and anti-hallucination substring gate, consistent with the openWorldHint/non-idempotent annotations.

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 two most decision-relevant facts (paid tool, cost) and packs a lot of genuinely useful information. The core sentence is an extremely long run-on with nested clauses, which slightly hurts scannability, but no sentence is 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 does the work of explaining the return surface: per-source entailment with verbatim-quote evidence, a coherence-gated verdict, and a stored receipt. That is nearly complete; only a concrete response shape (field names/structure) is left implicit.

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 claim, sources, and sub_claims are already fully documented in the schema. The description mentions decomposition behavior but adds no syntax, format, or constraint detail beyond what the schema provides, 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 ('fact-check a claim against live web sources') and even summarizes the internal pipeline (decomposition, per-source entailment, coherence-gated verdict). However, it never names or distinguishes itself from the four siblings (fact_check_preview, fact_check_status, fact_check_receipt, fact_check_methodology), so an agent gets no routing signal.

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 useful conditions about payment ('send the x402 PAYMENT-SIGNATURE header', 'without payment the call returns the canonical x402 challenge') and the jury-unconfigured failure path. But it offers no guidance on when to use this paid end-to-end tool versus the free preview or the receipt/status siblings, which is the main selection decision an agent faces.

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.