--- name: x402-list description: Discover x402 payment services and on-chain-verified facilitator settlement volume via the x402-list directory. Use when a user or agent needs to find an API/service that accepts x402 (HTTP 402 stablecoin) payments, compare services by reliability and price, check service uptime/health, or look up which x402 facilitators have real on-chain settlement volume. --- # x402-list ## What x402-list is x402-list is a directory of services that accept x402 payments. Its distinctive, defensible data is **on-chain-verified settlement volume per facilitator**, not self-reported figures. Listed services are continuously health-monitored for uptime, response time, and live status. This MCP server is a read-only wrapper over the public x402-list API; it needs no API key. ## Money units (read this first) **All `*_usd` fields are decimal US dollars and are used as-is. There is no cents conversion.** For example `min_price_usd: 0.001` means one tenth of a cent, and `volume_usd_all: 1542635.84` means about 1.54 million dollars. The service-detail `pricing[].price` field is an atomic on-chain token amount (a uint256 string), NOT dollars; only `price_usd` is the dollar figure. Never rescale either one. ## Tool guide (when to use each) - `search_x402_services`: find and filter services by free-text query, category, network, and status; sort by newest, uptime, cheapest, or endpoint count. Start here for discovery. Add `signable: true` when you intend to pay with a standard x402 client and want only services whose last observed 402 envelope carries the EIP-712 domain parameters needed to sign (`signable: false` returns the opposite set; a service whose latest assessment has not measured that check matches neither value, so omit the parameter to see it). - `get_service`: deep-dive one service by slug. Returns every endpoint, per-endpoint USD pricing, uptime windows (24h/7d/30d/90d), accepted networks, and the settlement asset. - `find_best_service`: get a ranked recommendation for a need, computed server-side (GET /api/v1/best). Ranks mostly by reliability, x402 compliance and price (status, verified, uptime_24h, response time, USD price), filtered by category and network, with a small (~10%) weight on per-service on-chain traction (settlement volume, tx count, unique buyers - a conservative undercount). Traction never dominates; shared-payout or unmeasured-network services stay neutral. The compliance term is the share of deterministic conformance checks the service passes, capped at 0.6 (the floor of the C band) when at least one of its EVM routes is missing the EIP-712 domain parameters a standard x402 client needs in order to sign a payment; that cap is why the returned `ranking_version` is 2, so scores stored under generation 1 are not comparable with these. - `check_health`: live status. With no slug, a directory-wide snapshot (online/degraded/offline/unknown counts plus per-service status). With a slug, that service's status, uptime windows, response time, consecutive failures, and recent daily uptime snapshots. - `get_facilitator_volumes`: the headline metric. Per-facilitator settlement volume (24h/7d/30d/all) in USD, transaction counts, and an `on-chain` vs `listed` verification flag. Optional daily timeseries and per-chain breakdown. - `assess_services`: PAID ($0.25 USDC on Base, x402). A fresh on-demand AI comparison of a shortlist of listed services for a stated need. This is a pass-through: it never holds keys, never signs, and never settles. Call it once without `payment_signature_b64` to receive the x402 payment challenge verbatim, sign accepts[0] client-side with your own wallet, then call again with the same question and services plus `payment_signature_b64` to receive the report and a settlement receipt. It charges only for the fresh reasoning, never to read an already-computed assessment (that stays free on `get_service`); a run that cannot be produced answers before settling, so you are never charged, and there is no refund. Optionally add a `probe` target `{ slug, endpoint_path? }` to also test one listed service live: when the server has probing armed the price becomes $0.25 plus that endpoint price X (non-refundable), and the report gains a `probe_report` block with a verdict and truncated extracts, never the verbatim third-party body. ## The honesty guard Keep two on-chain signals distinct. **Facilitator volume** (`get_facilitator_volumes`) is aggregated per facilitator and is the headline metric. **Per-service traction** (the `traction` block on a service, and a ~10% weight inside `find_best_service`) is measured over that service's own payTo via recognized settlers and is a deliberate **conservative undercount** - never an upper bound, never an estimate. When a payTo is shared across services (operator-level volume, `shared_payout: true`) or sits on a network we do not measure, there is no per-service figure and the service stays neutral in the ranking; do not present shared or unmeasured volume as a single service's revenue. If asked "which service does the most volume", show the measured `traction` where it exists, flag the undercount and any shared/unmeasured caveat, and offer facilitator volumes (via `get_facilitator_volumes`) for the ecosystem aggregate. ## Typical workflows - "Find me a cheap, reliable image-generation x402 API on Base" -> `find_best_service` with category, network `Base`, your need as `q`, and `prefer: cheapest`, then `get_service` on the top pick. - "Is service X healthy?" -> `check_health` with `slug: X`. - "Which x402 facilitators are real (have on-chain volume)?" -> `get_facilitator_volumes` with `timeframe: 30d`, then read each `verification` flag.