MCP Server Discovery: Catalogs, Controls, and Tradeoffs

The official MCP Registry reached 37,684 servers on September 28, 2026, according to a count that also reported 450 new arrivals that day. That growth is good news for developers looking for integrations. It’s also a warning: MCP server discovery has become a supply-chain problem before it has become a mature enterprise control plane.

Discovery now works in two modes—static, where a client uses a hardcoded server list, and dynamic, where it searches registries, probes well-known URIs, and filters results. The practical question is no longer whether agents can find a server. It’s whether you can tell which one is legitimate, current, appropriately permissioned, and safe to connect.

How does MCP server discovery work?

Static discovery is usually the sane starting point. A developer lists approved server URLs or launch commands in client configuration, and the agent connects only to those entries. It’s predictable, easy to audit, and appropriate when a team uses a handful of services with known owners.

Dynamic discovery flips the model. Instead of requiring every server to be hardcoded, a client can query a registry, read an MCP Server Card—a structured JSON file served at a well-known URI—and identify how to connect to a server. The documented discovery model supports static configurations for small, predictable setups and dynamic discovery for environments with thousands of possible servers. Ginger Labs’ overview of discovery at scale describes both modes and the role of well-known URIs, registries, and semantic filtering.

That flexibility explains the ecosystem’s momentum. The same research reports more than 10,000 public MCP servers and 97 million monthly downloads across the Python and TypeScript SDKs. It also cites a Stacklok finding that 41% of software organizations already run MCP in some form of production. Those figures don’t tell you that every published server is healthy or safe. They tell you that discovery is becoming a routine part of application architecture, not an experiment for isolated prototypes.

MCP has no mandatory pre-registration requirement, so a client can connect to a server without first joining a centralized catalog. That keeps onboarding friction low. It also means discovery can’t safely be treated as an approval step. If the client can connect to anything it can reach, your allowlist has to exist somewhere the client actually consults.

For a useful distinction, discovery answers “What servers might be available?” while authorization answers “Which of those servers may this agent use?” Don’t collapse those questions into one directory search.

Why has MCP server discovery become a security problem?

The long tail is growing faster than anyone can manually review it. By late May 2026, more than 27,000 MCP servers were indexed across public registries, according to a Codex Knowledge Base registry comparison. The same source reported that Glama indexed more than 21,000 servers while mcp.so listed approximately 19,700.

Those are catalog counts, not counts of production-ready integrations. A directory entry can describe a server whose endpoint is unreachable, whose tool list is empty, or whose publisher has stopped maintaining it. The September 28 MCP server count put the official registry at 37,684 entries, but a larger index doesn’t automatically mean a larger verified working surface.

Influzer illustrates the gap. Its directory holds about 11,500 MCP servers, yet only about 400 have searchable, indexed tools, according to Influzer’s quality-layer analysis. That’s a useful warning against treating a polished listing as proof of operational quality. Searchable tool metadata is still only one signal, and even it doesn’t answer whether the server is safe for your data or credentials.

The security data makes the issue less abstract. Infosecurity Magazine’s report on Ox Security’s analysis covers 15,465 servers across three public registries. The researchers found no consistent governance controls, nearly 16% of 5,095 unique hostnames resolving outside the US, and more than 2% no longer resolving. The same coverage reports that Trend Micro found 492 internet-exposed servers without client authentication or transport encryption in July 2025, later rising to 1,467.

This is the discovery-governance asymmetry I see in the ecosystem: publication is low-friction, while review and enforcement require extra work. The result isn’t necessarily a broken ecosystem. It’s a system where convenience and control are being solved in different places.

What does the official MCP Registry actually provide?

The official registry provides a standardized metadata layer. The registry at registry.modelcontextprotocol.io is maintained by Anthropic and exposes a REST API at /v0/servers using a standardized server.json format, as described by the Codex Knowledge Base. That format gives clients a consistent way to identify a server and find its package, remote endpoint, execution instructions, and capability declarations.

