x402 Doctor

Diagnose an x402 endpoint ($0.01 via x402)

x402_diagnose

Read-only

Paid ($0.01 via x402 in USDC on Base, Solana, Monad, Polygon, Arbitrum, Avalanche, Algorand or Stellar, or in RLUSD on the XRP Ledger): 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.

Input Schema

Name	Required	Description
`url`	Yes	The x402 endpoint (public http(s) URL), e.g. https://api.example.com/paid
`body`	No	Example JSON request body, for a POST route that checks its input before the 402 (implies POST). Without it, {} is sent and the requestBody example in the endpoint's /openapi.json is tried.
`method`	No	HTTP method of the paid route (default: GET, then POST)

Output Schema

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

Schema Changelog

Changes observed during successful MCP inspections.

Changed7 schema fields changedOct 29, 2026

removedInput schema / additionalProperties
```
Removed value: -false
```
changedOutput schema / additionalProperties
```
Previous value: -trueNew value: +{}
```

changedOutput schema / properties / accepts / anyOf

Previous value: -[
-  {
-    "$ref": "#/properties/checks/anyOf/0"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "items": {
+      "additionalProperties": {},
+      "propertyNames": {
+        "type": "string"
+      },
+      "type": "object"
+    },
+    "type": "array"
+  },
+  {
+    "type": "null"
+  }
+]

changedOutput schema / properties / checks / anyOf

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

addedOutput schema / properties / overall / anyOf

Added value: +[
+  {
+    "description": "pass, warn or fail",
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

removedOutput schema / properties / overall / type
```
Removed value: -[
-  "string",
-  "null"
-]
```

changedOutput schema / properties / receipt / anyOf

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

Changed1 schema field changedOct 20, 2026

addedInput schema / properties / body

Added value: +{
+  "description": "Example JSON request body, for a POST route that checks its input before the 402 (implies POST). Without it, {} is sent and the requestBody example in the endpoint's /openapi.json is tried.",
+  "maxLength": 16384,
+  "type": "string"
+}

Changed1 schema field changedOct 9, 2026

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

First observedSep 25, 2026

TDQS

A4/5.0

Behavior4/5

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

Annotations only declare readOnlyHint and openWorldHint; the description adds real behavioral context beyond them — that the tool itself costs $0.01 in listed currencies, that the target endpoint is never paid, what the response contains (pass/warn/fail per check plus a fix hint), and that a signed EIP-191 receipt bound to the caller's arguments is returned. It doesn't describe rate limits, latency, or failure behavior for unreachable URLs, which keeps it below a 5.

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

Conciseness3/5

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

The price and currency enumeration is front-loaded, which is useful, but the eight-chain USDC/RLUSD list is verbose and consumes roughly a third of the text before the actual purpose appears. The core sentence is a long run-on that packs checks, audience, alternative, and receipt into one breath instead of structured clauses.

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

Completeness4/5

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

With an output schema present, return values needn't be explained, and annotations cover the safety profile; the description still covers what is checked, how results are graded, the receipt artifact, and the cost of invocation. Remaining gaps are minor operational details such as behavior on unreachable or non-x402 endpoints.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents url, body, and method, including the body-implies-POST behavior and the openapi.json fallback. The description adds no per-parameter meaning of its own, so the baseline of 3 applies.

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

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb and resource ("diagnose an x402 endpoint") and immediately defines the scope: it inspects the endpoint the way a paying agent would, without paying it, checking the 402 challenge, accepts[] options, resource URL, settlement readiness, discovery, and paywall. It explicitly distinguishes itself from the sibling x402_preflight by intended audience (endpoint owner vs. prospective payer).

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?

It states both sides of the routing decision: use this when you own or are debugging the endpoint, use x402_preflight when deciding whether to pay someone else's endpoint. That is explicit when/when-not guidance with a named alternative. It doesn't address the other closely related siblings (x402_quick_check, x402_preflight_deep, x402_delivery_check, x402_fix), so the routing is clear but not exhaustive.

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.