MCP Server Discovery and Registry Design for Large Organizations

A platform engineer at a mid-size enterprise can discover, configure, and connect a new MCP server to a production AI agent in under ten minutes. That speed is the entire problem this article addresses: MCP server discovery at enterprise scale is a governance problem, not a search problem, and the fix is a registry architecture that separates discovery from authorization, gates every server through an explicit admission pipeline, and ties approved access to the identity provider the organization already runs. The strongest enterprise pattern treats the public MCP Registry as upstream intake only, routes every candidate server through security review and metadata enrichment before it reaches production, and enforces runtime access through OAuth 2.1 and role-based permissions scoped to the individual tool, not the whole server. The sections below lay out why that architecture is necessary, what the official registry does and doesn't cover, and how organizations including GitHub, Microsoft, and Speakeasy are building the layers that sit on top of it.

Why MCP Server Discovery Became a Governance Problem

A developer with an AI assistant and a terminal can find a candidate MCP server, install it, and grant it live access to a company system faster than a security reviewer can open a ticket. That speed is the root of the governance gap: discovery, publisher trust, code trust, permission approval, and runtime safety are five distinct checks that a security team would normally perform in sequence, and a ten-minute install compresses all five into a single, unreviewed act. Community directories now list tens of thousands of submitted MCP servers, and the distance between "a developer can find this" and "this is approved for enterprise use" has become the actual terrain of the problem, not a side effect of it. Without a centralized, enterprise-approved directory standing between those two states, discovery stays manual, security review gets fragmented across teams, and shadow AI spreads as agents connect to tools nobody vetted.

The damage compounds at scale in predictable ways: duplicate servers doing the same job under different names, credentials scattered across config files and environment variables with no central inventory, and no reliable answer to the question of which tools which agents are actually calling. None of that is a discovery failure. A search engine for MCP servers would not fix it, because the organizations hitting this wall can already find the servers they need. What they lack is a gate between finding a tool and trusting it with production data, and building that gate is a governance exercise, not a better index.

What the official registry verifies, and what it deliberately leaves unresolved

The official MCP Registry, hosted at registry.modelcontextprotocol.io and backed by Anthropic, GitHub, PulseMCP, and Microsoft, functions as a metadata service rather than a trust authority, and that distinction has to be the starting point for any enterprise layer built on top of it. The registry provides namespace verification, standardized metadata, package references, remote endpoint definitions, version records, and a REST API that downstream registries can consume. It verifies package-to-server identity matching through specific mechanisms: npm packages carry an mcpName field, PyPI and NuGet packages carry an mcp-name marker, OCI images carry an annotation, and MCPB artifacts carry a SHA-256 value for file integrity. Once a version is published, its metadata cannot be edited in place, which gives any downstream reviewer a stable intake record to work from. The 2026-07-28 spec release added a server/discover RPC, so clients get a real capability-discovery primitive instead of a flat listing.

The registry does not confirm whether a publishing account has been compromised, whether a tool's self-reported description matches what it actually does (tool poisoning sits outside its scope entirely), whether the permissions a server requests are proportionate to its stated function, or whether a server's runtime behavior stays consistent with what was registered. The documentation itself describes the registry as still in preview, and it does not currently support private servers. Namespace-based authentication, handled via DNS or GitHub verification, and an open API that other registries can mirror represent a real step beyond bare metadata listing, but the registry still delegates security scanning to the underlying package registries (npm, PyPI, and the rest) and to downstream aggregators. There is no cryptographic signing of every server, no verified publisher program, no built-in security scanning, and no per-org allowlist. Azure API Center lets organizations maintain their own inventory of MCP servers, surfaced to stakeholders through the API Center portal, with registered servers integrable into Microsoft Foundry's tool catalogs for governed agent access. The underlying protocol keeps moving under all of this. The.well-known/mcp server-card specification remains in review, and May, June, and July 2026 alone brought stateless sessions, an Enterprise-Managed Authorization extension, the deprecation of Dynamic Client Registration in favor of Client ID Metadata Documents, and server-to-client change notifications, each of which forces an implementation decision on anyone building a registry layer.

