Is this x402/MPP API safe to pay? $0.001 preflight, fixes, a $0.25 test purchase. Free quick check.
Scored across 8 tools
Most tools have distinct purposes: check_payment_proof verifies after payment, feedback reports issues, x402_fix returns code changes, and x402_preflight_batch handles multiple endpoints. However, x402_quick_check, x402_diagnose, and x402_preflight (and its deep variant) all check x402 endpoints with overlapping diagnostic outputs, so an agent could confuse which tier to use despite the descriptions' guidance.
Tool names use consistent snake_case and a clear x402_ prefix for the six domain-specific tools, with predictable suffixes like _preflight, _batch, _deep. The two free utilities (check_payment_proof, feedback) break the prefix pattern but are still readable and consistent in style.
Eight tools is well-scoped for a diagnostic service that offers free quick checks, paid tiered diagnosis, batch preflight, deep analysis, code fixes, payment proof verification, and feedback. Each tool serves a distinct use case or price/depth tier without excessive fragmentation.
The surface covers the full lifecycle: pre-payment checks (preflight variants), endpoint diagnosis (diagnose), remediation (fix), post-payment verification (check_payment_proof), and user feedback. A minor gap is the lack of a tool to verify the signed diagnosis receipts the server issues, but core workflows are otherwise complete.
Free: after paying an x402 endpoint, pass the PAYMENT-RESPONSE header it returned (X-PAYMENT-RESPONSE in v1). Returns the transaction, network and payer it names, whether that transaction exists on-chain and succeeded, and which USDC moved from whom to whom, with an explorer link. Read-only. Limited to 10 calls per hour.
| Name | Required | Description | Default |
|---|---|---|---|
| header | Yes | The PAYMENT-RESPONSE header value (base64 JSON) |
| Name | Required | Description |
|---|---|---|
| checks | No | |
| decoded | No | Transaction, network and payer named in the header |
| onchain | No | Whether the transaction exists and succeeded, and the USDC transfers |
| overall | Yes | pass, warn or fail |
| explorer | No | Explorer link for the transaction |
Report a bug, a missing feature or anything else about this service, in a structured way. Free. A person reads every report; nothing is run or changed automatically.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | bug, feature (something missing) or other | |
| contact | No | Optional: how to reach you about it | |
| message | Yes | What happened or what you need | |
| endpoint | No | Optional: the route or tool it is about, e.g. /v1/token |
| Name | Required | Description |
|---|---|---|
| id | Yes | Report id, to refer to it later |
| note | No | |
| type | No | |
| service | No | |
| received | Yes | true: a person will read it |
Free: check the signed receipt that every paid x402 Doctor answer carries (diagnose, preflight, batch, deep, fix, delivery check; HTTP or MCP), for example to prove later which verdict you got before paying an endpoint. Pass the whole answer as response. Returns valid, the signer and whether it is an x402 Doctor signer; with route and input also whether the receipt is for exactly that request. A changed verdict or receipt fails. Read-only, nothing is stored. Same as POST /api/v1/verify.
| Name | Required | Description | Default |
|---|---|---|---|
| input | No | The tool arguments you sent (MCP), or the query parameters as strings (HTTP) | |
| route | No | The request it answered: "mcp <tool name>" for an MCP answer (e.g. "mcp x402_preflight"), "GET /api/v1/preflight" for an HTTP one | |
| response | Yes | The whole paid answer as you received it, including its receipt |
| Name | Required | Description |
|---|---|---|
| valid | Yes | true: signed by an x402 Doctor signer, unchanged, and (when route and input are given) for that request |
| reason | No | Why it is not valid |
| signer | No | The address that signed it |
| known_signer | No | Whether that address is a current, retired or certified x402 Doctor signer |
| input_matches | No | Only with route and input: whether the receipt is for exactly that request |
| signer_status | No | current, retired or certified |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds real behavioral context beyond the readOnlyHint annotation: it discloses what is returned (valid, signer, x402-signer status), when the request-matching check applies (with route and input), that a changed verdict/receipt fails, and that nothing is stored. This is useful, non-redundant disclosure.
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 key point ('Free: check ...') but then runs into a long parenthetical enumeration and multiple clauses in one paragraph. It is dense and mostly earns its place, but could be tightened.
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 an output schema and full schema coverage, the description need not explain return values, yet it does summarize them and covers failure semantics and storage behavior. Adequate and nearly complete for this tool's 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?
Schema coverage is 100%, so the baseline is 3, but the description adds functional meaning: response is the whole answer, and route+input enable an exact-request match. That clarifies the intent of the optional parameters beyond their schema text.
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 (check/verify) and resource (the signed receipt carried by every paid x402 Doctor answer), and enumerates which answer types it covers. It is clear what the tool does, though it does not explicitly distinguish itself from the sibling check_payment_proof, which could overlap.
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 a concrete motivating scenario ('to prove later which verdict you got before paying an endpoint') and notes the equivalent HTTP route. There are no explicit when-not conditions or named alternatives, so it stops 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.
Paid ($0.25 USDC via x402 on Base or Solana): not a reading but a purchase. x402 Doctor buys the endpoint once (at most $0.1, USDC on Base, from its own wallet) with the example input its listing declares, checks the answer against the declared output schema and measures the charge on chain. Answers with a job id at once; follow it with x402_delivery_status (free), the result usually comes within minutes. The endpoint must get a "go" from the pre-payment check and be payable in USDC on Base; otherwise it is refused before payment. Same as GET /api/v1/delivery-check. The answer carries a signed receipt (EIP-191, bound to your arguments) that proves later which verdict you got.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The x402 endpoint to buy once (https, someone else's, payable in USDC on Base) | |
| method | No | HTTP method of the paid route (default: GET, then POST) |
| Name | Required | Description |
|---|---|---|
| id | No | The job id: pass it to x402_delivery_status |
| url | No | |
| status | No | queued, then done |
| accepts | No | Only on an unpaid call: the x402 payment options |
| receipt | No | Signed receipt (EIP-191) binding the answer to your arguments |
| status_url | No | |
| endpoint_price_usd | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds substantial context beyond the annotations: caller cost ($0.25 USDC), the service's own spend cap ($0.1 from its own wallet), payment rail (Base), async job-id behavior, the free polling follow-up, and a signed EIP-191 receipt bound to the arguments. One tension: readOnlyHint=true while the description frames the operation as 'not a reading but a purchase' that spends funds and may POST, so the annotation understates the side effects even though the text is honest about them.
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 price and the key reframing ('not a reading but a purchase') are front-loaded, and each sentence carries distinct information (cost, mechanism, prerequisite, follow-up, receipt). It is dense rather than bloated, though the receipt sentence and the 'Same as GET /api/v1/delivery-check' remark could be trimmed for a selection-time blurb.
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, asynchronous, open-world tool, everything an agent needs is present: cost, prerequisites and refusal conditions, the async job-id pattern, the free status tool to poll, and the receipt guarantee. An output schema also exists, so return-value detail is not the description's burden.
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 parameters are already documented, and the description adds little beyond the schema: it restates that the url must be someone else's and payable in USDC on Base, and says nothing about the method parameter or the GET-then-POST default. Baseline 3 is appropriate when the schema carries the parameter semantics.
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+resource: it buys an x402 endpoint once, checks the response against the declared output schema, and measures the on-chain charge. It is clearly distinguishable from sibling diagnostics (x402_preflight, x402_quick_check, x402_diagnose, x402_delivery_status) because it is the one that actually pays the endpoint, not just inspects it.
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?
It gives real preconditions ('The endpoint must get a "go" from the pre-payment check and be payable in USDC on Base; otherwise it is refused before payment') and routes the agent to the free follow-up (x402_delivery_status). What is missing is an explicit statement of when to prefer this over e.g. x402_quick_check or x402_diagnose, so the agent must infer that this is the paid, definitive check.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free: the status of a delivery check ordered with x402_delivery_check (or GET /api/v1/delivery-check): awaiting_payment, queued or done, and once done the result: paid_and_delivered, the outcome, the charge measured on chain and the transaction.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The job id x402_delivery_check answered with |
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| url | No | |
| result | No | Once done: paid_and_delivered, result, charged_usd, transaction, cache (could a CDN serve the paid answer to callers who did not pay) |
| status | Yes | awaiting_payment, queued or done |
| status_url | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered; the description adds genuinely new context by stating the call is free and describing the state machine (awaiting_payment, queued, done) plus what a completed job yields. It omits non-happy-path behavior such as what happens for an unknown, expired, or unpaid id.
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 cost signal ('Free') and the core purpose, then the state and result enumerations. No filler or repetition of the tool name.
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 does not need to enumerate return fields, yet it does so helpfully; the prerequisite link to x402_delivery_check and the free/paid distinction are the key unknowns an agent would have, and both are covered. Only polling/retry expectations and error states are missing.
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 id parameter is documented in the schema (including its 10-char pattern). The description corroborates the id's origin (it comes from x402_delivery_check) but adds no format or validation 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 resource (status of a delivery check) tied to a named sibling (x402_delivery_check), so the agent can tell it apart from x402_quick_check or x402_preflight without reading schemas. It also enumerates the lifecycle states and the terminal result payload, making the scope 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?
Clearly establishes the prerequisite context — the check must first be ordered with x402_delivery_check (or the equivalent HTTP endpoint) — which is the primary when-to-use signal. It stops short of explicit exclusions or guidance on how to distinguish this from other status-like siblings such as check_payment_proof or verify_receipt.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Paid ($0.01 USDC via x402 on Base or Solana): diagnose an x402 endpoint the way a paying agent would, without paying it: the 402 challenge format, every accepts[] option, the resource URL, Solana settlement readiness, which wallets can pay, Bazaar/OpenAPI discovery and the browser paywall. Returns every check with pass/warn/fail and a fix hint. For the endpoint's owner or a developer debugging it; to decide whether to pay someone else's endpoint, use x402_preflight. Same as GET /api/v1/diagnose. The answer carries a signed receipt (EIP-191, bound to your arguments) that proves later which verdict you got.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The x402 endpoint (public http(s) URL), e.g. https://api.example.com/paid | |
| method | No | HTTP method of the paid route (default: GET, then POST) |
| Name | Required | Description |
|---|---|---|
| url | No | |
| checks | No | Every check with its status, message and hint |
| accepts | No | Only on an unpaid call: the x402 payment options |
| overall | No | pass, warn or fail (absent on the payment requirement) |
| receipt | No | Signed receipt (EIP-191) binding the answer to your arguments |
Paid ($0.05 USDC via x402 on Base or Solana): diagnoses your x402 endpoint, then returns per problem the concrete change as code for your stack (express, next, hono, node, python, generic), filled in with your own payTo, amount, network and route. For the endpoint's owner: includes the diagnosis, so there is no need to call x402_diagnose first. Same as GET /api/v1/fix. The answer carries a signed receipt (EIP-191, bound to your arguments) that proves later which verdict you got.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The x402 endpoint (public http(s) URL), e.g. https://api.example.com/paid | |
| stack | No | Your server stack (default: detected) | |
| method | No | HTTP method of the paid route (default: GET, then POST) |
| Name | Required | Description |
|---|---|---|
| url | No | |
| fixes | No | Each problem with steps and code for your stack |
| accepts | No | Only on an unpaid call: the x402 payment options |
| overall | No | pass, warn or fail |
| receipt | No | Signed receipt (EIP-191) binding the answer to your arguments |
| summary | No | |
| unfixed | No |
Paid ($0.001 USDC via x402 on Base or Solana): call this before your agent pays an x402 endpoint. Returns go, caution or no_go, the recommended payment option, and why: payment would fail, the seller's payout address is on the OFAC SDN sanctions list, over your budget (max_usd), price above what is advertised, not HTTPS, unknown token, its 30-day track record. Never pays the endpoint. The buyer's check for one call; for several endpoints at once use x402_preflight_batch, before a payment above about $1 x402_preflight_deep, and to debug your own endpoint x402_diagnose. Same as GET /api/v1/preflight. The answer carries a signed receipt (EIP-191, bound to your arguments) that proves later which verdict you got.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The x402 endpoint (public http(s) URL), e.g. https://api.example.com/paid | |
| method | No | HTTP method of the paid route (default: GET, then POST) | |
| max_usd | No | Your budget per call in USD, e.g. 0.05 | |
| network | No | CAIP-2 network you want to pay on, e.g. eip155:8453 |
| Name | Required | Description |
|---|---|---|
| url | No | |
| accepts | No | Only on an unpaid call: the x402 payment options |
| options | No | Each payment option with its network, price and problems |
| reasons | No | |
| receipt | No | Signed receipt (EIP-191) binding the answer to your arguments |
| summary | No | One line, e.g. OK to pay: $0.02 on Base. |
| verdict | No | go: pay; caution: ask first; no_go: do not pay |
| safe_to_pay | No |
Paid ($0.005 USDC via x402 on Base or Solana): the pre-payment check for up to 10 x402 endpoints at once. Per endpoint go, caution or no_go, the recommended payment option and why, plus totals. For marketplaces and agents that weigh several services. Never pays the endpoints. Same as GET /api/v1/preflight/batch. The answer carries a signed receipt (EIP-191, bound to your arguments) that proves later which verdict you got.
| Name | Required | Description | Default |
|---|---|---|---|
| urls | Yes | The x402 endpoints to check (public http(s) URLs), at most 10 | |
| method | No | HTTP method of the paid route (default: GET, then POST) | |
| max_usd | No | Your budget per call in USD, e.g. 0.05 | |
| network | No | CAIP-2 network you want to pay on, e.g. eip155:8453 |
| Name | Required | Description |
|---|---|---|
| count | No | |
| counts | No | How many go, caution, no_go and unknown |
| accepts | No | Only on an unpaid call: the x402 payment options |
| receipt | No | Signed receipt (EIP-191) binding the answer to your arguments |
| results | No | One preflight per endpoint |
Paid ($0.01 USDC via x402 on Base or Solana): for expensive calls. The pre-payment verdict (go, caution or no_go) plus the full diagnosis, the 30-day history per day, how reliable the seller's other endpoints are and whether the endpoint moved domains. Never pays the endpoint. Worth it before a payment above about $1; for an ordinary call x402_preflight is enough. Same as GET /api/v1/preflight/deep. The answer carries a signed receipt (EIP-191, bound to your arguments) that proves later which verdict you got.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The x402 endpoint (public http(s) URL), e.g. https://api.example.com/paid | |
| method | No | HTTP method of the paid route (default: GET, then POST) | |
| max_usd | No | Your budget per call in USD, e.g. 0.5 | |
| network | No | CAIP-2 network you want to pay on, e.g. eip155:8453 |
| Name | Required | Description |
|---|---|---|
| url | No | |
| accepts | No | Only on an unpaid call: the x402 payment options |
| options | No | |
| reasons | No | |
| receipt | No | Signed receipt (EIP-191) binding the answer to your arguments |
| summary | No | |
| verdict | No | go: pay; caution: ask first; no_go: do not pay |
| safe_to_pay | No |
Free: does this x402 endpoint work for a paying agent? Returns pass, warn or fail with the number of problems and the top three. Limited to 10 calls per hour. For every check use x402_diagnose ($0.01); for code changes x402_fix ($0.05); before paying someone else's endpoint x402_preflight ($0.001).
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The x402 endpoint (public http(s) URL), e.g. https://api.example.com/paid | |
| method | No | HTTP method of the paid route (default: GET, then POST) |
| Name | Required | Description |
|---|---|---|
| url | No | |
| next | No | |
| overall | Yes | pass, warn or fail |
| failures | Yes | |
| warnings | Yes | |
| top_problems | Yes | Up to three problems, failures first |
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
verify_receiptx402_delivery_checkx402_delivery_statuscheck_payment_proof1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": true,
+ "properties": {
+ "checks": {
+ "items": {
+ "additionalProperties": {},
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "decoded": {
+ "additionalProperties": {},
+ "description": "Transaction, network and payer named in the header",
+ "type": "object"
+ },
+ "explorer": {
+ "description": "Explorer link for the transaction",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "onchain": {
+ "anyOf": [
+ {
+ "additionalProperties": {},
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Whether the transaction exists and succeeded, and the USDC transfers"
+ },
+ "overall": {
+ "description": "pass, warn or fail",
+ "type": "string"
+ }
+ },
+ "required": [
+ "overall"
+ ],
+ "type": "object"
+}feedback1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": true,
+ "properties": {
+ "id": {
+ "description": "Report id, to refer to it later",
+ "type": "string"
+ },
+ "note": {
+ "type": "string"
+ },
+ "received": {
+ "description": "true: a person will read it",
+ "type": "boolean"
+ },
+ "service": {
+ "type": "string"
+ },
+ "type": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "received",
+ "id"
+ ],
+ "type": "object"
+}x402_diagnose1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": true,
+ "properties": {
+ "accepts": {
+ "anyOf": [
+ {
+ "$ref": "#/properties/checks/anyOf/0"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Only on an unpaid call: the x402 payment options"
+ },
+ "checks": {
+ "anyOf": [
+ {
+ "items": {
+ "additionalProperties": {},
+ "type": "object"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Every check with its status, message and hint"
+ },
+ "overall": {
+ "description": "pass, warn or fail (absent on the payment requirement)",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "receipt": {
+ "anyOf": [
+ {
+ "additionalProperties": {},
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Signed receipt (EIP-191) binding the answer to your arguments"
+ },
+ "url": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+}x402_fix1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": true,
+ "properties": {
+ "accepts": {
+ "anyOf": [
+ {
+ "$ref": "#/properties/fixes/anyOf/0"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Only on an unpaid call: the x402 payment options"
+ },
+ "fixes": {
+ "anyOf": [
+ {
+ "items": {
+ "additionalProperties": {},
+ "type": "object"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Each problem with steps and code for your stack"
+ },
+ "overall": {
+ "description": "pass, warn or fail",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "receipt": {
+ "anyOf": [
+ {
+ "additionalProperties": {},
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Signed receipt (EIP-191) binding the answer to your arguments"
+ },
+ "summary": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "unfixed": {
+ "anyOf": [
+ {
+ "$ref": "#/properties/fixes/anyOf/0"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "url": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+}x402_preflight1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": true,
+ "properties": {
+ "accepts": {
+ "anyOf": [
+ {
+ "$ref": "#/properties/options/anyOf/0"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Only on an unpaid call: the x402 payment options"
+ },
+ "options": {
+ "anyOf": [
+ {
+ "items": {
+ "additionalProperties": {},
+ "type": "object"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Each payment option with its network, price and problems"
+ },
+ "reasons": {
+ "anyOf": [
+ {
+ "$ref": "#/properties/options/anyOf/0"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "receipt": {
+ "anyOf": [
+ {
+ "additionalProperties": {},
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Signed receipt (EIP-191) binding the answer to your arguments"
+ },
+ "safe_to_pay": {
+ "type": [
+ "boolean",
+ "null"
+ ]
+ },
+ "summary": {
+ "description": "One line, e.g. OK to pay: $0.02 on Base.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "url": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "verdict": {
+ "description": "go: pay; caution: ask first; no_go: do not pay",
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+}x402_preflight_batch1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": true,
+ "properties": {
+ "accepts": {
+ "anyOf": [
+ {
+ "$ref": "#/properties/results/anyOf/0"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Only on an unpaid call: the x402 payment options"
+ },
+ "count": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "counts": {
+ "anyOf": [
+ {
+ "additionalProperties": {
+ "type": "number"
+ },
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "How many go, caution, no_go and unknown"
+ },
+ "receipt": {
+ "anyOf": [
+ {
+ "additionalProperties": {},
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Signed receipt (EIP-191) binding the answer to your arguments"
+ },
+ "results": {
+ "anyOf": [
+ {
+ "items": {
+ "additionalProperties": {},
+ "type": "object"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "One preflight per endpoint"
+ }
+ },
+ "type": "object"
+}x402_preflight_deep1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": true,
+ "properties": {
+ "accepts": {
+ "anyOf": [
+ {
+ "$ref": "#/properties/options/anyOf/0"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Only on an unpaid call: the x402 payment options"
+ },
+ "options": {
+ "anyOf": [
+ {
+ "items": {
+ "additionalProperties": {},
+ "type": "object"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "reasons": {
+ "anyOf": [
+ {
+ "$ref": "#/properties/options/anyOf/0"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "receipt": {
+ "anyOf": [
+ {
+ "additionalProperties": {},
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Signed receipt (EIP-191) binding the answer to your arguments"
+ },
+ "safe_to_pay": {
+ "type": [
+ "boolean",
+ "null"
+ ]
+ },
+ "summary": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "url": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "verdict": {
+ "description": "go: pay; caution: ask first; no_go: do not pay",
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+}x402_quick_check1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": true,
+ "properties": {
+ "failures": {
+ "type": "number"
+ },
+ "next": {
+ "type": "string"
+ },
+ "overall": {
+ "description": "pass, warn or fail",
+ "type": "string"
+ },
+ "top_problems": {
+ "description": "Up to three problems, failures first",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "url": {
+ "type": "string"
+ },
+ "warnings": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "overall",
+ "failures",
+ "warnings",
+ "top_problems"
+ ],
+ "type": "object"
+}check_payment_proofx402_preflight_batchx402_preflight_deepfeedbackx402_diagnosex402_fixx402_preflightx402_quick_checkPreflight x402 payment compatibility with structured risk evidence and remediation guidance.
Independent measured reviews of x402 API sellers: pre-payment verdicts and accuracy grades.
Pre-send EVM address checks: free pre-check, $0.01 check, $0.05 deep scan. x402: payment is auth.
Live x402 endpoint trust/diligence check before you pay it. $0.02/call via x402.
Add one secure layer between your agents and this server.