The boundary matters. The registry stores metadata, not server code, and operates as a catalog rather than a runtime authorization boundary. A server record can tell a client where to look; it can’t inspect the server’s current process, validate every tool call, or revoke access after a connection is established. A Vynula guide to the registry makes that distinction explicit.

Stability is another caveat. As of September 2026, the official documentation still labels the Registry as a preview, according to Vynula’s September 2026 explanation. You can use it for discovery, but production systems should be prepared for schema changes, data resets, or service instability rather than treating it as an infallible system of record.

Curation also creates exclusion. MCP.Directory requires a public GitHub repository for submission, which can exclude legitimate closed-source or hosted servers without public implementation code, according to Adil Sadqi’s directory comparison. That policy may help some directories inspect code, but it rewards a particular distribution model over another. A canonical identity is useful; mandatory public source is a separate decision.

The official registry is best understood as an upstream identity and metadata service. Aggregators can add search, quality labels, and curation. Your client or gateway still has to decide what is allowed to execute.

Which MCP discovery tools fit which teams?

The right discovery tool depends less on catalog size than on how much operational control you need. Personal developers may want fast search and one-click setup. Teams need evidence that a server is live and an API they can manage. Organizations with sensitive credentials need routing, logs, and policy enforcement. Open-source infrastructure buyers may prefer to operate the gateway themselves, even when documentation is thinner.

The comparison below uses the pricing and product details captured in the available research. It separates directory convenience from runtime control; those aren’t the same job.

Tool	Pricing	Discovery and infrastructure features	Best fit
MCP Hub	Free tier; Pro plans from $10/month	Web, desktop, and CLI access; one-click setup; no public API	Individual developers and Claude Desktop experimentation
Glama	Free tier; plans from $9/month	Large directory, security rankings, managed gateway, hosting, and web/API access	Teams wanting managed discovery and hosting
OpenMCP	Free Community tier for up to 3 members; paid plans from $99/month	Open-source gateway for managing, deploying, and securing MCP integrations; web, CLI, and API access	Teams comfortable operating Docker and Kubernetes infrastructure
Official MCP Registry	—	Standardized server.json metadata and /v0/servers REST API; metadata catalog, not runtime enforcement	Client implementers and directory builders needing canonical metadata

MCP Hub is attractive when the immediate goal is finding something quickly. Its research profile emphasizes one-click installation for Claude Desktop, but it also notes the absence of a public API and deeper analytics. That makes it closer to a personal discovery utility than a programmable control plane. The same source flags a recent ANSI escape injection concern in MCP servers, another reason not to treat discovery UI polish as a security review.

Glama sits farther toward the managed-service side. Its directory, ranking layer, managed gateway, and hosting features reduce infrastructure work, while the research describes it as suitable for teams adopting MCP without operating every deployment themselves. The tradeoff is dependence on a third party and potentially separate costs when heavy usage consumes additional credits.

OpenMCP is the portability option in this group, but the research also flags a product-status problem: its former address redirects elsewhere, and the documentation is thin. Self-hosting may fit teams that already have infrastructure expertise; it isn’t automatically the cheaper or safer choice for a team without it.

The official registry isn’t a direct substitute for any of these products. It provides a common metadata contract, not a polished search experience or a complete policy layer. For a real rollout, you may use several layers together.

Where should MCP security controls live?

Security controls belong where the connection is actually authorized and executed: the client and gateway. A registry can help you find a server and verify a publisher identity. It cannot stop a client from bypassing a catalog and connecting directly to a reachable endpoint.

The evidence for this boundary is already substantial. Ox Security’s analysis reported by Infosecurity Magazine found zero consistent governance controls across 15,465 servers. Trend Micro’s separate research, covered in the same report, found 492 exposed servers without client authentication or transport encryption in July 2025, with that figure later increasing to 1,467.

