Mirror
A sync loop walks every page of the upstream MCP registry on a fixed cadence and canonicalises each server. The baseline read API is shape-compatible with upstream /v0, so your existing MCP clients point at it and work unchanged.
RCX-Registry · verifiable MCP subregistry
Verifiable discovery for MCP.
A tamper-evident mirror of the official MCP registry. Every server the upstream registry lists, plus proof: verified publishers, and a signed, hash-chained history you can replay yourself. Drop-in shape-compatible with the clients you already run.
registry.snapshotcadence · hourly
- servers
- ~17,439
- merkle_root
- b3:9f4c…e21a
- signer
- vault-transit · ed25519
- prev
- crown:8802…6f11
✓ signed · chain intact
illustrative — shape of a snapshot receipt
~17,439
servers mirrored from the upstream MCP registry
every change
a signed, hash-chained CROWN receipt — replayable end to end
DNS · GitHub
two ways for a publisher to prove they own their namespace
How it works
Mirror. Verify. Receipt.
A discovery surface existing clients can use unchanged, a way for publishers to prove who they are, and a signed history so nobody has to take the registry’s word for it.
Verify
Publishers prove control of their namespace — DNS TXT challenge, or GitHub OAuth for io.github.* — then declare RCX capability metadata for their servers, surfaced to clients under _meta.org.rcxprotocol.registry.
Receipt
Every state change — a snapshot, an enrichment, a rights verification — is an ed25519-signed, hash-chained CROWN receipt minted via Vault Transit. The registry’s entire history is independently verifiable, not merely trusted.
Why this exists
Namespace ownership is solved. History isn’t.
MCP registries verify who a publisher is at the moment they publish. Nothing about that makes the registry’s history tamper-evident, and nothing catches a server that turns malicious after it was approved. The last year of incidents is that gap, over and over:
postmark-mcp · Sept 2025
An npm-published MCP server ran clean for 15 versions, then shipped an update that BCC’d every email it handled to the author’s server. ~300 organisations pulled it before disclosure. A rug-pull that per-version receipts and history diffing would have surfaced.
CVE-2025-54136 · "MCP rug pull"
A tool definition was mutated after a client had already approved it — the classic bait-and-switch. Approval at publish time says nothing about what the server does next.
CVE-2025-6514 · mcp-remote
Command injection in a connector with ~437,000 downloads. Distribution scale is exactly why a verifiable chain of custody matters: one bad version reaches a lot of machines fast.
MCPTox · poisoned tool descriptions
Adversarial instructions hidden in tool descriptions reached a 72.8% success rate against agents. What a server advertises is attacker-controlled text — it should be attributable to a verified publisher.
Microsoft advisory · June 2026
An estimated ~200,000 vulnerable MCP instances in the wild. The ecosystem grew faster than its trust story. Namespace ownership is solved; tamper-evident history is not.
RCX-Registry’s job is the part the others skip: a signed, replayable chain of custody over the whole registry, so a rug-pull, a silent mutation, or a tampered record shows up as a broken chain — not a surprise in production. See how verification works →
Point your clients at a registry that can prove itself.
The read API is shape-compatible with upstream, so switching is a URL change. Publishers claim a namespace in minutes and get a receipted history for free.