x402 MCP Registry continuity methodology
The reader accepted 1,887 sealed Official MCP Registry observations across 19 dated captures. An unsuccessful newest source receipt makes every page unavailable; it never becomes a plausible empty catalogue.
This methodology keeps source scope, comparison rules, and privacy exclusions mechanical so a later page cannot silently widen them.
Feed-level privacy and legality boundary
The SQL reader selects only exact registry identity, snapshot date, a bounded detail projection, content hash, and collection time. It never selects raw JSON, wallet or client addresses, endpoint headers, descriptions, repository handles, price observations, on-chain reputation events, or mcp.so records. That exclusion happens before template code can access a value.
Comparison rule
Versions are compared only when the same exact registry name appears on two captured dates. We do not join by a similar name, repository, endpoint, or operator. A publication event uses the Registry's own published date. We publish volume and version history, never a score or a claim that one server is safer than another. The methodology treats every missing comparison as unavailable.
Capture boundary
This is not a complete registry census. The source request is capped at 100 latest-version search results, so absence is not evidence that a server is unregistered. Names, versions, statuses, and dates reproduce Registry Data; they are not security reviews or endorsements. The captured window is 2026-07-22 through 2026-08-10. The Registry remains authoritative.
Source receipt
The newest successful response was 93,087 bytes, collected 2026-08-10T12:50:11+00:00. Source hash: dc0b7065607c0f14cd622cf3a081502f06acb3fa6010e2c54c5e3c0886527b08. Collection batch seal: 8dacf6d277cad387e6b75620814e1e990f1a2cb05b39cd33ce4911ec0a34f97d.
Official MCP Registry API query · Registry terms and CC0 dedication · Return to the continuity-report offer.