x402 Doctor

Status of a delivery check (free)

x402_delivery_status

Read-only

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.

Input Schema

Name	Required	Description	Default
`id`	Yes	The job id x402_delivery_check answered with

Output Schema

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

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedOct 29, 2026

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

changedOutput schema / properties / result / anyOf

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

AddedOct 14, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds valuable context beyond that: the call is free, it exposes a state machine (awaiting_payment, queued, done), and on completion returns paid_and_delivered, the outcome, the on-chain measured charge and the transaction. No contradictions.

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?

Front-loads the key points (free, status, source tool) and packs the state list efficiently into one sentence. It is dense and slightly run-on, but every clause earns its place.

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?

Given a single required parameter, an output schema, and read-only annotations, the description covers what an agent needs: the source of the id, the possible states, and what becomes available once done. Polling cadence or retry guidance is not stated, but it is not essential to call correctly.

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 schema itself explains the single `id` parameter as 'The job id x402_delivery_check answered with'. The description reinforces where the id comes from but adds no syntax or format details beyond the schema. Baseline 3 is appropriate.

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 verb and resource: retrieves the status of a delivery check. It distinguishes itself from sibling x402_delivery_check by saying the check was 'ordered with' that tool, and lists the possible states, so an agent can tell exactly what this returns.

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?

Clearly implies when to use it: after ordering a check via x402_delivery_check (or the GET endpoint). It does not explicitly state exclusions or when to prefer another sibling, but the context is unambiguous.

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.