Check an x402 seller before paying: verdict, failure rate and evidence from paid calls on Base.
Scored across 4 tools
Each tool has a distinct role: checking one seller before payment, listing reliable sellers for selection, viewing recent changes, and reporting a completed payment. The overlap between check_x402_seller and list_reliable_sellers is managed by clearly different use cases and outputs.
Three tools follow a clear verb_noun snake_case pattern, with x402 embedded naturally. recent_changes is a noun phrase rather than verb_noun, which is a minor deviation but still readable and consistent with snake_case.
Four tools are well-scoped for an x402 seller reliability and reporting service. Each tool covers a distinct step in the workflow without redundancy, and the set does not feel thin for its apparent purpose.
The surface covers the core lifecycle: pre-payment seller checks, reliable-seller discovery, change monitoring, and post-payment reporting with proof. Minor gaps exist around broader seller search or deeper per-seller history, but agents can work around these via check_x402_seller and recent_changes.
Call this before any x402 payment, before retrying a request that answered HTTP 402, or whenever the user is about to buy an API call with USDC on Base or names an API they intend to pay per call. Returns a verdict (avoid, caution, ok, unknown), one sentence to act on, the seller's paid-call count and failure rate with a 95% interval, listed price, modal quote and max overcharge ratio when known, and links to the seller page and raw evidence.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | x402 resource URL, or a bare seller domain such as api.example.com |
| Name | Required | Description |
|---|---|---|
| host | Yes | |
| probe | Yes | Hourly unpaid probes of the seller's 402 quote; null when not probed |
| seller | Yes | Measured paid calls to this seller; null when the study never paid it |
| verdict | Yes | |
| resource | Yes | Measured paid calls to this exact URL; null when not measured |
| candidate | Yes | Queue state for a seller not yet measured; null otherwise |
| seller_url | Yes | |
| evidence_url | Yes | |
| generated_at | Yes | When the index was generated |
| verdict_text | Yes | One sentence to act on, with the evidence link |
| methodology_url | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds useful behavioral detail: the verdict enum (avoid/caution/ok/unknown) and the evidence returned. It doesn't say what happens on unresolvable URLs or how to interpret 'unknown.'
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 sentence, front-loaded with the invocation triggers before the return details. Dense but no filler; the return-value clause is slightly redundant given the output schema exists.
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 read-only, one-parameter tool with a full output schema, the definition covers triggers and the shape of the verdict. The only gap is guidance on handling 'unknown' or unresolvable inputs.
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% and the single param is fully documented in the schema (URL or bare domain). The description only hints at the URL concept through the 'names an API' phrasing and adds no format or syntax detail 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?
States a specific verb and resource: 'Check an x402 seller.' The scope is unmistakable, though it doesn't name the sibling tools (list_reliable_sellers, recent_changes) to differentiate 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?
Gives explicit triggers: before any x402 payment, before retrying after an HTTP 402, or when the user names an API they intend to pay per call. It doesn't say when NOT to use it or name a specific alternative to use instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Call this when choosing among sellers for a task, or when the user asks for a safe or reliable API. Returns sellers with zero failures across at least 30 paid calls, most-called first. For each: domain, category, paid-call count, the 95% upper bound on its failure rate, median quoted price in USDC, USDC paid to it in the last 30 days, when it was last seen, and its paidfor seller page.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many sellers to return, most-called first; 50 when omitted | |
| category | No | Kind of service to list sellers for; omit to list every kind |
| Name | Required | Description |
|---|---|---|
| sellers | Yes | |
| generated_at | Yes | When the index was generated |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnlyHint, idempotentHint, openWorldHint), so the description's added value is the reliability filter threshold, the ordering rule, and the full return field list. It doesn't mention pagination limits beyond the schema or freshness windows for the reliability window itself, but the substance is well above the annotation bar.
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 well-organized sentences, leading with the trigger condition and following with the return payload. The return-field enumeration is long but earns its place by telling the agent what it can filter or report on; a minor trim would still convey it.
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 the description needn't document returns formally, yet it still summarizes each field including the statistical measure (95% upper bound on failure rate) that an agent needs to interpret reliability. Read-only, idempotent, open-world behavior is fully accounted for.
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% and both parameters are documented with defaults (50 when omitted) and enum semantics (omit to list every kind). The description adds no parameter detail beyond the schema, 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 and resource (list reliable sellers) with the exact reliability criterion: zero failures across at least 30 paid calls, sorted most-called first. Easily distinguished from siblings check_x402_seller (single-seller lookup) and recent_changes (change feed).
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 names the triggering situation: 'Call this when choosing among sellers for a task, or when the user asks for a safe or reliable API.' The sibling check_x402_seller is implicitly the per-seller counterpart, and no exclusions are needed given the criteria are self-selecting.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Call this when the user asks what changed, or before relying on a verdict older than a day. Returns recent changes, newest first: verdict changes, new failures by type, moved quotes, changed pay-to addresses, sellers added or reaching 30 paid calls, published seller replies, the operator-reported series maturing or disagreeing with ours. Each change has its time, type, seller domain, seller page and type-specific details (for example the old and new quote).
| Name | Required | Description | Default |
|---|---|---|---|
| host | No | Seller to show changes for, as a bare domain such as api.example.com; omit for every seller | |
| since | No | Show only changes after this time, in ISO 8601 (such as the generated_at of a verdict you already have); omit for the latest changes |
| Name | Required | Description |
|---|---|---|
| count | Yes | Matching changes the index returned (it caps the feed at the newest 500); events holds at most the newest 100 |
| events | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive, open-world behavior, so the safety profile is covered. The description adds genuinely new behavioral facts: results are ordered newest first and each change carries time, type, seller domain, seller page, and type-specific details such as old/new quote values.
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, front-loaded with the calling trigger before the return payload. The long enumeration of change types is dense but each entry conveys a distinct, actionable event category, so it earns its space; minor tightening is possible.
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 and the description does not waste words re-explaining return shapes. With only two optional, fully documented parameters, the description covers triggers, ordering, and change semantics completely enough for correct 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 coverage is 100%, so both host and since are already documented in the schema. The description adds only a loose hint that since can be a verdict's generated_at, which the schema itself states; the baseline 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?
States a specific verb and resource ('Returns recent changes') and then enumerates exactly which change types are included (verdict changes, new failures, moved quotes, pay-to address changes, seller additions, replies, series maturity). That enumeration makes it immediately distinguishable from check_x402_seller and list_reliable_sellers.
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 two concrete triggers: 'when the user asks what changed' and 'before relying on a verdict older than a day.' The second one implicitly routes agents away from trusting a stale check_x402_seller verdict, which is useful, but no sibling is named explicitly and there is no when-not-to-use statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
After your agent pays an x402 seller with any wallet, report what came back. Needs the resource URL, the settlement transaction hash and the outcome. Free, no account, no key; the report counts only with on-chain proof.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The x402 resource URL that was paid for | |
| outcome | Yes | What came back: ok (the response was usable for its purpose), non_delivery (an error, an empty body or nothing usable after paying), wrong_goods (a usable response, but not what was asked for), overcharge (charged more than the quoted or listed price), duplicate (two settlements for one purchase) | |
| tx_hash | Yes | The settlement transaction hash on Base: the `transaction` field of the seller's PAYMENT-RESPONSE or X-PAYMENT-RESPONSE header (base64 JSON) | |
| http_status | No | The HTTP status of the paid response, if known | |
| quoted_usdc | No | The price the 402 quoted, in USDC, if known |
| Name | Required | Description |
|---|---|---|
| payer | Yes | The paying wallet, read from the transaction (never from the report) |
| pay_to | Yes | |
| reason | Yes | Why a report was rejected; null otherwise |
| status | Yes | verified: counted once folded in (minutes); pending: checked on Base again within minutes; duplicate: this transaction was already reported; rejected: not counted, see reason |
| sentence | Yes | The result in one sentence |
| amount_usdc | Yes | USDC moved, read from the transaction |
| verification_url | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare idempotent=true, destructive=false, openWorld=true and readOnly=false, so the safety profile is covered. The description adds valuable context beyond that: it is free, requires no account or key, and only counts with on-chain proof. It omits rate limits and what happens to duplicate reports, but the added auth/cost context is substantial.
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?
Three short sentences, front-loaded with the trigger and the required inputs. Every sentence earns its place: trigger, required fields, and cost/proof constraint.
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 100%-covered input schema and an output schema, the description covers the trigger, required inputs, cost/auth profile and proof requirement. It does not explain duplicate-report behavior despite idempotent=true, which is a minor gap for a reporting 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?
Schema coverage is 100% and the schema descriptions are detailed, including a full explanation of every outcome enum value and the tx_hash format. The description repeats the three required fields (url, tx_hash, outcome) but adds no syntax or format detail beyond the schema. 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 (report) and resource (an x402 payment outcome), plus the trigger (after your agent pays a seller with any wallet). This clearly distinguishes it from check_x402_seller, list_reliable_sellers and recent_changes, which query seller state rather than record a payment result.
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 gives a clear triggering condition: use it after an agent pays an x402 seller. It also states the prerequisite that the report only counts with on-chain proof. It does not explicitly name alternatives or exclusions, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
check_x402_sellerlist_reliable_sellersrecent_changesreport_x402_paymentTrust scores for x402 sellers: wash-trading, real buyers, verdict. $0.02/score via x402 on Base.
Live x402 endpoint trust/diligence check before you pay it. $0.02/call via x402.
Independent measured reviews of x402 API sellers: pre-payment verdicts and accuracy grades.
We buy from x402 endpoints with real USDC and publish delivery outcomes. Check before you spend.
Add one secure layer between your agents and this server.
