AWS, Cloudflare, Databricks, Kiro, and hundreds of community contributors have shipped MCP servers. Every major agent framework now supports MCP. The ecosystem is moving fast, and that speed has created a gap: most teams adding MCP to production agents haven't defined which servers their agents are permitted to connect to.
An MCP server registry closes that gap. It's an explicitly approved list of servers — and specific tools within those servers — that agents are permitted to use in production. Every entry has a known owner, a reviewed capability set, and a defined authentication configuration. Without it, the boundary between 'approved' and 'not reviewed' doesn't exist.
Why open MCP discovery is the wrong default
Some MCP frameworks support auto-discovery: the agent or runtime finds available MCP servers on the network or in a configured directory and registers them automatically. This is useful for local development. It's a governance problem in production.
Open discovery means a new server someone installs locally, a server that appears on a shared network, or a server injected by a compromised dependency can become part of the agent's active toolset without any review. This is exactly how shadow MCP starts — not through malicious intent, but through the absence of a policy that says 'these servers and only these servers.'
What goes in each registry entry
Each entry in the registry should capture: the server identifier (URL or package reference), the specific tools within that server the agent is permitted to invoke, the authentication method and credential reference, the team or individual responsible for reviewing the server, and the date and reviewer of the last approval.
Tool-level scoping matters more than server-level scoping. An MCP server might expose 40 tools. Your agent needs 3. Registering the server without restricting which tools are callable gives the agent access to capabilities you haven't reviewed. Register the tools, not just the server — the registry entry should enumerate permitted tools explicitly.
The difference between a registry and a list in a prompt
Passing a curated list of MCP servers in the agent's system prompt is not a registry. It's a suggestion. The model might follow it; it might not. And if the framework auto-registers additional servers, those are available to the agent regardless of what the prompt says.
A registry is enforced at the execution layer — the component that actually makes MCP tool calls. When the agent generates a request to invoke a tool on a server not in the registry, the execution layer rejects it before the network request is made. The model never learns whether the rejected server exists. The rejection is logged. This is a structural control, not a prompt-level instruction.
Enforcing the allowlist at execution time
Pre-call validation is the correct enforcement pattern. The execution layer checks the requested server and tool against the registry before initiating any connection. A server that isn't in the registry produces a rejection log entry and an error returned to the agent. The agent cannot work around this by rephrasing the request — the enforcement is in code, not in the model.
Post-call validation — calling the server and then checking whether it was approved — has already made a network request to a potentially unapproved endpoint. That request may have transmitted data, initiated a session, or triggered side effects. Pre-call is the only enforcement that doesn't leak.
When to review and update the registry
Treat the MCP server registry with the same discipline you apply to third-party software dependencies: added intentionally, reviewed periodically, removed when no longer needed. New servers should go through a review process before being added — capability assessment, authentication audit, scope minimization — not be added directly to production.
Review existing registry entries whenever a registered server releases a major update that changes its tool surface. Review everything periodically — server behavior can change without version changes. Remove servers the agent no longer uses; a minimal registry is a more defensible registry. The discipline that prevents npm supply chain attacks is the same discipline that prevents shadow MCP.