The architectural boundary enterprises must draw between discovery and authorization

A registry and a gateway answer two different questions, and the central architectural claim of this piece is that collapsing them into one system is the mistake that makes everything downstream unsafe. A registry answers what tools exist, where they're deployed, and what they claim to do: it's the catalog an agent or a developer queries to find candidate MCP servers. A gateway answers something narrower and more consequential: is this specific agent authorized to execute this specific tool call, with these specific parameters, on behalf of this specific user, right now. One is a catalog. The other is a runtime enforcement point, and treating the two as interchangeable creates a single point of failure: if a server that clears discovery review is implicitly treated as authorized to run with production credentials, that assumption is precisely what supply-chain attacks are built to exploit.

Most large organizations need both layers working in concert, but the interface between them has to be explicit and auditable rather than implied. A registry record should inform a gateway's authorization decision, but it should never substitute for one. The gateway layer is already taking shape as its own product category rather than something every engineering team builds in-house: Citrix's NetScaler added MCP Gateway functionality in July 2026, operating at the network layer to route, govern, and observe agent traffic to backend MCP servers. Several organizations that tried to stand up internal governance tooling in early 2026 are now evaluating external platforms instead, because the MCP spec has moved faster than most internal engineering roadmaps can absorb. Getting this boundary wrong doesn't just create technical debt. It means re-architecting access control under the pressure of an incident, with production agents already connected to servers nobody formally approved, which is a far more expensive place to discover the distinction between a catalog and a gate than a design review.

How an enterprise admission pipeline moves a server from public discovery to approved internal use

The safest operating pattern treats the public MCP Registry purely as upstream intake, so every candidate server has to clear an explicit approval pipeline before it touches production data or credentials. That pipeline starts by ingesting from the public registry as a source of information, not as a grant of trust, and moves into a security review stage that verifies the publisher, pins the exact artifact, inspects the package and its source, enumerates the tools the server exposes at runtime, classifies the permissions it requests, and checks for known vulnerabilities in its software composition. From there, the server gets enriched with organizational trust metadata, a record of who reviewed it and under what terms, before it's published into a private registry or enforced allowlist that developers actually pull from. Any change to the artifact, its tool definitions, its permissions, its endpoint, or its publisher forces the server back through the pipeline rather than letting the original approval stand indefinitely.

GitHub's enterprise MCP controls show what this looks like as a working system: organizations can configure an MCP registry URL and restrict which clients are supported, so that only servers listed in that private registry are permitted to run. The enforcement isn't airtight yet, since the restriction can currently be bypassed through local config file edits and GitHub does not yet offer strict prevention of non-registry servers, but the model is the right one: the private registry becomes the actual enforcement boundary, not just a reference catalog sitting beside the real access control. The metadata an organization attaches to each approved server at this stage is what turns the approval into something auditable rather than a one-time judgment call: an approval owner and business justification, a review date and an expiration date that forces periodic reapproval, the exact artifact digest alongside its software-composition scan result, a hash of the approved tool definitions and the specific subset of tools cleared for use, the OAuth scopes the server is allowed to request and the service or workload identity it runs under, and the data classifications it's permitted to touch. That schema matters because the inputs it tracks can shift independently of each other: a legitimate publisher can ship vulnerable code in a later release, a clean-looking package can request more permissions than its function requires, a read-only tool can return content crafted to manipulate the agent reading it, and a remote service can change its own implementation without the registry record ever reflecting the change. Capturing the state of a review at a point in time, and triggering reapproval the moment any of those inputs moves, is what the metadata schema is actually for. For regulated teams, the pipeline has to produce answers to six specific questions for every server admitted: who maintains it, what identity model it inherits, what it's able to mutate, where its logs are written, what data classifications cross its boundary, and what the process is when the server itself changes.

