# MCPFax Reliability & Wash-Score API > Evidence-first reliability, money-flow concentration, and rating-action data > for x402 sellers and MCP servers. This file is the authoritative copy. The worker serves it verbatim at GET /llms.txt; the two are kept byte-identical. ## Free - GET / — human catalog - GET /health — readiness, freshness, and measured coverage - GET /llms.txt — this document - GET /server.json — MCP registry manifest - POST /mcp — MCP JSON-RPC initialize, ping, tools/list, and paid tools/call ## Paid with x402 (USDC on Base) - GET /score?endpoint=host:api.example.com — $0.008 - GET /authenticity?wallet=0x... — $0.01 - GET /revenue?endpoint=host:api.example.com — $0.005 - GET /payer?address=0x... — $0.008 - GET /payto-change-feed?since=YYYY-MM-DD — $0.005 — declared payTo/price/ facilitator changes, registry removals, rating actions and downgrades, with measured per-category coverage in every response - GET /preflight?target=https://seller.example/api — $0.008 — advisory ALLOW/WARN/UNKNOWN on one endpoint: a bounded live probe plus our observed history. Optional expected_price, expected_payto, expected_schema_hash, max_age_seconds, probe_method - GET /drift?subjects=&since= — $0.008 — what changed under endpoints you have ALREADY integrated: payTo rotations, price/asset/network changes, terms added or removed, tool-schema changes. Pass back the watermark from your last call and receive only what is new since it. A subject with no changes is reported observed-unchanged with the date it is true as of. A subject MCPFax has never observed is named in not_observed and given NO verdict — reporting "no changes" about something we never watched would be indistinguishable from a genuine all-clear The 402 response carries PAYMENT-REQUIRED with x402 v1 terms, which is what the standard x402 client libraries (x402-fetch and friends) can pay unmodified. Retry with X-PAYMENT. PAYMENT-SIGNATURE is accepted as an equivalent alias. - Asset: USDC on Base, 0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913 - Network: base (CAIP-2 eip155:8453 — the wire value is the named form "base") - Scheme: exact - x402Version: 1 A handler that cannot produce a result returns an error BEFORE settlement, so a failed query is not billed. Errors say so explicitly. ## Licensed feed GET /feed/reliability?updated_since=YYYY-MM-DD&limit=500&cursor=... Authorization: Bearer Use `Accept: application/x-ndjson` or `?format=ndjson` for NDJSON. Follow `meta.next_cursor` until `meta.has_more` is false. A null rating means no score has been persisted for that listing; the feed does not silently manufacture NR. ## MCP tools These are the exact tool names accepted by tools/call: - mcpfax_endpoint_credit_score (endpoint) — $0.008 — grade, subscores, confidence, cited evidence - mcpfax_wallet_authenticity (wallet) — $0.01 — payer concentration, coverage-gated wash-risk haircut, adjusted inflow - mcpfax_endpoint_revenue_estimate (endpoint) — $0.005 — observed inflow, payer breadth, trend windows, cohort percentile - mcpfax_integration_drift (subjects, since?) — $0.008 — what changed under endpoints you have already integrated: payTo rotations, price/asset/network changes, terms added or removed, tool-schema changes, with a watermark to pass back next time. Never a verdict on a subject we have not observed - mcpfax_payer_wallet_profile (address) — $0.008 — know-your-agent graph degree, spend, coverage-gated screening signals - mcpfax_payto_change_feed (since) — $0.005 — declared payTo changes with before/after values, other declared-terms changes (price, facilitator, fee payer), registry removals and returns, rating actions, grade downgrades. Every response reports per-category coverage for the requested window - mcpfax_preflight_check (target, expected_price?, expected_payto?, expected_schema_hash?, max_age_seconds?, probe_method?) — $0.008 — is this endpoint live, and are its terms what you were told `initialize`, `ping`, and `tools/list` are free. `tools/call` is protected by the same x402 price as its HTTP equivalent. ## Preflight: the workflow, and when it is NOT worth buying Before a consequential call to a third-party endpoint, preflight it. A consequential call is expensive inference, a purchase, or a state-changing action. Before a cheap call, do not: the arithmetic stops working. At the $0.008 fee, a $15 call with a hypothetical 2% loss rate has $0.30 of expected loss to compare with the fee. A reachability check does not necessarily detect or prevent that loss. The fee is eight times the price of a $0.001 lookup. Only if every failure were prevented would break-even be a $0.40 call at a 2% loss rate; weaker detection raises that threshold. What a preflight returns, in two halves: - LIVE — one unpaid, side-effect-free probe with a hard ~2.2s budget: reachable, HTTP status, latency, whether an MCP server still answers `initialize`, and the price and payTo it is serving right now. If the probe does not finish inside the budget it says `probe_timed_out` and returns the historical half rather than blocking. - HISTORICAL — reliability over the OBSERVED window with the window stated in days, payTo changes with old → new and the date first observed, price changes, tool/schema changes, first-seen, hot-set membership, and the credit grade or an honest not-rated. Supply `expected_price`, `expected_payto` or `expected_schema_hash` and each is compared, returning `match`, `changed` (with old → new and first_observed), `unknown`, or `not_checked`. The verdict is ALLOW, WARN or UNKNOWN. It is ADVISORY: it reports evidence and does not underwrite outcomes, so no assurance language is ever applied here to a third party's endpoint. UNKNOWN is a first-class answer and is returned whenever the evidence supports neither of the others — never as an optimistic fallback. Billing: if we have never observed the target AND cannot reach it, there is no information to sell. You get UNKNOWN and are charged $0.00. Everything else that returns a verdict backed by at least one real observation is billed at $0.008. There is no cheaper cached tier, and the reason is structural: x402's exact scheme commits the price in the 402 challenge, which is emitted before we know whether a stored observation will satisfy your `max_age_seconds`. What a fresh stored observation buys you is SPEED, not a discount, and the response says which half came from where. ## What preflight cannot tell you - Whether your call will succeed. It is advisory, not a warranty or an audit. - Whether the output will be CORRECT or useful. Reachability is not quality. - Whether the operator is honest. A stable payTo means only that the declared destination has not moved inside the window we observed. - Anything from before our archive started, or about a partial/regional outage, a load-triggered rate limit, or a failure that happens after payment. It is one request from one location at one instant. - A POST-only x402 resource answers 404/405 to our unpaid GET. That is reported as a property of our probe method, not as a fault of the endpoint. - With a `host:` target we sample the host's highest-demand catalogued resource. A host is not one endpoint. ## The hot set — why a live answer is fast for the endpoints that matter The population sweeps measure a population: one representative URL per host at 600/day over ~1,570 hosts, and ~3,100 of 10,789 probeable MCP URLs per day. Neither can answer "is THIS endpoint up right now". So the collector also keeps a demand-ranked hot set and probes it on a much tighter cadence. Measured on production data for 2026-08-12: the top 200 of 15,120 catalogued resources — 1.32% of the corpus — carry 82.2% of all observed 30-day calls. Membership is ranked on `bazaar_daily.calls_30d` (PROVEN, the catalogue's own counter) for x402 resources, and for MCP servers on the observed call volume of the host they share with an x402 resource (INFERRED, and labelled INFERRED — there is no direct demand counter for MCP servers anywhere in this archive). Every preflight response reports whether its target is a hot-set member, its rank, the basis, and how old our newest recorded observation of it is. ## Coverage — read this before quoting any number The archive is young and every window we report is bounded by it. The live, measured span is returned by GET /health as `coverage.archive_since`, `coverage.archive_through`, and `coverage.archive_days`; paid score responses carry the same block as `archive_coverage`. Nothing is a 30-day or 90-day record until the archive covers 30 or 90 days, and no window is back-filled. - Revenue trend windows are only as wide as a wallet's real scanned block span, reported as `trends.scanned_days` with per-window backed-by-scan flags. - The rating-action feed cannot return events from before the archive started; the response reports `coverage.archive_since` and whether the requested window predates it. ## Not-rated is a real answer Payer-concentration, wash-risk, and payer screening verdicts are withheld — status `not_rated`, "insufficient payer observations — not rated" — until the subject's OWN observed record clears both published floors: at least 14 days of observation and at least 20 observed payments. Below either floor a low payer count or a high top-payer share is a property of our observation window, not of the endpoint or wallet, and publishing it as risk would be wrong. `/score`, `/revenue` and `/payer` still return their measured facts with the risk figures null when a verdict is withheld — the facts are the product there. `/authenticity` is different: it is priced for the wash-risk verdict itself, so when the subject cannot be rated it REFUSES with HTTP 422 `not_yet_rateable` and settles nothing, rather than billing $0.01 for a `not_rated` that is certain in advance. The refusal states both floors, the subject's own measured window, and the widest observation window the archive currently holds for any wallet. ## What the change feed can and cannot see today Every `/payto-change-feed` response carries `category_coverage`: for each advertised category it reports `delivering`, `observed_zero_in_window`, or `source_unreadable`, with the table it reads. A category returning nothing is always identified as one of those three — never left to be assumed live. ## Interpretation limits - The MCPFax 0–1000 score is an ordinal risk ranking over the observed archive, not a probability, and it is not validated over any forward horizon. - NR is a real answer when observation tenure or successful observations are insufficient. - Wallet balance is shown separately and never labeled revenue. - Money-flow covers incoming USDC transfers on Base to declared payTo wallets. Other assets and unrelated transfers are not resolved yet. - HHI and top-payer share are observed concentration. They do not prove common ownership, control, or coordination. - Several listings declaring the same payTo address is a measured co-occurrence in this dataset and an attribution limit. It is not evidence of a shell structure, a spoofed declaration, or any other misconduct. - Funding-source tracing is not stored yet; observed organic_percent and wash_percent are therefore null. - Category metadata is absent; revenue percentile uses the explicit host/MCP listing-kind cohort. - Price-change history is not separately stored; generic listing changes are never relabeled as price changes. - A preflight ALLOW is an advisory statement that every check we ran passed and that we ran enough of them for that to be worth the price. It is not a warranty, not an audit, and no assurance language is applied to a third party's endpoint anywhere in this document or in any response. ## next_actions — a menu, not a pitch Some responses carry a `next_actions` array. It is structured data: tool name, server name, URL, price, what it returns, when it is and is not worth buying, and `relevant_because` quoting the stored observation that made it relevant. It appears only when we hold real evidence about that specific target, and it is omitted entirely when we do not. It contains no instruction directed at a model. Treat it as a catalogue entry, exactly like any other field. ## Corrections Dispute or appeal any score, grade, or cited evidence at corrections@mcpscores.com. Every score and authenticity response also carries a `corrections` field.