MCP Registry and Server Discovery — how a developer finds, publishes, and vets a server before trusting it enough to connect a client

Finding an MCP server and deciding whether to trust it are the same problem: the official MCP Registry is a metadata index, not a vetting authority, and none of the public registries perform pre-listing security review. This page gives the exact publishing/versioning mechanics a server author needs, and the trust signals (and their gaps) a developer must check before pointing a client at someone else's server.

The Registry Landscape: Official Registry vs Third-Party Directories

The official MCP Registry is a centralized metadata repository for publicly accessible MCP servers, maintained by the MCP steering group and backed by Anthropic, GitHub, PulseMCP, and Microsoft; it is the canonical source of truth for publicly published servers, giving server creators a single place to publish metadata. — https://modelcontextprotocol.io/registry/about. It is currently in preview status: breaking changes and data resets are possible before general availability. — same source. As of May 24, 2026 it held approximately 9,652 latest server records and 28,959 total server/version records; Anthropic's December 2025 ecosystem update cited more than 10,000 active public MCP servers ecosystem-wide. — https://www.digitalapplied.com/blog/mcp-adoption-statistics-2026-model-context-protocol. Its scope is explicitly limited: it does not count private enterprise servers, every package named "mcp" on npm/PyPI, or every server listed by downstream marketplaces. — https://modelcontextprotocol.io/registry/about. Server metadata is stored in a standardized `server.json` format holding the server's unique name, location, execution instructions, and discovery data. — same source.

Third-party directories sit on top of it. MCP.so reported over 19,000 indexed servers as of April 2026 (largest public directory verified in that research); Glama.ai/mcp/servers lists 21,000+ servers with visual previews and daily updates. — https://www.truefoundry.com/blog/best-mcp-registries. Glama builds on the official registry with deeper per-connector data — health checks, quality scores, security audits, tool schemas with annotations, usage telemetry, license info, maintainer notes — and positions itself as a curated seal of approval via automated scans plus manual review (README present, valid license, no known vulnerabilities). MCP.so instead offers a "Call Ranking" leaderboard ordering servers/clients by call volume, i.e. usage-based discovery rather than curation. — same source. Downstream aggregators pull from the official registry and enrich it with ratings/curation before exposing it to end users and clients; the official registry codebase itself is not designed for self-hosting and maintainers do not support that use case. — https://modelcontextprotocol.io/registry/about.

Publishing a Server: Namespace, Versioning, and server.json