That doesn’t mean catalogs are useless. It means they solve a different problem. A registry can aggregate quality signals, canonical identities, and searchable metadata. The client still needs an allowlist. A gateway still needs to check credentials, tool permissions, and data movement for each call.

Microsoft’s approach reflects that split. BEX’s coverage of Microsoft Agent 365 says Shadow AI Discovery through Defender and Intune can surface unmanaged MCP servers after Agent 365 became generally available on May 1, 2026. Discovery first makes sense: you need visibility before you can govern what hasn’t been inventoried.

Cloudflare is approaching the execution layer from the opposite direction. Cloudflare’s September 24 changelog says its generally available MCP server portals provide one endpoint for approved servers, gateway routing, DLP scanning, and Logpush support. That’s closer to the control point where a server connection becomes an auditable request.

CIS has also turned the problem into a measurable checklist. CIS’s MCP Server Benchmark v1.0.0 contains 55 prescriptive recommendations across 10 security domains, including governance, authentication, data protection, observability, supply-chain security, and execution safety. Use it to test the system around the server, not just the catalog entry.

How does stateless MCP change discovery architecture?

The July 28, 2026 MCP specification revision removes the initialize handshake, session IDs, and sticky-session requirements. According to InfoQ’s coverage of the stateless revision, any server instance can handle any request, which simplifies horizontal scaling and removes some session infrastructure.

This change makes discovery feel more like ordinary API routing. A client can send a self-contained request to a server behind a conventional load balancer without maintaining a session affinity rule. That’s operationally attractive, especially for serverless deployments.

The stateless design doesn’t eliminate discovery. It changes the shape of the problem. The protocol now includes an optional server/discover RPC for checking capabilities before a tool call, while Multi Round-Trip Requests use input_required results to collect additional input. Quarkus’s implementation analysis explains how the new flow replaces persistent server-to-client callbacks with explicit request cycles.

That explicit structure can make capability inspection cleaner. It can also expose more places where you need policy. A gateway needs to know which client identity made the request, which server it targeted, which tools are visible, and whether the next request in a multi-step interaction is still authorized. A discovery catalog cannot answer those questions for you.

Our earlier explanation of stateless MCP server architecture patterns goes deeper into the deployment consequences. For discovery specifically, the key point is simple: removing sessions removes state management, but it doesn’t remove governance. You still need to know which servers are allowed, which capabilities are exposed, and which calls are permitted.

What discovery approach should an engineering team adopt?

Start with a static allowlist if you have a small number of known servers. Add dynamic discovery only when the catalog is large enough that hardcoding every connection creates real operational friction. The MCP versus APIs explanation is useful here: MCP is optimized for agent runtime tool discovery, while deterministic developer integrations often remain clearer as conventional APIs.

For dynamic discovery, use a layered design:

1. Discover broadly. Query the official registry and one or more directories for candidates.
2. Verify the surface. Check whether the endpoint is live, whether tools are indexed, and whether authentication is required.
3. Review ownership. Confirm the publisher, endpoint, source repository when available, and intended data access.
4. Allowlist explicitly. Add only approved server URLs or exact launch commands to the client configuration.
5. Route through a gateway. Apply per-tool permissions, credential isolation, data-loss controls, and audit logs.
6. Revoke continuously. Remove access when ownership, endpoint behavior, or business requirements change.

The cost question deserves a separate check. The supplied 50-developer scenario estimates MCP Hub Pro at $6,000 per year using the math 50 × $10 × 12, and Glama Starter at $5,400 per year using 50 × $9 × 12. Those figures come from the listed MCP Hub pricing and Glama pricing, not from a full enterprise total. They omit gateway costs, usage charges, security operations, infrastructure, and the labor required to review servers.

My recommendation is to use dynamic discovery for candidate generation, not for production authorization. Let catalogs expand your search space; let the client allowlist and gateway control what an agent can actually do. If your team is designing multi-step MCP workflows, also read MCP multi-round-trip requests explained before assuming that statelessness means requests are simple.