Lumière PayCheck

Check an x402 endpoint

check_endpoint

Read-onlyIdempotent

Get the trust verdict for one x402 endpoint: score (0-100), grade (A-F), and verdict (proceed, caution, avoid, free, or insufficient_data), plus uptime, delivery-test status, payout-wallet incidents, and how many independent buyers stand behind the seller's buyer wallets (we count customers, not wallets). Use it when you're deciding whether an endpoint is trustworthy at all, before you have a price quote. When you already have the 402 quote (amount and payTo) and are about to pay, use check_payment instead: it runs this same check and also verifies the price and wallet. To discover good endpoints rather than check a known one, use top_endpoints. Read-only and free; reflects monitoring every 30 minutes and real test payments, so a brand-new endpoint may return insufficient_data. Endpoints not in the catalog return monitored: false. API docs: https://github.com/Book0fEli/lumiere-paycheck/blob/main/docs/api.md

Input Schema

TableJSON Schema

Name	Required	Description	Default
`url`	Yes	Full URL of the x402 endpoint including path, exactly as the agent will call it, e.g. https://api.example.com/v1/price.

Output Schema

TableJSON Schema

Name	Required	Description
`url`	Yes	The endpoint checked
`auth`	No	Present when our paid test was refused for want of the seller's own sign-in (no money was taken). Have access? Send hasAccess: true to check_payment.
`page`	No	Public page with the full history
`grade`	No	A delivered cleanly; B delivered with a caveat; C unconfirmed; D doesn't work as listed, no money lost; F costs money or unsafe; ? with too little data
`score`	No	0-100; null for free resources
`advice`	No	What the verdict means for paying it, naming the actual cause
`buyers`	No	Who is really behind the seller's buyers. Never changes the grade.
`points`	No	The points behind the score: uptime /40, speed /15, stability /25, delivery /20
`probes`	No	Checks counted in the last 7 days
`values`	No	Automatic value checks on the latest paid response. A warning caps the grade at B, never avoid.
`listing`	No	Present only when the latest paid response differs from the listing's example or schema. The data is delivered.
`reasons`	No	Every factor behind the grade, most important first: paid tests (with date and what came back), uptime, speed, payout wallet, price, listing
`verdict`	Yes	proceed \| caution \| avoid \| free \| insufficient_data
`delivery`	No	verified = a real test payment was delivered; failing (see advice: an error after payment that didn't collect the money is D/caution; taking the money and failing is F/avoid); or unverified
`forTeams`	No	Short note about team plans (per-agent keys, spend limits, audit trail)
`headline`	No	One sentence: the verdict and its main reason
`decidedBy`	No	Which rule set the final score (e.g. a ceiling from a failed paid test), or that it came straight from the points
`monitored`	Yes	false if the endpoint isn't in the monitored catalog
`payToMode`	No	fixed, or per_request when the seller issues a new payout address per request
`uptimePct`	No	Share of checks in the last 7 days that returned a valid payment quote
`withdrawn`	No	Present when the endpoint was withdrawn by its seller or is gone from the Bazaar: no longer for sale, don't pay it.
`testedWith`	No	Present when the latest passing paid test needed a sign-in or extra input: a seller-provided test account, a wallet sign-in, or the seller's declared test request.
`buyerReports`	No	What real buyers reported after paying. Never changes the grade; confirmations move the endpoint up our paid-test queue.
`exampleInput`	No	Present when the listing's own example input got 'not found' when we paid (no money taken): use real input.
`requiredInput`	No	Present when our paid test was refused for want of a header or input the listing doesn't document (no money taken).
`valuesChecked`	No	Latest paid check also passed known-answer value tests
`walletIncidents`	No	Unexplained payout-wallet changes
`walletUnconfirmed`	No	Recent wallet changes nobody could confirm yet

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedOct 10, 2026

changedOutput schema / properties / advice / description

Previous value: -"What the verdict means for paying it"New value: +"What the verdict means for paying it, naming the actual cause"

addedOutput schema / properties / decidedBy

Added value: +{
+  "description": "Which rule set the final score (e.g. a ceiling from a failed paid test), or that it came straight from the points",
+  "type": "string"
+}

addedOutput schema / properties / headline

Added value: +{
+  "description": "One sentence: the verdict and its main reason",
+  "type": "string"
+}

addedOutput schema / properties / points

Added value: +{
+  "additionalProperties": false,
+  "description": "The points behind the score: uptime /40, speed /15, stability /25, delivery /20",
+  "properties": {
+    "delivery": {
+      "type": "string"
+    },
+    "speed": {
+      "type": "string"
+    },
+    "stability": {
+      "type": "string"
+    },
+    "total": {
+      "type": "string"
+    },
+    "uptime": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "uptime",
+    "speed",
+    "stability",
+    "delivery",
+    "total"
+  ],
+  "type": "object"
+}

addedOutput schema / properties / reasons

Added value: +{
+  "description": "Every factor behind the grade, most important first: paid tests (with date and what came back), uptime, speed, payout wallet, price, listing",
+  "items": {
+    "additionalProperties": false,
+    "properties": {
+      "at": {
+        "description": "Date of the event it's based on (YYYY-MM-DD)",
+        "type": "string"
+      },
+      "effect": {
+        "description": "positive, neutral or negative",
+        "type": "string"
+      },
+      "factor": {
+        "description": "data, delivery, uptime, speed, wallet, price, listing, values, access or withdrawn",
+        "type": "string"
+      },
+      "limit": {
+        "description": "The ceiling this factor puts on the grade, e.g. \"F (max 39)\"",
+        "type": "string"
+      },
+      "text": {
+        "description": "What we found, in plain words (paid-test results include the date and what came back)",
+        "type": "string"
+      }
+    },
+    "required": [
+      "factor",
+      "effect",
+      "text"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}

Changed1 schema field changedOct 7, 2026

addedOutput schema / properties / withdrawn

Added value: +{
+  "additionalProperties": false,
+  "description": "Present when the endpoint was withdrawn by its seller or is gone from the Bazaar: no longer for sale, don't pay it.",
+  "properties": {
+    "at": {
+      "type": "string"
+    },
+    "note": {
+      "type": "string"
+    },
+    "reason": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "at",
+    "reason",
+    "note"
+  ],
+  "type": "object"
+}

Changed2 schema fields changedOct 6, 2026

addedOutput schema / properties / requiredInput

Added value: +{
+  "additionalProperties": false,
+  "description": "Present when our paid test was refused for want of a header or input the listing doesn't document (no money taken).",
+  "properties": {
+    "documented": {
+      "type": "boolean"
+    },
+    "note": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "documented",
+    "note"
+  ],
+  "type": "object"
+}

addedOutput schema / properties / testedWith

Added value: +{
+  "additionalProperties": false,
+  "description": "Present when the latest passing paid test needed a sign-in or extra input: a seller-provided test account, a wallet sign-in, or the seller's declared test request.",
+  "properties": {
+    "how": {
+      "type": "string"
+    },
+    "note": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "how",
+    "note"
+  ],
+  "type": "object"
+}

Changed3 schema fields changedOct 5, 2026

changedOutput schema / properties / delivery / description

Previous value: -"verified = a real test payment was delivered; failing (see advice: an error after payment that didn't collect the money is caution, not avoid); or unverified"New value: +"verified = a real test payment was delivered; failing (see advice: an error after payment that didn't collect the money is D/caution; taking the money and failing is F/avoid); or unverified"

addedOutput schema / properties / exampleInput

Added value: +{
+  "additionalProperties": false,
+  "description": "Present when the listing's own example input got 'not found' when we paid (no money taken): use real input.",
+  "properties": {
+    "found": {
+      "type": "boolean"
+    },
+    "note": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "found",
+    "note"
+  ],
+  "type": "object"
+}

changedOutput schema / properties / grade / description

Previous value: -"A-F, or ? with too little data"New value: +"A delivered cleanly; B delivered with a caveat; C unconfirmed; D doesn't work as listed, no money lost; F costs money or unsafe; ? with too little data"

Changed1 schema field changedOct 5, 2026

addedOutput schema / properties / auth

Added value: +{
+  "additionalProperties": false,
+  "description": "Present when our paid test was refused for want of the seller's own sign-in (no money was taken). Have access? Send hasAccess: true to check_payment.",
+  "properties": {
+    "note": {
+      "type": "string"
+    },
+    "required": {
+      "description": "true: the seller needs its own sign-in (account, API key or wallet signature) on top of x402",
+      "type": "boolean"
+    }
+  },
+  "required": [
+    "required",
+    "note"
+  ],
+  "type": "object"
+}

Changed3 schema fields changedOct 5, 2026

addedOutput schema / properties / buyerReports

Added value: +{
+  "additionalProperties": false,
+  "description": "What real buyers reported after paying. Never changes the grade; confirmations move the endpoint up our paid-test queue.",
+  "properties": {
+    "confirmed": {
+      "description": "Buyers (customers or wallets) who reported a usable response in 7 days",
+      "type": "number"
+    },
+    "note": {
+      "type": "string"
+    },
+    "ourTestQueued": {
+      "description": "Our own paid test is queued for this endpoint",
+      "type": "boolean"
+    },
+    "problems": {
+      "description": "Buyers who reported a problem in 7 days",
+      "type": "number"
+    },
+    "windowDays": {
+      "type": "number"
+    }
+  },
+  "required": [
+    "confirmed",
+    "problems",
+    "ourTestQueued",
+    "windowDays",
+    "note"
+  ],
+  "type": "object"
+}

changedOutput schema / properties / delivery / description

Previous value: -"verified = a real test payment was delivered; failing; or unverified"New value: +"verified = a real test payment was delivered; failing (see advice: an error after payment that didn't collect the money is caution, not avoid); or unverified"

addedOutput schema / properties / values

Added value: +{
+  "additionalProperties": false,
+  "description": "Automatic value checks on the latest paid response. A warning caps the grade at B, never avoid.",
+  "properties": {
+    "checked": {
+      "description": "true: automatic value checks passed on the latest paid test",
+      "type": "boolean"
+    },
+    "warning": {
+      "description": "A value that looks wrong (wrong subject, stale data, price far from the public spot price)",
+      "type": "string"
+    }
+  },
+  "required": [
+    "checked"
+  ],
+  "type": "object"
+}

Changed3 schema fields changedOct 5, 2026

changedOutput schema / properties / listing / description

Previous value: -"Present only when the latest paid response doesn't match the listing's example. The data is delivered; the grade is capped at B until the listing matches."New value: +"Present only when the latest paid response differs from the listing's example or schema. The data is delivered."

addedOutput schema / properties / listing / properties / capped

Added value: +{
+  "description": "true: the data is reshaped vs the listing (nested, list vs item), grade capped at B; false: a minor gap, warning only",
+  "type": "boolean"
+}

changedOutput schema / properties / listing / properties / sellerFix / description

Previous value: -"What the seller changes to lift the B cap"New value: +"What the seller can change"

Changed1 schema field changedOct 5, 2026

addedOutput schema / properties / listing

Added value: +{
+  "additionalProperties": false,
+  "description": "Present only when the latest paid response doesn't match the listing's example. The data is delivered; the grade is capped at B until the listing matches.",
+  "properties": {
+    "matchesExample": {
+      "description": "false: the paid response differs from the seller's own example",
+      "type": "boolean"
+    },
+    "sellerFix": {
+      "description": "What the seller changes to lift the B cap",
+      "type": "string"
+    },
+    "warning": {
+      "description": "How the real response differs, and where to read the fields",
+      "type": "string"
+    }
+  },
+  "required": [
+    "matchesExample",
+    "warning",
+    "sellerFix"
+  ],
+  "type": "object"
+}

Changed1 schema field changedOct 4, 2026

addedOutput schema / properties / buyers

Added value: +{
+  "additionalProperties": false,
+  "description": "Who is really behind the seller's buyers. Never changes the grade.",
+  "properties": {
+    "buyerWallets30d": {
+      "description": "Buyer wallets that paid the seller in 30 days",
+      "type": "number"
+    },
+    "estimated": {
+      "description": "true when counted from a sample of buyers",
+      "type": "boolean"
+    },
+    "flags": {
+      "description": "coordinated_wallets, self_funded, concentrated_buyers, shared_operator, estimated, partial_lookup",
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "independentBuyers30d": {
+      "description": "Independent buyers behind the seller's buyer wallets in 30 days (wallets funded from one source count as one)",
+      "type": "number"
+    },
+    "organicShare": {
+      "description": "0-1: share of 30-day volume from independent buyers",
+      "type": "number"
+    },
+    "reviewed": {
+      "description": "false until the seller's buyers have been reviewed (the biggest sellers are reviewed daily)",
+      "type": "boolean"
+    }
+  },
+  "required": [
+    "reviewed"
+  ],
+  "type": "object"
+}

First observedSep 30, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Goes well beyond the annotations by disclosing that the check is free, that it reflects monitoring every 30 minutes and real test payments, that a brand-new endpoint may return insufficient_data, and that uncataloged endpoints return monitored:false. These are concrete behavioral traits an agent needs to interpret 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?

Front-loaded with purpose and return values, then usage routing, then caveats and a docs link. It is fairly long but nearly every sentence carries decision-relevant information; the trailing API docs URL is the only mildly extraneous element.

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, yet the description still helpfully previews the verdict vocabulary and edge-case return values. Combined with the weaker alternatives routing, an agent has everything needed to call this correctly and interpret results.

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?

One parameter with 100% schema description coverage, so the schema already explains the url format and example. The description adds no parameter-level guidance beyond what the schema provides, matching the baseline 3 when the schema carries the semantic load.

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 states a specific verb and resource ('Get the trust verdict for one x402 endpoint') and enumerates the returned signals (score, grade, verdict, uptime, payout incidents, buyer counts). It is instantly distinguishable from siblings like check_payment and top_endpoints.

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

Usage Guidelines5/5

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

Explicit routing: use this 'before you have a price quote,' use check_payment 'when you already have the 402 quote... and are about to pay,' and use top_endpoints 'to discover good endpoints rather than check a known one.' Both when-to-use and named alternatives are covered.

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

All Lumière PayCheck 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.

Check an x402 endpoint

Input Schema

Output Schema

Schema Changelog

TDQS

Glama MCP Gateway

Resources