…/publisher
Publisher-declared capability metadata plus verification method and enrichment receipt hash. Public writes to this block are disabled until caller authentication and signing are complete.
Positioning
A drop-in subregistry.
The MCP registry documents an open subregistry model: implement the read shape, add value through custom _meta fields, no approval step. RCX-Registry preserves that envelope and reserves an RCX metadata namespace. The live mirror read dataset works today, and each sync tick mints a signed snapshot. Publisher extensions remain gated until authenticated proof, signed-artifact persistence, and public receipt verification ship.
Shape-compatible
Your existing clients work unchanged
The baseline read API mirrors the upstream /v0 surface field-for-field. Anything that already speaks to the official MCP registry speaks to this one. Optional RCX metadata appears inside the existing envelope only when its producing pipeline has supplied it.
| GET /v0/servers | List servers — cursor pagination, limit |
| GET /v0/servers/{name}/versions | List versions for a server |
| GET /v0/servers/{name}/versions/{version} | Fetch one version |
The namespace contract
Everything RCX adds lives under one _meta key
Subregistries extend server entries through _meta, and RCX keeps its entire footprint inside org.rcxprotocol.registry. A client that ignores it sees a plain upstream entry; a client that reads it can consume extensions when present.
{
"server": {
"name": "io.example.com/my-mcp-server",
"version": "1.4.0"
},
"_meta": {
"io.modelcontextprotocol.registry/official": {
"status": "active",
"isLatest": true
},
"org.rcxprotocol.registry/publisher": {
"publisher_rights_verified": true,
"verification_method": "dns_txt",
"enrichment_receipt_hash": "blake3:8802…6f11"
}
}
}…/auto
Registry-derived enrichment fields and their receipt hash. This is additive metadata; a mirrored entry need not carry the block.
Point a client here
VS Code, by policy
VS Code exposes an enterprise policy, McpGalleryServiceUrl, that repoints its entire MCP gallery at any spec-compliant endpoint. Because our /v0 matches the shape, this works today — one policy value moves a whole fleet onto a compatible read API.
// VS Code enterprise policy (device management)
// Repoints the whole MCP gallery at a compatible registry read API.
{
"McpGalleryServiceUrl": "https://registry.rcxprotocol.org"
}Any client that lets you configure the registry base URL points here the same way. And because there is a self-contained /openapi.json, OpenAPI-to-MCP tooling can wrap the registry itself as a server — one more surface, no extra work from us.
Freshness
Configured sync model
Production serves the mirrored dataset and, on each completed sync tick, mints and persists a snapshot receipt signed with Vault Transit ed25519 over the flat, sorted BLAKE3 set digest.
Mirror
The configured loop is designed to walk every upstream page and mint a signed snapshot over the flat, sorted BLAKE3 set digest named snapshot_merkle_root. It is not completing in production.
Soft-delete
When a server disappears upstream it is soft-deleted with a 30-day retention window — a removal is recorded, never a silent gap.
Enrichment
The implementation can refresh already-seeded declarations on a 24-hour cadence, but no public declaration route is available and complete signed artifacts are not persisted or returned by the public API.
Same servers. Same shape. Now with attributable metadata.
Repoint a client for mirror reads. Publisher verification remains closed pending trust hardening.