x402 Doctor

Check an x402 payment proof (free)

check_payment_proof

Read-only

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.

Input Schema

Name	Required	Description	Default
`header`	Yes	The PAYMENT-RESPONSE header value (base64 JSON)

Output Schema

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

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedOct 29, 2026

removedInput schema / additionalProperties
```
Removed value: -false
```
changedOutput schema / additionalProperties
```
Previous value: -trueNew value: +{}
```
addedOutput schema / properties / checks / items / propertyNames
```
Added value: +{
+  "type": "string"
+}
```
addedOutput schema / properties / decoded / propertyNames
```
Added value: +{
+  "type": "string"
+}
```

changedOutput schema / properties / onchain / anyOf

Previous value: -[
-  {
-    "additionalProperties": {},
-    "type": "object"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "additionalProperties": {},
+    "propertyNames": {
+      "type": "string"
+    },
+    "type": "object"
+  },
+  {
+    "type": "null"
+  }
+]

Changed1 schema field changedOct 9, 2026

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"
+}

AddedOct 3, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare readOnlyHint and openWorldHint, and the description adds genuinely new operational facts: zero cost, a 10-calls-per-hour rate limit, that it performs an on-chain existence/success lookup, and that it resolves payer/payee USDC transfers. That is meaningful disclosure beyond the annotation set, though it doesn't explain failure modes for an invalid or unmatched header.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

One dense but well-ordered sentence covering cost, when to call, input provenance, and return contents, followed by two short qualifiers for read-only and rate limit. No filler and the key facts are front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values needn't be spelled out, yet the description still summarizes them helpfully. Cost, rate limit, input source, and mutation profile are all covered — nothing an agent needs to call this correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the single parameter is already documented as a base64 JSON header value. The description adds provenance and format guidance — which header to grab, the X-PAYMENT-RESPONSE v1 naming — giving it value above the baseline 3 for fully-covered schemas.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

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 payment proof) and enumerates exactly what it returns: transaction, network, payer, on-chain existence/success, USDC movement, explorer link. It doesn't explicitly differentiate itself from the closest sibling, verify_receipt, so it falls short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear triggering context — 'after paying an x402 endpoint, pass the PAYMENT-RESPONSE header it returned' — and notes the v1 header name variant. It offers no explicit exclusion or comparison to alternatives such as verify_receipt, so the when-not guidance is missing.

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

All x402 Doctor tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.