Mirror
The production API serves the mirrored dataset in the upstream /v0 response shape. Its configured sync loop is currently failing at Vault signing before it can persist a snapshot, so the corpus must not be treated as fresh signed evidence.
RCX-Registry · verifiable MCP subregistry
Verifiable discovery for MCP.
A mirror of the official MCP registry with a frozen signed-evidence format and byte-exact conformance vectors. The read API preserves the response envelope your existing clients expect; production signing and publisher writes are fail-closed.
registry.snapshotformat example · no live snapshot
- servers
- 17,000+
- snapshot_merkle_root
- b3:9f4c…e21a
- signer
- test-vector key · ed25519
- previous_snapshot_hash
- 8802…6f11
example signature · flat set digest linked
illustrative values — production receipts are not yet served over /v0
17,000+
servers mirrored from the upstream MCP registry
frozen format
signed-receipt specification plus byte-exact test vectors
writes closed
publisher verification is unavailable pending trust hardening
How it works
Mirror. Verify. Receipt.
A discovery surface existing clients can use unchanged, a publisher-proof design that is currently closed in production, and signed change-record formats frozen in the public specification.
Verify
All public publisher verification and declaration writes currently fail closed. DNS needs a reviewed passport-to-domain binding and server-owned audit time; GitHub also needs bound OAuth state, org proof, and production credentials.
Receipt
The repository freezes canonical receipt formats, signing semantics, and byte-exact test vectors. Production signs each snapshot with Vault Transit ed25519 and persists the receipt. Artifact retrieval and a normative public-key discovery endpoint remain explicit follow-up work.
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 goal is the part the others skip: signed snapshot and enrichment evidence, attributable publisher rights, and byte-exact formats that independent implementations can reproduce. Today the reproducible deliverables are the format, code, and vectors; production signing, proof binding, and public retrieval remain visibly incomplete. See how verification works →
Point your clients at a registry that publishes its evidence format.
The read API is shape-compatible with upstream, so switching is a URL change. Publisher onboarding remains unavailable until its proof and attribution model passes review.