Lumière PayCheck helps agents evaluate x402 endpoints and approve or deny payments before money is spent.
Check any x402 endpoint's trust verdict: score, grade, verdict, uptime, delivery-test status, wallet incidents, and independent-buyer support.
Check a specific payment before signing: returns allow/deny with reasons, verifying amount, cap, payTo wallet, network, and optional caution/verification/organic-share rules.
Report how a paid x402 call went, using a receipt or transaction hash, to help trigger re-tests.
Discover top trustworthy x402 endpoints ranked by safety and reliability.
Get catalog-wide statistics: monitored endpoint counts by verdict and last score time.
Get instructions and pricing for the full paid report, plus other paid checks like wallet risk, batch grades, and watch alerts.
Monitors x402 endpoint payout wallets and on-chain USDC payment activity on Solana, providing real usage metrics such as volume, distinct buyers, typical and largest payment, trend, and buyer concentration for endpoint verification.
Handles card-based subscription billing for Lumière PayCheck plans, enabling monthly billing and automatic account setup for Builder and Business plans.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Lumière PayCheck Check if this x402 endpoint is safe to pay 0.05 USDC before my agent pays it"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Check an x402 endpoint before your agent pays it.
AI agents now pay for APIs on their own with x402: an endpoint answers 402 Payment Required with a price, the agent pays in USDC, and gets the data. Nothing in that flow tells the agent whether the endpoint works, whether the price is right, or whether the payout wallet is the real one.
Lumière PayCheck answers those questions. It monitors every endpoint listed in the x402 Bazaar, grades each one, and gives your agent a plain verdict: proceed, caution, or avoid.
🌐 Live: https://lumierepaycheck.org · 🔌 MCP: https://lumierepaycheck.org/mcp?plans=1 · 📜 Terms
This repository is the public home for docs, examples, and feedback. The monitoring service itself is hosted and closed-source; the scoring formula is public (below).
Monitors every endpoint in the x402 Bazaar (the badge above shows the live count, which grows as new endpoints are listed) every 30 minutes: price quote, payout wallet, uptime, response time.
Flags hijack risk, without punishing normal rotations. Every payout-wallet change is checked against the seller's own wallet declaration, the seller's earlier wallets, and direct transfers between the old and new wallet. Confirmed rotations don't affect the grade; unexplained changes are avoid, then caution with human review. Sellers that use a new address per request are recognized automatically. How it works.
Spending rules for agents. Before paying, an agent asks "may I pay this endpoint this amount to this wallet?" and gets allow or deny with reasons.
Plans for teams. Scoped agent keys, daily/monthly spend limits, signed receipts your wallet verifies before paying, a replayable audit trail, and human review for anomalies. Details.
Identity and access for agents that pay. Like Entra ID and Intune, for AI agents:
Feature | What it does | Plans |
Payments outside PayCheck | Register an agent's wallet; every x402 payment it makes is matched to PayCheck's decisions, and payments made without asking, after a deny, or for more than approved alert you | All |
SDK enforcement |
| All |
Agent inventory | Status (active, idle, stale, expiring, frozen), last seen, client, compliance, risk; CSV | All |
Agent credentials | Opt-in: agents prove to sellers they belong to a verified company; sellers verify for free with | Business+ |
Access reviews, temporary limits, policy templates, risk score | Keep/change/revoke reviews with signed reports, time-limited limit raises, shared rule sets, explainable Low/Medium/High risk | Business+ |
SSO and SCIM | Sign in with Entra ID, Okta or Google Workspace; people provisioned automatically | Enterprise |
Screening for facilitators. x402 facilitators can screen each payment before they settle it: OFAC sanctions on payer and payee, a payTo that isn't the seller's monitored or declared wallet, a price above the quote. 10,000 checks a month free. Details.
Wallet risk. Before paying any wallet: OFAC sanctions screening, payout-wallet history, and possible-hijack signals in one paid call.
Alerts. Watch an endpoint and get signed webhook alerts when it breaks, changes wallet, or raises its price.
Paid delivery checks: small real payments that confirm an endpoint returns what it advertises. A failure only counts if a re-test about two hours later fails too, and requests an endpoint rejects for missing input never count.
Known-answer tests: values, not just shape. Uptime and schema checks can pass while an API returns the wrong number. For endpoints with a knowable answer, the verifier pays for a call with a known correct result, or compares against an independent live source, and checks the value itself. Sellers can add their own tests. How it works.
Real usage from on-chain data: actual x402 payments (USDC on Base and Solana) into each endpoint's payout wallet over 30 days: volume, distinct buyers, typical and largest payment, trend, and how concentrated the buyers are, counting only payments submitted by recognized facilitators.
Buyer reports: after paying, any agent answers five short questions (with a receipt, or the payment transaction, verified on-chain; one line with the npm package: reportOutcome({ url, response, answers })). Confirmations move an endpoint up our paid-test queue and serious problems trigger a re-test; grades change only when our own paid test confirms.
No accounts, no API keys. Free checks are free; paid features are paid per call with x402, the same way agents pay everything else.
Related MCP server: x402 Discovery & Trust MCP
Add the remote MCP server:
https://lumierepaycheck.org/mcp?plans=1Claude: Settings → Connectors → Add custom connector → paste the URL.
Cursor / others (mcp.json):
{ "mcpServers": { "lumiere-paycheck": { "url": "https://lumierepaycheck.org/mcp?plans=1" } } }Tools: check_payment, check_endpoint, report_outcome, top_endpoints, catalog_stats, get_full_report.
Prefer a local stdio server? packages/mcp-server runs the same tools on your machine (node server.js, or the repo's Dockerfile).
npm i x402-paycheck @x402/fetchimport { x402Client, wrapFetchWithPayment } from "@x402/fetch";
import { withPayCheck } from "x402-paycheck";
const fetchWithPay = wrapFetchWithPayment(fetch, withPayCheck(new x402Client().register(/* your scheme */)));Every payment is checked by PayCheck before it's signed; a "no" aborts it with the reason. Details: packages/x402-paycheck.
Then add one rule to your agent's instructions:
Before paying any x402 endpoint, call the Lumière PayCheck
check_paymenttool with the endpoint URL, the amount, and the payTo wallet from its 402 quote. Only pay ifallowis true. If it returnsallow: false, tell me the reasons instead of paying. After paying, callreport_outcomewith the receipt (or the url and payment tx) and short answers about whether you got what you paid for.
// Before paying any x402 endpoint, ask Lumière PayCheck.
const res = await fetch("https://lumierepaycheck.org/v1/check-payment", {
method: "POST",
headers: { "content-type": "application/json" },
body: JSON.stringify({ url: target, amount: quote.amount, payTo: quote.payTo }),
});
const decision = await res.json();
if (!decision.allow) throw new Error(`Not paying ${target}: ${decision.reasons.join("; ")}`);
// ...then pay with your x402 client as usualMore in examples/: TypeScript, Python, curl, webhook and receipt verification, a guarded payer, and plan purchase.
Route | Price | What it does |
| Free | Score, grade, verdict for one endpoint |
| Free | Spending rules: allow/deny a specific payment, with reasons |
| Free | Top-rated endpoints (no wallet incidents) |
| Free | Catalog size and verdict counts |
| Free | Sellers grouped by domain |
| Free | Real on-chain usage for one endpoint: volume, buyers, trend |
| Free | Every failed check in the last 7 days: time, result, HTTP status, and whether it counts |
| Free | Payout-wallet changes in the last 7 days and what the review found (declaration, seller history, on-chain link) |
| Free | Sellers: have your declared payout wallets read now |
| Free | Buyer report after paying (with a receipt or the payment tx) |
| Free | Sellers: dispute a grade, or see a dispute's status |
| Free | Public page for one endpoint, including its failed-check log |
| Free | Embeddable SVG badge |
| Free | Monitor health: what the last cycle saw, including which hosts blocked us |
| Free | Live service status and 90-day uptime |
| $0.005 | Full report: score breakdown, current quote, wallet and price history |
| $0.01 | Wallet risk before paying any wallet: OFAC sanctions, payout-wallet history, possible hijack |
| $0.01 | Score up to 100 endpoints in one call |
| $0.10 | 30 days of signed webhook alerts for one endpoint |
| The endpoint's price | Sellers: fund a paid re-test for an endpoint priced above $0.05 (details) |
| Free | Plan catalog |
| $9 · $49 | Buy, renew, or upgrade a plan with USDC (x402). Card: /subscribe |
| Plan | Authorize a payment with an agent key: allow / deny / review + signed receipt |
| Facilitator plan | Pre-settlement screening for x402 facilitators (10,000 checks/month free, then $1.50 per 1,000) |
Free routes allow 60 requests per minute per client, or 300 with a free API key sent in the x-paycheck-key header. The MCP server allows 300 tool calls per minute. Paid routes use x402 with USDC on Base or Solana (same price on both; on Solana the facilitator pays the fee). Lookups for endpoints we don't monitor return 404 and are never charged. Full reference: docs/api.md.
Free checks stay free. Plans add authorization for agents that spend money:
Builder | Business | Enterprise | |
Price | $9 / month | $49 / month | |
Scoped agent keys (allowed sellers, per-payment cap, expiry, revoke, rotate) | 3 | 25 | Custom |
Daily & monthly spend limits | ✅ | ✅ | ✅ |
Signed receipts for enforcement at the tool boundary | ✅ | ✅ | ✅ |
Replayable audit trail | 30 days | 1 year + CSV | Custom |
Human review for anomalies (new wallets, large amounts) | — | ✅ | ✅ |
Try Business free for 30 days at lumierepaycheck.org/trial: just an email, no card. Continue and your workspace and keys carry over; don't, and your agents keep the free allow/deny check.
Subscribe on the website with a card at lumierepaycheck.org/subscribe: billed monthly by Stripe, cancel anytime, and your account is set up automatically. Then manage everything (agent keys, limits, approvals, billing) at lumierepaycheck.org/account. Developers can also pay with USDC via x402 (prepaid 30 days, no auto-renewal).
The agent calls POST /v1/authorize before every payment and gets allow, deny, or review, with reasons. On allow it gets an Ed25519-signed receipt bound to that exact payment, and examples/guarded-pay.ts shows a payer that refuses to sign without one. Every decision can be replayed later to prove why it was made.
Want it set up for you? The setup service ($750 one-time) configures your agents, limits and approval rules, runs them for a 7-day watch-only week so nothing is blocked by surprise, then hands them over with a guide for your team. An optional monthly review is $250/month.
Full guide: docs/subscriptions.md · Subscribe: lumierepaycheck.org/subscribe · Pay with USDC: examples/subscribe.ts
Verdict | Meaning |
| Score ≥ 75, no wallet incidents, no failed deliveries |
| Score 40–74, or a payout-wallet change nobody could confirm after 24 hours |
| Score < 40, an unexplained payout-wallet change (first 24 hours, reverted, or not a declared wallet), or a failed paid delivery |
| Serves data without asking for payment |
| Fewer than 3 checks so far |
Deterministic and public. No one can pay for a better grade.
What each grade means: A we paid and it delivered, cleanly and reliably · B we paid and it delivered, with a caveat (reshaped vs its listing, a value warning, 80–95% uptime) · C probably works but unconfirmed (not paid-tested yet, needs its own sign-in, 50–80% uptime, an unconfirmed wallet change) · D doesn't work as listed, but you won't lose money (an error after payment with no charge, or the listing's own example input gets "not found") · F costs money or unsafe (took the money and failed, a payout-wallet incident, under 50% uptime). A/B = proceed, C/D = caution, F = avoid.
Uptime 40: how often the endpoint returns a valid payment quote over 7 days. Uptime sets the ceiling: an A needs at least 95% uptime and a passed paid test; under 95% the best grade is B, under 80% C, and under 50% F (avoid). These apply once there are 6 hours of checks
Latency 15: full points at ≤ 1 s median, zero at ≥ 5 s (checks run from one region, so distance isn't penalized). Checks that overlap a stall on our side don't count
Stability 25: drops with payout-wallet changes and price increases (each distinct higher price counts once, 8 points at most)
Delivery 20: share of paid test payments that returned what was advertised. Any 2xx counts as success; a 429, a firewall block or an async 202 after payment is neutral; empty result lists count as honest "no results"; a response fails only if it's an error status, empty when output is promised, not JSON when JSON is promised, or has none of the listing's fields (fields wrapped in data/result, or a list of the listed items, count). Endpoints failing a paid check are re-tested daily
Not yet paid-tested → scored on the other 80 points, rescaled, labeled so, and C at best: A and B mean a real paid test delivered
Caps: unexplained wallet change → F (unconfirmed after 24 hours → max 70, C); took the money and failed a paid test → F; error after payment with no charge, or the listing's own example input "not found" → D; needs its own sign-in → C; delivers but reshaped vs its own listing (fields nested elsewhere, a list where it shows one item, most example fields missing) → max 85 (B), with a note telling agents where to read the fields; minor gaps (an optional field, a content-type label) get a note only. Confirmed rotations and per-request addresses don't count
Verdicts: proceed means a real paid test delivered and the endpoint is reliable. Healthy endpoints not yet paid-tested are caution (delivery not yet confirmed), kept current by our free checks every 30 minutes
Value checks: on each paid test we also check the answer is plausible: it's about what we asked (symbol, address, URL), its "generated at" time is recent, and a major token's USD price is within 10% of the public spot price. A failed value check is a warning with a B cap, never avoid
A failed payment caused on our side never counts against a seller
Fair to sellers: only real problems count. Checks where our monitor is rate-limited or blocked by a firewall (Cloudflare, Vercel, AWS WAF, Akamai, DataDome, Imperva, Sucuri) are blocked; requests the endpoint rejects before quoting (400/405/415/422) are mismatch; failures caused by our own network are monitor_error. Quotes on payment networks we can't read yet (e.g. nano:mainnet) are unsupported_network. None of these count. Network errors and 502/503/504 are retried once. We send at most 2 requests at a time and about 1 per second to any one host, and pause a host that asks us to slow down
Transparent: every failed check is listed on the endpoint's public page and at /v1/failures, with timestamps. Our user agent is lumiere-paycheck-prober/1.0 (+https://lumierepaycheck.org) if you want to allowlist it
Every monitored endpoint has a public page and a badge that updates on its own:
[](https://lumierepaycheck.org/e?url=YOUR_ENDPOINT_URL_ENCODED)Declare your payout wallets so a rotation is never mistaken for a hijack, and a hijack is caught on the first check: publish {"payTo": ["0xYourWallet"]} at https://<your-host>/.well-known/paycheck.json (or a DNS TXT record at _paycheck.<your-host>: payto=0xYourWallet), then POST /v1/declaration with your endpoint URL. Details.
Think a grade is wrong? Open a Grade dispute with the endpoint URL. A bot replies within a minute with the endpoint's current score and failure log, and queues a paid re-test automatically. When the re-test has run, the bot posts the result (grade before and after) and closes the issue if the grade is fixed. Free re-tests cover endpoints priced at $0.05 or less; for pricier ones the bot posts a link to fund a test at the endpoint's own price. Rules and limits: seller guide.
From the team behind PayCheck: done-for-you follow-up for small businesses. agents.lumierepaycheck.org
Most small businesses aren't short on work; they're short on follow-up. Lumière Agents does the chasing, in the owner's name and voice:
Agent | What it does |
Invoice chaser | Polite reminders 1, 7 and 14 days after the due date, one statement per customer, from the business's own email address. Understands replies ("paid", "check's in the mail", "we'll pay Friday", a dispute) and hands the rest to the owner. |
Quote follow-up | Friendly check-ins 2, 5 and 12 days after each quote. Any reply stops it and goes straight to the owner; a revised quote restarts it. |
Missed-call text-back | Every missed caller gets a text from the business's own number within a minute (9am–8pm), with the booking link and a hand-off to the owner. |
Paperwork chaser | Collects subcontractors' insurance certificates through an upload link, checks them against the owner's checklist, and asks for renewals before they expire. |
Receipt chaser | Every Monday, asks whoever holds the company card for the missing receipts (a phone photo is enough) and files them; the bookkeeper gets a monthly copy. |
How it stays safe
You approve every email at first. Each agent has an "Approve before sending" / "Send automatically" switch the owner can flip any time.
Facts come from your books, not the AI. Amounts, invoice numbers and dates are inserted by code; the AI only writes the wording, and a draft with made-up numbers or pressure is replaced by a plain template.
Polite by design. Business hours only, no US holidays, weekly limits per contact, STOP and unsubscribe always work, and nothing is sent to someone who asked to stop.
Your accounts stay yours. Works with QuickBooks (read-only) or any spreadsheet; emails come from your own address and texts from your own Twilio number. Each client's data is walled off in the database and stored files are encrypted.
Pricing: one agent $200/month + $750 setup; each extra agent $100/month + $400 setup; all five $500/month + $2,000 setup. Cancel any time. Guides · Get started
Lumière Agents is a separate, hosted product from Lumière LLC; its code isn't in this repository.
Lumière PayCheck is an independent project operated by Lumière LLC (Connecticut, USA). It is not affiliated with Coinbase, the x402 Foundation, the Bazaar, or any seller. Scores are automated assessments, not guarantees, endorsements, or financial advice.
Questions, feature requests, and grade disputes: open an issue and pick the matching form. Building an agent that pays with x402? I'd love to hear what it needs.
Guides for evaluating and running Lumière PayCheck: overview, features, pricing, getting started, administrator guide, integration guide, and FAQ. PDFs: Enterprise plan guide (everything included) and 4-page overview.
What personal information we collect and who else handles it: PRIVACY.md (also at lumierepaycheck.org/privacy). Live usage numbers: lumierepaycheck.org/stats. Service status and uptime: lumierepaycheck.org/status.
How keys, payments, and data are protected, including current limitations: SECURITY.md (also at lumierepaycheck.org/security). Report vulnerabilities privately via GitHub security advisories or hello@lumierepaycheck.org.
The documentation, example code and packages in this repository are MIT licensed. The Lumière PayCheck hosted service and its source code are not part of this repository and are not covered by this license.
"Lumière PayCheck", "Lumière" and the Lumière PayCheck logo are trademarks of Lumière LLC. The MIT license covers the code, not the names or logo: forks are welcome, but please give them a different name.
Get an overview of the whole monitored x402 catalog: how many endpoints are monitored, how many fall into each verdict (proceed, caution, avoid, free, insufficient_data), and when scores were last computed. Use it for context or reporting, for example to tell a user how much of the x402 ecosystem passes checks. It says nothing about any single endpoint: use check_endpoint for one endpoint, top_endpoints for a ranked list, or check_payment before paying. Read-only, free, no parameters.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint, so the safety profile is covered. The description still adds value by stating it is free, takes no parameters, returns aggregate-only data, and exposes the specific verdict categories returned. It stops short of describing pagination or freshness guarantees, which keeps it off 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well front-loaded: purpose first, then usage, then scope exclusions and alternatives. The 'Read-only, free, no parameters' tail slightly repeats the readOnlyHint annotation and the empty schema, but it is short and mildly useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters, no output schema, and annotations covering the safety profile, the description supplies everything needed: what is measured, the categorical breakdown, and explicit sibling routing. No relevant gap remains for an agent deciding whether to call it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the baseline is 4. The description confirms 'no parameters' and instead uses the space to describe the output shape (verdict buckets, last-computed time), which is the useful information here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Get an overview of the whole monitored x402 catalog') and enumerates exactly what is returned: endpoint counts, per-verdict breakdowns, and last-computed timestamps. It explicitly positions itself against siblings ('It says nothing about any single endpoint'), so an agent can distinguish it without opening another schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly names when to use it ('for context or reporting') and routes to the correct alternatives with the selecting condition: check_endpoint for one endpoint, top_endpoints for a ranked list, check_payment before paying. Nothing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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
| 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnly, idempotent, non-destructive, openWorld), and the description adds real operational context beyond them: it is free, monitoring refreshes every 30 minutes and includes real test payments, brand-new endpoints may return insufficient_data, and endpoints outside the catalog return monitored: false. These are exactly the edge behaviors an agent needs before trusting a verdict.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the return contents, then routes to alternatives, then closes with edge cases and a docs link. Six dense sentences, but each carries either routing logic or behavior not present in structured fields; nothing is filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description's enumeration of return fields (score, grade, verdict vocabulary, uptime, buyer counts) is doing necessary work. Combined with the fresh-endpoint and not-in-catalog edge cases and the API docs pointer, an agent has everything needed to call and interpret this correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single 'url' parameter is already fully documented in the schema, including the 'exactly as the agent will call it' requirement and an example. The description adds no further parameter meaning, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Get the trust verdict for one x402 endpoint') and enumerates the concrete outputs (score, grade, verdict, uptime, delivery-test status, payout-wallet incidents, buyer count). It explicitly separates itself from check_payment and top_endpoints, so an agent can route without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit when-to-use ('when you're deciding whether an endpoint is trustworthy at all, before you have a price quote'), an explicit alternative with its trigger condition (check_payment when you already have the 402 quote and are about to pay), and a third route for discovery (top_endpoints). Nothing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Decide whether a specific x402 payment should go through: returns allow true/false with reasons. Checks the endpoint's trust verdict, that the amount is within your cap and not above the monitored price, and that the payTo wallet matches the one we've observed (catches swapped or hijacked wallets). Optionally (minOrganicShare) it also requires that enough of the seller's volume comes from independent buyers. Intended for right before a payment, with the amount, payTo, and network from the endpoint's 402 quote; allow is true only when every rule passes. Use check_endpoint instead if you only want an endpoint's grade without a quote in hand. Read-only and free; it doesn't make or block the payment itself. When allow is false, the reasons list explains why. API docs: https://github.com/Book0fEli/lumiere-paycheck/blob/main/docs/api.md
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Full URL of the x402 endpoint you are about to pay, including path | |
| payTo | No | Wallet address from the endpoint's 402 quote | |
| amount | No | Amount about to be paid, atomic units (USDC has 6 decimals: 10000 = $0.01) | |
| network | No | Network from the quote, e.g. eip155:8453 | |
| hasAccess | No | true if you have your own account, API key or sign-in with this seller. For endpoints that need the seller's sign-in on top of x402, allowCaution/requireVerified then don't block (we couldn't confirm delivery only because we can't sign in). | |
| maxAmount | No | Your hard cap for this payment in atomic units (USDC: 1000000 = $1). Payments above it are denied. | |
| allowCaution | No | false = deny endpoints with a caution verdict too, not just avoid (default true) | |
| minOrganicShare | No | Optional, 0-1: deny sellers where less than this share of 30-day volume comes from independent buyers (e.g. 0.5). Not applied to sellers whose buyers haven't been reviewed yet. | |
| requireVerified | No | true = only allow endpoints that delivered on a real test payment (default false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnlyHint, idempotentHint and destructiveHint=false, but the description adds real behavioral context: it is free, it neither executes nor blocks the payment, allow is true only when every rule passes, and false results come with a reasons list. It does not describe latency, caching, or failure modes when the endpoint is unknown, so it is short of 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the decision and its return semantics, then the rule set, then exclusions and limitations. It is on the longer side with a docs URL appended, but nearly every sentence carries information the agent needs and there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, and the description compensates by describing the return contract (allow boolean plus reasons list) and the semantics of a false verdict. Combined with the rule enumeration and defaults noted in the schema, an agent has everything needed to call and interpret this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are already documented and the baseline is 3. The description goes modestly beyond by explaining how the inputs combine into a decision (trust verdict, amount within cap and not above monitored price, payTo matching the observed wallet, optional minOrganicShare gate) and by naming the 402-quote provenance for url/payTo/amount/network.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific decision verb and resource ('Decide whether a specific x402 payment should go through') and immediately describes the output shape (allow true/false with reasons). It explicitly distinguishes itself from the sibling check_endpoint by noting that this one is for when a 402 quote is in hand. An agent can pick it without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit timing ('Intended for right before a payment, with the amount, payTo, and network from the endpoint's 402 quote') and an explicit alternative with the selecting condition ('Use check_endpoint instead if you only want an endpoint's grade without a quote in hand'). It also clarifies the tool does not itself make or block the payment, removing a likely agent misconception.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get instructions for buying the detailed paid report on one x402 endpoint (score breakdown, current price quote, wallet and price history, test-payment results). Returns the report URL, price, and network; it doesn't buy the report itself. The report is an x402 endpoint that your agent pays with any x402 client. Use it only when the free check_endpoint result isn't enough and the user wants the full history. The response also lists the other paid x402 checks (wallet risk, batch grades, watch alerts), paid the same way. Endpoints we don't monitor return 404 on the report URL and are never charged. API docs: https://github.com/Book0fEli/lumiere-paycheck/blob/main/docs/api.md
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Full URL of the x402 endpoint you want the paid report for, including path |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, and the description adds non-obvious behavior: the tool explicitly does NOT buy the report, payment happens via any x402 client, and unmonitored endpoints return 404 and are never charged. These are valuable operational disclosures beyond the annotations, though rate limits or timeout behavior are unmentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Key facts (what it returns, that it doesn't purchase, when to use it) are front-loaded, and the trailing link is useful. The sentence enumerating other paid checks is somewhat tangential but still helps an agent understand the payment ecosystem, so it mostly earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description compensates by specifying the return payload (report URL, price, network) and by covering payment mechanics, failure mode (404), and usage gating. Nothing an agent needs to call this correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single url parameter is fully documented, so the schema does the work. The description only implicitly constrains it to monitored x402 endpoints, adding minimal meaning 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource and immediately corrects the misleading name: it returns instructions/URL/price for a paid report rather than the report itself. It also contrasts with the free sibling check_endpoint, so an agent can route correctly without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit gating is given: 'Use it only when the free check_endpoint result isn't enough and the user wants the full history.' It names the alternative tool and the condition that selects it, leaving little to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
After paying an x402 endpoint, report whether you got what you paid for. Free, optional, and open to every agent: send the receipt from a Lumière PayCheck allow decision (paid plans), or the endpoint url plus the payment's transaction hash (anyone; we verify the payment on-chain, Base or Solana, within 24 hours). Answer the short questions in answers: gotResponse, matchedListing (yes/partly/no), charged (as_quoted/more/twice), dataUsable (yes/unsure/no), wouldPayAgain. Reports never change a grade by themselves: confirmations from independent buyers move the endpoint up our paid-test queue, and serious problems (nothing came back, charged more or twice) trigger a re-test; only our own paid test changes the grade. One report per payment; the seller's own wallet can't report on itself.
| Name | Required | Description | Default |
|---|---|---|---|
| tx | No | The payment's transaction hash (Base 0x...) or Solana signature | |
| url | No | The endpoint you paid (with tx, when you have no receipt) | |
| answers | No | ||
| outcome | No | Optional shortcut instead of answers: delivered = usable; problem = error, empty, wrong or overcharged | |
| receipt | No | The receipt from a Lumière PayCheck 'allow' decision (paid plans). Or send url + tx instead. | |
| problems | No | Short descriptions, e.g. 'missing field price', 'HTTP 500' | |
| httpStatus | No | HTTP status the endpoint returned after payment, e.g. 200 or 500 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations give the safety profile (readOnlyHint=false, idempotentHint=true, openWorldHint=true), and the description adds substantive context beyond them: submissions are free and optional, on-chain verification of the payment (Base or Solana) happens within 24 hours, reports never change a grade by themselves, and only confirmation streaks or serious problems (no response, charged more/twice) trigger a re-test.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the purpose and packed with useful detail, but the parenthetical-laden sentences run long and pack several distinct rules into single clauses, which slightly hurts scanability. Little is wasted, though.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 7-parameter nested write tool with no output schema and zero required params, the description covers eligibility, submission paths, and downstream consequences well. It does not say what the tool returns to the reporter (e.g., an acknowledgement or verification status), which is the one remaining gap with no output schema to cover it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is already 86%, but the description still adds meaning: it clarifies the receipt-vs-url+tx alternation and interprets the answer fields ('matchedListing (yes/partly/no)', 'charged (as_quoted/more/twice)') and the outcome shortcut. This maps the semantics rather than merely restating the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('report whether you got what you paid for' after paying an x402 endpoint) and is clearly distinguishable from siblings like check_endpoint and check_payment, which read rather than submit. An agent knows immediately this is the write-a-feedback path.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use it (after paying an x402 endpoint), the two accepted submission paths (PayCheck receipt vs url + tx) and who each is for, plus the constraint 'one report per payment' and that a seller's own wallet cannot self-report. It also explains what reports do and do not affect.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the x402 endpoints that are currently safest to pay (verdict proceed or caution, no payout-wallet incidents), best first, with score, grade, verdict, and whether a real test payment was delivered. Use it to discover reliable endpoints or pick between providers. To evaluate one specific endpoint use check_endpoint; to approve a payment use check_payment. Read-only and free; rankings update as monitoring runs (every 30 minutes).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many endpoints to return, 1-50 (default 10) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so 'read-only' is partly redundant. The description still adds real context beyond them: the tool is free, rankings refresh on a 30-minute monitoring cadence, and 'safest' is operationally defined as proceed/caution verdicts with no payout-wallet incidents.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences, front-loaded with purpose and eligibility, followed by routing and operating constraints. No filler; every sentence contributes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description enumerates the returned fields (score, grade, verdict, test-payment status) and defines the ranking predicate. Combined with the alternatives routing and freshness note, an agent has everything needed to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a single optional 'limit' parameter whose bounds and default are fully documented in the schema. The description adds no syntax or format detail beyond that, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('List') and resource ('x402 endpoints that are currently safest to pay'), defines the inclusion criteria (verdict proceed or caution, no payout-wallet incidents), the ordering ('best first'), and the returned fields. An agent can distinguish it from check_endpoint or check_payment without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly names the use cases ('discover reliable endpoints or pick between providers') and routes to alternatives with conditions: check_endpoint for one specific endpoint, check_payment to approve a payment. Both the when-to-use and when-not-to-use are covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0catalog_statscheck_endpointcheck_paymentget_full_reportreport_outcometop_endpointsScored across 6 tools
Each tool has a clearly distinct purpose, and the descriptions explicitly cross-reference each other (check_endpoint vs check_payment vs top_endpoints, etc.) to route the agent correctly. check_endpoint for one endpoint, check_payment before paying, top_endpoints for discovery, catalog_stats for aggregate, report_outcome for post-payment, get_full_report for paid deep-dive — no meaningful overlap.
Four tools follow a clean verb_noun pattern (check_endpoint, check_payment, report_outcome, get_full_report) with snake_case throughout. top_endpoints and catalog_stats are noun-phrase/collections, a minor deviation from the verb-led convention but still readable and predictable.
Six tools is well-scoped for an endpoint-trust service, with each tool earning its place across discovery, single-endpoint checking, payment gating, reporting, and catalog context. No redundancy or padding.
The surface covers the lifecycle: discovery (top_endpoints), inspection (check_endpoint), payment approval (check_payment), feedback (report_outcome), context (catalog_stats), and paid deep-dive (get_full_report). Minor gaps remain — batch grading, wallet-risk, and watch alerts are only advertised as paid x402 endpoints rather than exposed as MCP tools, and there's no direct free history retrieval.
x402 payment firewall + Agent Credit Bureau. Invoice/verify/score via RLUSD on XRPL.
Pay-per-call x402 services for agents: risk scoring, DeFi, wallet and market data.
x402 payment security and pre-execution transaction risk screening for autonomous AI agents.
Verify x402 payment endpoints before an AI agent pays: scam scan, on-chain checks, trust scores.