groundcheck

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

Annotations already declare read-only, idempotent, non-destructive. The description adds substantial behavioral detail: returns a signed offline-verifiable receipt, binds payment to delivery to content via hashes, includes structural conformance and grounded verdicts, and is paid per call. No contradiction with 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?

Well-structured with clear sections (PURPOSE, GUIDELINES, PARAMETERS, LIMITATIONS, EXAMPLE). However, the PARAMETERS section largely duplicates the input schema descriptions, adding minor redundancy. Otherwise efficient for a complex 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?

The tool is complex (6 params, no output schema) but the description covers return values (delivery_verdict with options), rationale, example output, payment binding semantics, schema conformance scope, and content-checking limits. It provides enough to select and invoke correctly, and to interpret the result.

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 baseline is 3. The description adds meaning by specifying payment_receipt as X-PAYMENT-RESPONSE value in base64/raw JSON, advertised_schema from 402 offer/Bazaar listing, and request_text bound by hash when given. The example illustrates parameter combinations, though the PARAMETERS section largely repeats schema descriptions.

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 states the tool's unique function: verifies what was delivered by an x402 paid service and returns a signed receipt with verdicts. It distinguishes from siblings by focusing on delivery attestation rather than content verification, while referencing verify_claim for source-coverage limits.

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?

Provides explicit guidelines: call after a paid third-party call whose output will be acted on or accounted for. Lists branching actions for each verdict (consistent/degraded/inconsistent/unverifiable). Mentions on-chain confirmation as a separate step and notes consistency-vs-quality limitations, implying alternatives like verify_claim for claim-level verification.

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?

Beyond the readOnlyHint/openWorldHint/idempotentHint annotations, the description discloses substantial behavioral traits: claims are extracted automatically, questions/opinions/instructions are skipped, results are bounded by max_claims, source-coverage limits match verify_claim, payment is per-call, and a signed receipt is bound to a hash of the text. This is far more than annotations provide.

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 organized into PURPOSE, GUIDELINES, PARAMETERS, LIMITATIONS, and EXAMPLE sections. Each section adds value, and the example is concise and illustrative. At roughly 150 words it is detailed yet not bloated, with the purpose front-loaded.

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?

Even without an output schema, the description covers return fields (verdict, sufficiency, conformal guarantee), signed receipt, limitations, payment behavior, and an example. Combined with rich annotations and a simple two-parameter schema, this is complete for an agent to select and invoke the tool 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?

The input schema already describes both parameters (text and max_claims) with full coverage. The description's PARAMETERS section mostly restates the schema, adding only that claims are extracted automatically and providing an example. This does not add significant new meaning beyond the schema, so the baseline score of 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 opens with 'Fact-check EVERY factual claim in a block of text and return a per-claim report' and explicitly calls it 'the batch form of verify_claim'. This clearly distinguishes it from sibling verify_claim (single claim) and states the specific resource (block of text).

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 GUIDELINES section explicitly states when to call the tool: 'on any multi-claim text you are about to rely on', and when to use the alternative: 'Use verify_claim instead for a single claim.' It also specifies the context of AI-generated drafts or documents before publishing or acting.

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 mark readOnlyHint, idempotentHint, and destructiveHint:false, and the description adds valuable context beyond that: the tool is rule-based and auditable, deterministic ('same text always yields the same claims'), skips questions/opinions/instructions, may under-split, and does NOT verify. No contradiction with annotations; 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 long but uses clear section headers (PURPOSE, GUIDELINES, PARAMETERS, LIMITATIONS, EXAMPLE). Every section adds distinct value; it could be marginally tightened but is well-organized and not bloated.

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, the description covers the return shape ({claims, count, input_sha256} plus signed receipt), limitations, and pricing. It also clarifies the relationship to verify_claim and check_citations, making it complete for confident selection and invocation.

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 description need not add much. It restates text and max_claims, but the example ('extract_claims({"text": "Marie Curie..."}) -> {count: 2, ...}') clarifies parameter usage and return shape. The small push beyond schema baseline justifies a 4.

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 opens with a specific verb+resource: 'Split text into independently checkable ATOMIC factual claims' and frames it as the first step of a verification loop. It clearly distinguishes from siblings by naming check_citations as the extract+ground alternative, so purpose is unmistakable.

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 states when to use: 'Call when you want to see WHICH claims a document makes before paying to ground them...' and also when NOT to, pointing to check_citations for combined extraction+grounding. This is textbook usage guidance with alternatives named.

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, openWorldHint, idempotentHint, and destructiveHint. The description adds substantial behavior: conservative by design, returns matched=false rather than guessing, covers only OpenFIGI symbology, does not price or resolve crypto, and is paid per call. This goes well beyond the 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?

The description is well-organized with labeled sections (PURPOSE, GUIDELINES, PARAMETERS, LIMITATIONS, EXAMPLE), front-loading the core purpose. Every sentence contributes value, with no redundant filler, and the example aids quick comprehension.

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?

Despite no output schema, the description explicitly states the return structure (matched, instruments, provenance). It covers purpose, usage, limitations, and parameters, providing enough context for an agent to select and invoke the tool effectively. The example further anchors real usage.

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?

Input schema descriptions cover 100% of parameters, so baseline is 3. The description reiterates parameter meanings and adds an example call, but does not introduce significant new semantic detail beyond the schema. The auto-detection note appears in both places.

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 uses a specific verb 'resolve' with the resource 'security identifier or instrument name' and target 'canonical FIGI records' via OpenFIGI. It also highlights unique outputs like provenance and a signed receipt, clearly distinguishing it from sibling tools such as verify_claim or 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?

The description explicitly instructs 'Call BEFORE acting on any claim, order, or document that names a security' and advises preferring explicit identifiers. It also notes what the tool does not do (e.g., pricing, crypto). However, it does not explicitly name alternative sibling tools, so it stops short of the top criterion.

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?

Beyond the annotations (readOnlyHint, openWorldHint, idempotentHint), the description discloses significant behavioral traits: compound claims are split and recombined weakest-link, the conformal guarantee only exists on calibrated deployments, and the tool checks source support rather than ultimate truth. This provides context that annotations alone do not 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?

The description is long but well-structured with clear labeled sections (PURPOSE, GUIDELINES, PARAMETERS, LIMITATIONS, EXAMPLE). Each section adds unique value, though it could be tightened. The structure aids scanning and comprehension, earning a 4 rather than 3.

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 the absence of an output schema, the description fully explains the return fields (verdict, sufficiency, guarantee, atoms, provenance) and provides a concrete example. It also covers limitations and usage guidance, making it complete for a tool of this complexity.

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 input schema already describes both parameters (claim as a single declarative sentence, max_sources 1-10 default 5). The description's PARAMETERS section restates these constraints but does not add new semantics beyond the schema. With 100% schema coverage, 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 clearly states the tool's purpose: 'Fact-check one claim against live retrieved sources and return a result you can GATE A DECISION ON'. It specifies the verb (fact-check), resource (one claim), and outcome (verdict with guarantee and provenance). It also distinguishes itself from an LLM's own judgment, making its unique value explicit.

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 GUIDELINES section provides explicit when-to-use: 'Call BEFORE asserting a fact you are not certain of, or before acting on one.' It also explains how to interpret the result via sufficiency and guarantee, and offers an alternative by recommending 'Prefer this over calling an LLM's own judgment'. Limitations further clarify when not to use it, such as for very recent or private claims.

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