The registry problem nobody talks about
Every engineering blog post about MCP focuses on the fun part: connecting an AI agent to a new tool and watching it work. What they skip is what happens three months later, when your organisation has 40 MCP servers, nobody knows which ones are still maintained, three teams have independently built connectors to the same API, and a security audit is asking for a list of every tool your AI agents can access. That is the MCP server registry problem.
An MCP server registry is the organisational answer to this problem: a centralised, authoritative catalogue of every MCP server in your environment, who owns it, what tools it exposes, who is authorised to use it, and what its operational status is.
What an MCP server registry contains
A well-designed MCP server registry is more than a list of endpoints. Each registered server entry should contain:
- Server identity — name, owner team, description, and the environment it belongs to (dev, staging, prod)
- Tool manifest — the list of tools the server exposes, with descriptions and parameter schemas
- Access policy — which agent roles and user identities are authorised to invoke this server and its tools Authentication configuration — the OAuth scopes, OIDC claims, and credential type required to call this server
- Operational metadata — health status, version, last deployment date, deprecation notices
- Approval status — whether the server has passed security review for production use
This information serves two audiences simultaneously. Agents use it at runtime to discover what tools are available to them, without hardcoded configuration. Security and platform teams use it to audit the tool landscape, enforce approval workflows, and respond to incidents.
How agent discovery works
One of the most powerful properties of a centralised registry is runtime tool discovery. Instead of hardcoding tool configurations into agent code — which requires a redeployment every time a new MCP server is added — agents query the gateway registry at startup and receive the list of tools they are authorised to use.
The flow works like this: the agent authenticates with the gateway, the gateway resolves the agent's identity and role, the registry returns the tool manifest for all MCP servers that role is authorised to access, and the agent proceeds with its task using the discovered tools. When a new MCP server is registered and assigned to the agent's role, the agent gains access on its next startup — with no code changes.
Developer impact: Runtime discovery eliminates the coordination overhead of keeping agent tool configurations in sync with MCP server changes. One registry update propagates to all agents immediately.
The shadow MCP server problem
Without a registry enforcing an approval gate, shadow MCP servers proliferate. A developer wires an agent to an internal database API over the weekend, skipping the security review because the deadline is tight. The connection works, the project ships, and six months later that developer has left the company. Nobody knows the connection exists. The database API it calls was deprecated and is now returning stale data. And the agent, still happily calling the shadow server, is making decisions based on that stale data.
This is not a hypothetical. It is the standard pattern of ungoverned MCP adoption, and it is exactly what an approval-gated registry prevents. When every MCP server must be registered before agents can discover it, shadow servers become visible. The registry becomes the organisation's single source of truth for agent tool access, and 'what tools does our AI fleet have access to?' becomes a query rather than an investigation.
Registry vs environment isolation
A mature registry supports environment namespacing: separate entries for the dev, staging, and production versions of the same MCP server, with different access policies for each. A developer building a new agent can access the dev MCP servers freely. Promoting to staging requires a reviewer approval. Reaching production MCP servers requires satisfying the full security policy.
This mirrors the environment promotion workflows that platform teams already use for application code. Bringing the same discipline to MCP server access prevents the common failure mode where agents tested in a lenient dev environment go to production with insufficiently scoped tool access.
Virtual MCP servers: aggregating tools logically
A useful pattern that registries enable is virtual MCP servers. Rather than exposing individual physical MCP servers directly to agents, the registry can group related tools from multiple servers under a logical virtual endpoint. A 'CustomerDataVirtualServer' might expose the get_customer tool from the CRM MCP server, the get_orders tool from the orders MCP server, and the get_support_history tool from the ticketing MCP server — all through a single virtual endpoint.
Agents that need customer context call one virtual server rather than three physical ones. When the underlying physical servers change — a migration, a version upgrade, an API change — only the virtual server mapping needs updating. The agents are unaffected.
TrueFoundry MCP Gateway
TrueFoundry's MCP Gateway provides a centralised registry and discovery system that serves as the single source of truth for all MCP servers in your organisation. Agents discover authorised tools at runtime through the registry without hardcoded configurations. The registry supports environment grouping (dev-mcps, staging-mcps, prod-mcps) with separate RBAC rules per environment. Approval workflows control which roles can access each server before it reaches production. Virtual MCP servers allow tool aggregation across physical backends. TrueFoundry ships with prebuilt registry entries for Slack, GitHub, Confluence, Sentry, and Datadog — ready to enable with no custom setup.
Starting your registry
The right time to establish an MCP server registry is before your second MCP server, not after your fortieth. Start with three things: a registration template (name, owner, tools, access policy, auth config), an approval workflow (who must sign off before a server is promoted to production), and a deprecation process (how servers are sunset when the underlying API changes). These three elements, applied consistently from the beginning, prevent the sprawl that plagues ungoverned MCP environments.
Top comments (0)