x402 Doctor

Have an x402 endpoint bought once: paid and delivered? ($0.25 via x402)

x402_delivery_check

Paid ($0.25 via x402 in USDC on Base, Solana, Monad, Polygon, Arbitrum, Avalanche, Algorand or Stellar, or in RLUSD on the XRP Ledger): 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, has TypeSafe's Jev judge whether it is what was paid for, 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.

Input Schema

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)

Output Schema

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

Schema Changelog

Changes observed during successful MCP inspections.

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

changedOutput schema / properties / receipt / anyOf

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

AddedOct 14, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Goes well beyond the annotations: discloses the caller's price ($0.25 across listed chains/RLUSD), that the tool itself spends up to $0.1 from its own wallet, that it returns a job id immediately and is asynchronous, that refusals happen pre-payment, and that a signed EIP-191 receipt bound to the arguments is returned. It also disambiguates that this is a purchase, not a read, which is consistent with readOnlyHint=false and openWorldHint=true.

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?

Dense but well ordered: price, what it does, async handoff, refusal conditions, endpoint equivalent, receipt. The long parenthetical chain list (Solana, Monad, Polygon, Arbitrum, Avalanche, Algorand, Stellar, XRP Ledger) is front-loaded clutter, though it does convey accepted payment rails.

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?

For an async paid job tool it covers everything an agent needs: cost, prerequisite gating, immediate job-id return, the polling sibling, and the receipt artifact. Since an output schema exists, the description is not obliged to describe return values, and it already names the job id and receipt semantics.

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 coverage is 100% and the two parameters already document the https/third-party/USDC-on-Base constraint on url and the GET-then-POST default for method. The description restates the payment-currency constraint but adds no new syntax or format 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.

Purpose5/5

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

States a specific, multi-step action on a specific resource: it buys the endpoint once with the listing's example input, validates the answer against the declared output schema, has a judge verdict it, and measures the on-chain charge. It also names the sibling it hands off to (x402_delivery_status) and the prerequisite check, so an agent can separate it from x402_diagnose / x402_preflight without opening schemas.

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 prerequisite conditions explicitly (must get a 'go' from the pre-payment check and be payable in USDC on Base, otherwise refused before payment) and the correct follow-up path (poll x402_delivery_status, free, result in minutes). It stops short of saying when to prefer x402_quick_check or x402_preflight_deep instead, so the alternative-selection guidance is incomplete.

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.