MCP registries aren't catalogs — they're control planes

Teams are building MCP registries the wrong way: as an index of available tools, discoverable by agents at runtime. That's the wrong mental model, and it produces the wrong architecture.

The distinction matters because the mental model determines what you build. A catalog is passive — it lists what's available. A control plane is active — it governs what can be used, by whom, under what conditions, and with what audit trail. When agents autonomously discover and invoke tools that modify external systems, the difference between those two architectures is the difference between a governed deployment and an uncontrolled one.

The InfoWorld analysis of enterprise MCP registries makes this concrete: the registry should function as core infrastructure owned by platform engineering, with governance over server builds, testing, deployment, and monitoring. That framing is exactly right. It means the registry isn't a convenience layer — it's the point where your organizational controls either exist or don't.

The practical requirements follow directly from the governance model. Per-user OAuth authentication, not shared credentials. Agents should act with user attribution baked in — every tool invocation traceable to a session, a user, a decision. Dynamic permission enforcement at tool invocation, not blanket access grants at registration time. The permission question isn't answered once when a server gets added to the registry; it's answered each time an agent tries to use it.

Supply chain vetting before a server gets exposed to agents — not after something goes wrong. This is the same logic that drove software bill-of-materials requirements into procurement conversations: you want to know what you're running before it's running in production, not after an incident surfaces the question. Version control with breaking-change signaling rounds this out, so agents aren't quietly invoking tool schemas that have changed beneath them.

Metadata quality is also underrated here. Agents pick tools based on descriptions. If those descriptions are thin or stale, agents make the wrong selection — and the error surfaces several steps downstream where it's harder to attribute. A real control plane includes semantic search over rich metadata: capabilities, side effects, latency characteristics, failure modes. That's not documentation overhead. It's the foundation for reliable agent behavior.

The public vs. private registry debate gets framed as a convenience question. It's actually a governance question. Public registries are still immature — they offer reach without the security primitives that enterprise deployment requires. Authentication is inconsistent. Vetting is minimal. Most organizations with serious deployment requirements end up forking an open-source implementation and extending it internally, which means accepting the operational cost of owning the full lifecycle.

There's a real debate in the field about whether enforcement belongs in the registry layer or in the underlying MCP servers. The honest answer is both — and in most current deployments, it's neither. Registries are being treated as indexes while the authentication and identity questions get deferred. The registry can express guardrails for orchestration layers to enforce, but it can't substitute for core security in the servers themselves. Both layers need to be governed.

The teams getting this right aren't building a better index. They're building institutional infrastructure — the kind that determines what agents can touch, on whose authority, and with what trail. MCP adoption is accelerating. The protocol debate is largely settled. What's not settled is who controls the production patterns — and the registry is where that gets decided.

For more insights on where AI, regulation, and the practice of law are headed next, visit www.kenpriore.com.