Start with the fact most write-ups miss. The official MCP Registry already launched, in preview, on 2025-09-08. It was still in preview in mid-2026. So the registry is not a future hypothetical to speculate about. It is running code with a specific design, and that design is exactly where the governance argument lives.
The registry answers questions of discovery. It does not answer questions of trust. Those are different jobs, one layer apart. Read the table as the whole argument.
| The real question | MCP Registry (discovery) | Colrows (governed execution) |
|---|---|---|
| Does this tool exist? | Yes, verified namespace | Not its job |
| Is the publisher who they claim? | Yes, DNS or GitHub verified | Not its job |
| Is the code safe? | No, scanning is delegated | Execution is sandboxed and governed |
| Can this user access the data behind it? | No | Yes, RBAC, RLS, masking before execution |
| Is the answer correct and auditable? | No | Yes, deterministic SQL, full audit trail |
The registry makes good tools discoverable. It makes bad tools discoverable at the same speed. The trust problem does not live in the directory. It lives one layer down, at execution.
The registry era is already here
The official registry is the centralized metadata repository for public MCP servers. It is backed by Anthropic, GitHub, PulseMCP, and Microsoft. It stores metadata, not code. A server.json record points to the real package on npm, PyPI, or Docker Hub. The API froze at v0.1 on 2025-10-24.
The design is hub-and-spoke. The central registry is meant to be consumed by downstream aggregators and marketplaces, not by host apps directly, through a shared OpenAPI spec. Those downstream registries are already running:
- The GitHub MCP Registry launched on 2025-10-24 with 44 servers, including HashiCorp Terraform, Notion, Unity, Firecrawl, and Stripe.
- The Docker MCP Catalog ships curated, signed images with SBOMs, built into Docker Desktop.
- Anthropic's Connectors Directory lists connectors for Claude.
This is the app-store moment for agent tools. The pattern is familiar, and so is the trap: an app store makes software easy to find, and finding is not the same as vetting.
What a registry actually verifies
Here is the crux. The registry verifies namespace ownership, not code safety.
Reverse-DNS names, such as io.github.user/server or com.example/server, are verified through GitHub OAuth or a DNS challenge. Only the legitimate owner can publish under that namespace. That is useful. It stops a stranger from squatting your brand. It does nothing else.
Security scanning is delegated to package registries and downstream aggregators. The central registry does no code review. Versions are immutable once published, semver is recommended, version ranges are prohibited, and one version is flagged latest. Moderation is manual takedown plus a denylist, with community flags filed as GitHub issues.
One line captures the whole gap: discovery is not publisher trust, publisher trust is not code trust, and code trust is not permission approval. A listing certifies none of code security, honest descriptions, correct permissions, or unchanged runtime behaviour. Do not read a green namespace badge as a safety guarantee.
Discovery without governance raises the blast radius
A discoverable-but-unsafe tool spreads faster than a hidden one. The exposure numbers are not hypothetical.
- Knostic scanned the internet on 2025-07-17 and found 1,862 MCP servers exposed. Of 119 it verified by hand, all 119 exposed their tool listings with no authentication.
- Elastic Security Labs tested MCP implementations on 2025-09-19. It found 43 percent had command-injection flaws and 30 percent allowed unrestricted URL fetching.
- Tool poisoning, coined by Invariant Labs on 2025-04-01, hides malicious instructions in a tool's description. The model reads and obeys them. The user never sees them. A registry that lists a tool cannot catch this, because the listing does not inspect behaviour.
Make discovery frictionless without governance and you have built a faster distribution channel for both good tools and bad ones. That is the exact failure mode we detail in MCP security risks: tool poisoning, prompt injection, and data leakage.
Registry versus gateway versus semantic layer
Three jobs get blurred in vendor decks. Say them separately.
- A registry gives you findability. Which tools exist, who published them, which version is latest.
- An MCP gateway gives you transport governance. Auth, rate limits, and audit on the tool call.
- A semantic execution layer gives you answer governance. Whether the query is correct, entitlement-scoped, and auditable.
A registry and a gateway both govern the door. Neither governs the query. That is the wedge, and it holds even for a well-run enterprise setup.
The honest objection: "We will run a curated private registry and a gateway, and be fine." Concede the first part. Curation and transport auth are necessary and good. The spec itself recommends a private registry for internal servers, and Cloudflare's enterprise reference architecture (2026-04-14) describes governed MCP portals with logging, policy enforcement, and per-server allowlists. Now the second part. None of that makes an LLM-generated query correct, and none of it makes the query per-identity safe. The accuracy cliff applies behind any registry: on Spider 2.0, top models solve only 10 to 17 percent of real enterprise text-to-SQL tasks. We cover that in the text-to-SQL accuracy cliff.
Fix the Context, Not the Model. A registry helps an agent find a data tool. It cannot give the agent the business context or the access rules to use it correctly. That job belongs to the layer behind the tool, not the directory in front of it.
Agents should discover governed capabilities, not raw endpoints
The most valuable registry-driven ecosystem points agents at governed capabilities, not raw SQL endpoints. A discovered data tool is only safe to have discovered if a governed layer sits behind it: business entities, approved metrics, valid joins, per-identity access, deterministic SQL, and audit.
That is what Colrows is. Agents find a Colrows tool through the registry and the gateway. Behind that tool, Colrows resolves intent against a typed semantic graph, proves every join, enforces RBAC, ABAC, and row and column policy at compile time, and emits dialect-perfect SQL across 16+ engines with a full audit trail. See how to build an MCP semantic layer server for the wire shapes, and why MCP is not enough without a governed semantic layer for the architecture case. The wider argument sits in the Company Brain series.
Frequently asked questions
Is there an official MCP registry?
Yes. The official MCP Registry launched in preview on 2025-09-08 and was still in preview in mid-2026. It is the centralized metadata repository for public MCP servers, backed by Anthropic, GitHub, PulseMCP, and Microsoft. It stores metadata, not code: a server.json record points to the real package on npm, PyPI, or Docker Hub.
What does the MCP registry actually verify?
Namespace ownership, not code safety. Reverse-DNS names such as io.github.user/server are verified through GitHub OAuth or a DNS challenge, so only the legitimate owner can publish under that namespace. Security scanning is delegated to package registries and downstream aggregators. The registry does no central code review.
Does a registry listing mean a tool is safe?
No. Discovery is not publisher trust, publisher trust is not code trust, and code trust is not permission approval. A listing certifies none of code security, honest tool descriptions, correct permissions, or unchanged runtime behaviour. It only certifies who owns the namespace.
What is the difference between a registry, a gateway, and a semantic layer?
A registry provides findability: which tools exist, who published them, which version is latest. An MCP gateway provides transport governance: auth, rate limits, and audit on the tool call. A semantic execution layer provides answer governance: whether the query is correct, entitlement-scoped, and auditable. A registry and a gateway govern the door. Only the semantic layer governs the query.
Should enterprises run a private MCP registry?
Yes, for internal discovery. The MCP specification recommends self-hosting a private registry, because the public registry does not host private servers. Cloudflare's enterprise reference architecture describes governed MCP portals with centralized logging, policy enforcement, and per-server tool allowlisting. A private registry still needs a governed execution layer behind it.