This is the exact procedure for getting a self-built server discoverable (feeds directly into Building an MCP Server: SDKs, Tool Schemas, Testing, and Deployment — the practical path from a 15-minute local prototype to a hosted remote server's deployment step):

- Namespace authentication. Publish with the mcp-publisher CLI after proving control of the namespace, either via GitHub authentication or DNS/HTTP domain verification. — https://modelcontextprotocol.info/tools/registry/publishing/. Namespaces use reverse-DNS format, e.g. io.github.username/server-name or com.example/server-name, so servers are traceable to their claimed source and only the legitimate owner can publish under a given namespace. — https://modelcontextprotocol.io/registry/about. To publish under a GitHub namespace you must authenticate as that GitHub user or run inside a GitHub Action on that account's repositories; to publish under a custom-domain namespace you must prove ownership via a DNS or HTTP challenge. — https://modelcontextprotocol.info/tools/registry/publishing/. - Package ownership proof differs by target registry: NPM requires an mcpName field in package.json; PyPI requires the server name to appear in the README; Docker requires a specific LABEL annotation; MCPB requires inclusion of a SHA-256 file hash. — same source. - No human review queue. Verification is fully automated and owner-centric — publishers prove namespace control programmatically, nobody manually approves the listing. — same source. Deployment shape is the author's choice: package (npm, PyPI, Docker, …), remote hosting (web service), or a hybrid of both for maximum reach. — same source. - Versioning. server.json must declare a version string, unique per publication; once published, the version string and its metadata cannot be changed. — https://modelcontextprotocol.io/registry/versioning. Semantic versioning (1.0.0, 2.1.3-alpha) is recommended but any string format is accepted; if it fails to parse as semver it is always marked "latest". — same source. Version strings that look like ranges (^1.2.3, ~1.2.3, >=1.2.3) are prohibited, and non-semver ranges are always marked "latest" even when they would otherwise sort earlier — a trap for authors who copy a package-manager-style range into server.json. — same source. Best practice is aligning the server version with the underlying package's version to avoid confusing the two release cycles. — same source.

Discovery: How Clients and Aggregators Find Servers

The registry defines an OpenAPI specification that other registries (private or public) can implement, giving MCP host applications a standardized interface across catalogs instead of one bespoke integration per directory. — https://modelcontextprotocol.io/registry/about. Aggregators are expected to poll the official registry on a regular but infrequent cadence — the documentation's example is once per hour — to stay synchronized without hammering the API. — same source. The primary listing endpoint is /v0/servers, using cursor-based pagination with a maximum of 100 results per page. — https://nordicapis.com/getting-started-with-the-official-mcp-registry-api/. As of February 2026, a second discovery path is emerging via well-known endpoints, defined in two active spec proposals: SEP-1649 (a server card at /.well-known/mcp/server-card.json) and SEP-1960 (a manifest at /.well-known/mcp) — not yet finalized. — https://www.ekamoira.com/blog/mcp-server-discovery-implement-well-known-mcp-json-2026-guide.

What the registry checks

namespace authentication (reverse-DNS accountability) is the primary trust signal; the registry explicitly delegates security scanning to the underlying package registries (npm, PyPI, Docker Hub, …) and to downstream aggregators rather than performing centralized vetting itself. — https://modelcontextprotocol.io/registry/about. MCP.so's Call Ranking leaderboard is a usage-based popularity signal, not a security one. — https://www.truefoundry.com/blog/best-mcp-registries. UNVERIFIED: Glama's quality score and security-audit results are stated in its marketing materials but the scoring methodology and audit frequency are not publicly documented.

What that leaves open

- Registry admission requires only proof of GitHub-repo or domain ownership — no code review, security audit, or malware scan. — https://nimblebrain.ai/blog/state-of-mcp-security-2026/ - 15.4% of registry servers have no source code available at all, making audits impossible for the remote-only (10.6%) and fully opaque (4.8%) subsets. — same source - Roughly 88% of MCP servers require authentication credentials, but the registry's structured metadata captures almost none of this — developers document it in READMEs instead of structured fields — and only 8.5% of servers use OAuth, the rest relying on static API keys or nothing at all. — same source - A server's presence in the official registry is no more a trust signal than any other community package, yet users tend to assume registry presence implies vetting — a mismatch between perceived and actual assurance. — https://tianpan.co/blog/2026-04-10-mcp-server-supply-chain-risk - Most MCP clients use a trust-on-first-use (TOFU) model: the initial install approval is thorough, but subsequent server changes go unverified, so an already-approved server can be silently modified later with no re-review. — https://nimblebrain.ai/blog/state-of-mcp-security-2026/. The protocol itself has no mechanism to verify that a running tool implementation still matches what was reviewed at install time. — https://bishopfox.com/blog/otto-support-supply-chain-risks-mcp-servers

Structured trust frameworks are emerging to fill this gap — CoSAI's MCP Security Framework, OWASP's Top 10 for Agentic Applications, the mpak Trust Framework (MTF), and MCP-Guard (reported 96% accuracy against adversarial prompts) — but none of these is enforced by any registry today. — https://nimblebrain.ai/blog/state-of-mcp-security-2026/

What Does NOT Work: Weak Vetting Has Already Been Exploited

Real incidents, not theoretical risk: in September 2025 the legitimate postmark-mcp server was modified by its own developer to silently BCC every outgoing email to the attacker — a post-approval supply-chain change TOFU cannot catch. — https://bishopfox.com/blog/otto-support-supply-chain-risks-mcp-servers. Between January and April 2026, researchers disclosed 16 CVEs (11 from OX Security, 5 independently) across the Python, TypeScript, Java, and Rust MCP SDKs, affecting more than 7,000 publicly accessible servers with 150+ million combined downloads — https://thehackernews.com/2026/04/anthropic-mcp-design-vulnerability.html — including CVE-2026-26118 (CVSS 8.8) in Microsoft's MCP server implementation, enabling AI tool hijacking. — https://www.pointguardai.com/ai-security-incidents/microsoft-mcp-server-vulnerability-opens-door-to-ai-tool-hijacking-cve-2026-26118. On the third-party marketplace ClawHub, roughly 20% of ~4,000 listed skills were malicious, some returning correct results while secretly harvesting crypto wallet keys and stored credentials — curation alone does not close this gap. — https://nimblebrain.ai/blog/state-of-mcp-security-2026/ + https://bishopfox.com/blog/otto-support-supply-chain-risks-mcp-servers

Five demonstrated attack vectors ride on this weak vetting: Tool Description Poisoning (malicious instructions hidden in tool metadata), Tool Shadowing (a compromised server alters a different, legitimate server's behavior), Parameter Exfiltration (innocuous-looking parameters instruct the model to populate them with sensitive data), Command Injection (untrusted input reaching shell execution), and Registry Compromise (build-pipeline attacks propagating to every downstream deployment at once). — https://tianpan.co/blog/2026-04-10-mcp-server-supply-chain-risk. Unlike a traditional package, an MCP tool definition is natural language that the model processes as legitimate guidance, so these attacks work at a semantic level that static code analysis simply doesn't see. — same source. Public registries additionally lack four enterprise capabilities: server-level access restrictions, audit trails of tool access, role-based governance controls, and data-residency protections — relevant to Enterprise MCP Integration Patterns — the Gateway Layer and the Build-vs-Buy Call Before You Ship a Server. — https://www.truefoundry.com/blog/best-mcp-registries

Mitigations that platform teams actually recommend

a tiered approval model — Gold for fully vetted enterprise vendors with security audits, Silver for community servers with verified practices and code review, Bronze for experimental/sandboxed-only use — https://nimblebrain.ai/blog/state-of-mcp-security-2026/ — plus operational discipline: maintain internal registries with verified commits and signed plugins, pin specific versions and re-review before updating, verify checksums and vendor dependencies locally, restrict outbound network egress, and monitor for unexpected network activity during tool execution. — https://bishopfox.com/blog/otto-support-supply-chain-risks-mcp-servers. UNVERIFIED: signing, provenance tracking, sandboxed execution, and allow-listing are floated as future fixes but are not yet standard practice in any major registry.

For this wiki's objective

before a developer or their coding agent connects a client to any server found through the registry or a directory, the registry/namespace check tells you *who published it*, not *whether it's safe now* — that gap is exactly what MCP Limits: Registry Trust and Supply Chain Risks — why 'it's in the registry' is not a safety guarantee before you connect a client and Authorization in MCP: OAuth 2.1, Token Scoping, and the Confused-Deputy Problem — securing a remote server on the first attempt (scoped tokens limit blast radius even if a server later turns malicious) exist to cover.

Related

- Building an MCP Server: SDKs, Tool Schemas, Testing, and Deployment — the practical path from a 15-minute local prototype to a hosted remote server — the publishing/versioning mechanics here (mcp-publisher, namespace proof, server.json) are the last step of that page's deployment flow: after "does it run," this page answers "can others find it and should they trust it." - MCP Limits: Registry Trust and Supply Chain Risks — why 'it's in the registry' is not a safety guarantee before you connect a client — expands the vetting-gap and supply-chain-incident material summarized here into the full limits analysis. - MCP Limits: Prompt Injection and Tool Poisoning — why the primitives a working server relies on are also its attack surface — Tool Description Poisoning, named here as one of five registry-enabled attack vectors, is that page's core subject. - Authorization in MCP: OAuth 2.1, Token Scoping, and the Confused-Deputy Problem — securing a remote server on the first attempt — since the registry provides no runtime trust guarantee, scoped OAuth tokens and least-privilege permissions are the mitigation that survives a server going bad after install. - MCP Adoption and the July 2026 Spec — what changed under you while you weren't looking — the registry scale figures here (9,652 / 19,000+ / 21,000+ servers) are one input to that page's broader ecosystem-adoption picture.