x402 Doctor

Check up to 10 x402 endpoints before paying ($0.005 via x402)

x402_preflight_batch

Read-only

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

Input Schema

Name	Required	Description
`urls`	Yes	The x402 endpoints to check (public http(s) URLs), at most 10
`client`	No	Set to gateway when your agent pays with Circle's Gateway client (@circle-fin/x402-batching) from a Gateway balance: Gateway-only endpoints are then not a caution, and Gateway options are recommended first.
`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

Output Schema

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

Schema Changelog

Changes observed during successful MCP inspections.

Changed6 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/results/anyOf/0"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "items": {
+      "additionalProperties": {},
+      "propertyNames": {
+        "type": "string"
+      },
+      "type": "object"
+    },
+    "type": "array"
+  },
+  {
+    "type": "null"
+  }
+]

changedOutput schema / properties / counts / anyOf

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

changedOutput schema / properties / receipt / anyOf

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

changedOutput schema / properties / results / anyOf

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

Changed1 schema field changedOct 19, 2026

addedInput schema / properties / client

Added value: +{
+  "description": "Set to gateway when your agent pays with Circle's Gateway client (@circle-fin/x402-batching) from a Gateway balance: Gateway-only endpoints are then not a caution, and Gateway options are recommended first.",
+  "enum": [
+    "gateway"
+  ],
+  "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/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"
+}

AddedSep 29, 2026

TDQS

A3.7/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 that: the $0.005 price, the accepted chains/assets, and critically 'Never pays the endpoints', which reassures the agent about side effects. It also discloses that the answer includes a signed EIP-191 receipt bound to the caller's arguments, a non-obvious property worth knowing before relying on the result.

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

Conciseness4/5

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

Cost and the core purpose are front-loaded in the first clause, and the remainder is dense but purposeful. The long enumeration of eight payment chains in a parenthetical is the one stretch that consumes space relative to its decision value.

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?

An output schema exists, so return values need not be detailed, yet the description still previews the go/caution/no_go verdicts, recommended payment option and totals. Pricing, payment rails and the receipt are all covered; only error behavior for invalid or unreachable URLs is left unspecified.

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 urls, client, method, max_usd and network in detail. The description adds no parameter-level meaning beyond repeating the 'up to 10' limit, leaving it at the baseline for a fully documented schema.

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: a pre-payment check across up to 10 x402 endpoints in one call, and even names the underlying REST route (GET /api/v1/preflight/batch). The batch scope ('up to 10 at once') implicitly separates it from the single-endpoint x402_preflight, but no sibling is named explicitly.

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

Usage Guidelines3/5

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

'For marketplaces and agents that weigh several services' gives an implied audience/context for use. There is no explicit when-not guidance and no routing to alternatives such as x402_preflight for a single endpoint or x402_preflight_deep for deeper analysis, so the agent must infer the choice.

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.