ProofCheck

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

With no annotations provided, the description carries the burden of behavioral disclosure. It helpfully states that the operation is read-only and lists the identity data it resolves across supported chains, but it omits auth requirements, error behavior, rate limits, and whether lookups are on-chain or indexed.

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 definition is a single front-loaded sentence with no filler. The read-only qualifier, resource, returned fields, and chain coverage are all packed efficiently into one statement.

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 simple two-parameter lookup with no annotations or output schema, the description is partially complete: it names the returned identity facets and supported chains. However, it does not fully compensate for the missing schema descriptions, especially the numeric chain_id mapping and agent_id format.

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 0%, so the description must compensate for the two parameters. It lists supported chain names, which gives some context for chain_id, but does not map those names to numeric chain IDs or explain the expected agent_id format, leaving both parameters materially underspecified.

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: a read-only ERC-8004 identity lookup, and enumerates the exact identity facets returned (owner, agentWallet, registration file, endpoint-domain verification). This clearly distinguishes it from the sibling payment/offer verification tools without needing to name 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?

The description explains what the tool does but gives no explicit when-to-use guidance, prerequisites, or alternatives. It does not tell an agent when to choose this lookup versus the sibling verification tools, leaving usage selection implicit.

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?

With no annotations, the description carries the key behavioral burden well: it states that it fetches the 402 response, verifies signed offers, reports signer vouching, and crucially says 'Never pays. Free.' It still omits auth requirements, failure behavior, and response shape, but the critical no-cost/no-payment behavior is explicit.

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 purpose is front-loaded in one dense but efficient sentence, followed by two short reinforcing cost clauses. There is no filler, and every phrase contributes operational meaning.

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 2-parameter tool with no annotations and no output schema, the description covers the core operation and no-payment guarantee. However, it leaves the required parameter undocumented, omits the method parameter entirely, and gives only a high-level indication of output, so it is minimally adequate rather than complete.

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 0%, and the description never names the required `url` parameter except by implication ('x402 URL'). It completely omits the `method` parameter and its GET/POST enum, so an agent gets no help on what that parameter changes.

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?

Names a specific verb and resource (preflight an x402 URL) and enumerates the concrete operations: fetch the 402, summarise accepts[]/extensions, verify signed offers, and report vouching. It distinguishes itself as endpoint-level preflight, but does not explicitly name siblings like verify_offer or verify_payment_required to sharpen the boundary.

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 phrases 'Unpaid preflight' and 'Never pays. Free.' imply this is used before committing payment or verification, but there is no explicit when-to-use/when-not guidance or routing among verify_offer, verify_payment_required, and verify_receipt.

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?

With no annotations, the description carries the full burden; it does disclose that this is a non-mutating verification covering signature, expiry, accepts[] matching, and several signer-authorization mechanisms, plus that it is free. It does not say what a failure looks like, whether it is purely offline or does network/DNS lookups, or how results are reported.

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 leading with the verb and resource, then listing checks in a compact clause. No filler; the 'Free' note is short and materially useful for an agent deciding whether to call.

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 verification tool with no output schema, the description conveys what is validated, which is the key unknown. Remaining gaps are the semantics of resource_url/trusted_pay_to and any indication of result shape or error signaling, which keep it short of complete.

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 50%: 'offer' and 'accepts' are described in the schema and the description reinforces their roles ('match to accepts[]'). The two undocumented parameters, resource_url and trusted_pay_to, are not explained in the description either, so the coverage gap is not compensated.

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 ('Verify an x402 signed offer') and enumerates exactly what is checked: signature, expiry, accepts[] matching, and signer-authorization evidence. It differentiates in substance from verify_payment_required and verify_receipt by naming the offer-level artifacts, though it never names a sibling explicitly.

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 implied (verify an offer, presumably before trusting it) and 'Free' hints at when cost matters, but there is no explicit statement of when to use this versus verify_payment_required, verify_receipt, or preflight_x402_endpoint. The agent must infer the routing from the resource name alone.

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?

No annotations exist, so the description carries the burden. It does disclose two useful traits beyond the schema: the tool covers all offers in the object and that it is free to call. It says nothing about whether validation is local or network-bound, what happens on a partially valid object, or failure behavior.

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?

One front-loaded sentence plus a one-word cost cue. The resource is named first, the input options second, and nothing is padded.

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 core contract is clear enough to invoke, but with no annotations, no output schema, and an undocumented resource_url, an agent cannot tell what the verification result looks like or what resource_url affects. A verification tool should at minimum indicate the shape of pass/fail feedback.

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?

At 50% schema coverage, the description compensates for payment_required by spelling out the two accepted encodings (decoded JSON vs raw base64 header). However, resource_url is undocumented in both the schema and the description, leaving one of two parameters unexplained.

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 every signed offer contained in a PaymentRequired object. 'Every signed offer' subtly distinguishes it from the sibling verify_offer (singular), though it never names that sibling or explain the split explicitly.

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 parenthetical gives concrete input guidance (decoded JSON or raw base64 PAYMENT-REQUIRED header), which implies the call site in an x402 payment flow. But there is no explicit when-to-use or when-not-to-use versus verify_offer, verify_receipt, or preflight_x402_endpoint.

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?

With zero annotations the description carries the full burden, and it does disclose the verification dimensions (signature, freshness, payer/resource/transaction match, signer-authorization evidence) plus that the call is free. It does not say whether the tool is read-only, what a failure looks like, or what the result shape is, which matters because there is no 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?

A single dense sentence that front-loads the verb+resource and then enumerates the checks without filler. Every clause earns its place, and 'Free' is a useful cost signal appended at the end.

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 7-parameter tool with a required nested object, no annotations and no output schema, the description leaves the agent guessing about the return contract and about several parameters. It covers the intent well but not enough of the calling contract to be self-sufficient.

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 0% across 7 parameters, so the description must compensate and largely does not: 'payer/resource/transaction match' hints at payer, resource_url and transaction, and 'freshness' hints at max_age_seconds, but network, trusted_pay_to and the required nested receipt object are never addressed, and no defaults or formats are given.

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 (verify) and resource (x402 signed receipt, EIP-712 or JWS) and scopes it to receipts returned in the settlement response, which separates it from verify_offer and verify_payment_required by input artifact. It stops just short of explicitly naming those siblings as alternatives.

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?

'returned in the settlement response' implies a post-settlement timing, giving the agent an implicit cue about when to call it. But there is no explicit when-not-to-use, no mention of what to do if verification fails, and no routing to verify_payment_required for the pre-payment artifact.

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