The threat model that makes a governed registry non-negotiable

MCP server security in 2026 is a supply-chain problem before it's anything else, and that reframes the registry as an attack surface in its own right, not only a governance convenience. Trend Micro identified 492 MCP servers exposed to the public internet with no authentication at all, which puts unauthenticated exposure in the category of documented fact rather than theoretical risk. In April 2026, OX Security disclosed a systemic vulnerability spanning Anthropic's MCP implementations across Python, TypeScript, Java, and Rust, a supply chain with hundreds of millions of downloads and, by OX's count, a very large number of vulnerable instances already in the wild. At that scale, reviewing individual servers one at a time stops being a workable control; only a pipeline that applies the same checks to every artifact, every time, can keep pace.

The PyPI ecosystem offered its own case study in March 2026, when a backdoored package accumulated tens of thousands of downloads within three hours of being published, before anyone caught it. The compromised package was LiteLLM, the language-model gateway underpinning CrewAI, DSPy, and Microsoft GraphRAG, which makes the incident a clear demonstration that a trusted, widely integrated package is exactly the kind of target attackers look for, precisely because so many downstream systems trust it by default. A separate but compounding threat sits in the tool-poisoning and prompt-injection surface: a tool that dumps full records in response to a simple query can put API keys, personally identifiable information, and internal identifiers directly into the conversation, where that data can be summarized into logs, forwarded to another tool, or end up embedded in a support transcript nobody thought to classify as sensitive. None of this is a convenience problem that a better catalog would solve on its own. An ungoverned MCP registry is the ingestion point through which supply-chain attacks reach an organization's agents, making the admission pipeline described above a control, not a formality. Detecting a compromised server after it's already running in production is too slow by definition. The pipeline and the gateway layer that enforces it exist to stop an unapproved or compromised server from reaching production.

Role-Based Access and Identity Integration in the Authorization Layer

A registry entry, no matter how well vetted, cannot enforce anything on its own. It has to feed into an authorization layer wired to the identity infrastructure the organization already runs, or the approval recorded in the metadata schema never actually constrains what happens at runtime. When an agent requests a tool call, whether that's updating a record, querying a database, or posting to an internal system, the gateway enforcing that call has to confirm the agent is acting within the permission scope of the specific human user it represents, not a shared service account and not the broad scope of whoever originally configured the integration. That means user-delegated OAuth flows rather than static service credentials: the specific user, through their own identity, at the moment of the request.

Role-based access control is the baseline mechanism for making that distinction operational: engineering teams see GitHub and code-execution tools, finance teams see ERP integrations, and agent identity is tracked separately from user identity so that an audit trail can distinguish between the two. The June 2026 Enterprise-Managed Authorization extension to the MCP spec makes this concrete at the protocol level: an identity provider can automatically provision the specific MCP servers a given user is authorized to use based on their role, with a single auditable trail living in the IdP admin console rather than scattered across per-server configs and one-off OAuth consent screens. Azure API Center's integration with Microsoft Foundry's tool catalogs follows the same logic: a registry record becomes governed agent access only once an identity-aware platform layer sits between the catalog and the running agent. Speakeasy's AI control plane applies the same principle by connecting MCP servers to the identity providers enterprises already run, including Okta, Microsoft Entra ID, Auth0, WorkOS, Google Workspace, and Ping Identity, along with any SAML or OIDC provider, so that role-based policies governing which teams can reach which servers live in the same system already managing SaaS access rather than in a second, parallel permission model someone has to keep in sync.

The practical consequence for registry design is specific: the metadata schema described earlier has to include the required OAuth scopes and permitted data classifications for every approved server, because those are the fields the authorization layer actually reads at runtime. A registry that stops at "this server exists and looks legitimate" gives a gateway nothing to enforce. A registry that records which scopes a server is allowed to request and what data it's cleared to touch gives the gateway a policy to execute on every single tool call, which is the form the governance argument in this piece takes once it reaches the point of actually running in production.