MCP Registry & Directory Guide: Where to Find MCP Servers

TL;DR - The official MCP Registry (registry.modelcontextprotocol.io) is the canonical, API-first metadata catalogue, backed by the MCP steering community — machine-readable, but not a browsing experience. - Community directories — PulseMCP, Glama, mcp.so, Smithery, mcpservers.org — layer search, rankings, and hosting on top; they index tens of thousands of servers of wildly varying quality. - Directory listing counts (20,000–50,000+) massively overstate the usable ecosystem; most entries are unmaintained experiments. - A reliable finding workflow: vendor docs first → official registry → one community directory for discovery → verify maintenance before connecting. - For remote servers specifically, curated lists beat raw directories — see our best remote MCP servers survey.

---

Why MCP Discovery Became Its Own Problem

Within a year of the Model Context Protocol shipping, the "how do I find a server for X?" problem got worse, not better. Thousands of servers appeared on GitHub. Multiple competing directories sprang up to index them. Vendors shipped official servers that coexisted with older community clones of the same integration. By 2026 the raw numbers are impressive — PulseMCP's directory tracks over 20,000 servers, Glama indexes more than 50,000 open-source ones — and almost useless as stated, because volume tells you nothing about which server for a given product is official, maintained, and safe.

This guide maps the registry and directory landscape as it actually stands in July 2026: what each source is, what it's good for, and how to combine them without connecting abandonware to your AI client.

---

The Official MCP Registry

URL: registry.modelcontextprotocol.io

Launched in preview in September 2025 under the modelcontextprotocol GitHub org, the official registry is the ecosystem's canonical metadata layer. Key properties:

• It's an API, not a storefront. The registry is a machine-readable catalogue (a REST API over standardised server.json manifests) designed for *clients and aggregators* to consume. You can browse it, but it's optimised for programmatic discovery.
• Publisher-verified namespacing. Servers are published under namespaces tied to verified identities (e.g., DNS or GitHub verification), which addresses the "is this the real Stripe server?" problem better than any community list.
• It's upstream of other directories. Several community directories now sync from the official registry and treat their own listings as a superset.

What it doesn't do: rank servers, review code, host anything, or tell you which of three similar servers is best. It's infrastructure, deliberately unopinionated.

Use it when: you're building tooling that needs server metadata, or you want to verify a server's provenance.

---

The Community Directories, Honestly Reviewed

PulseMCP

A daily-updated directory tracking 20,000+ servers plus MCP clients, with filters that matter in practice — you can cut the list to *official-provider, remote-capable* servers, which is most of what a serious user wants. Adds editorial use-cases and a newsletter. Weakness: it indexes existence, not quality; a filter result still needs a maintenance check.

Glama

The most technical of the directories: 50,000+ indexed open-source servers, each automatically scanned and scored (security, licence, quality signals), plus an in-browser MCP inspector for poking at a server's tools before you install anything, and a gateway product that fronts servers with logging and access control. Positions its index as a superset of the official registry. Weakness: automated scores are a floor, not an endorsement — plenty of high-scoring servers are still single-commit experiments.

mcp.so

One of the earliest and largest community-curated directories, strong on breadth and simple search. Good for "does *any* server exist for this niche product?" sweeps. Listing quality varies more than the two above; treat it as a search engine, not a recommendation.

Smithery

Directory *plus hosting*: Smithery both catalogues servers and runs many of them as hosted endpoints you can connect to directly. That makes it the fastest path from "found it" to "using it" for community servers that would otherwise need local installs. The trade-off is an extra party in your data path — the same calculus as any remote vs local decision, with a community host instead of the vendor.

mcpservers.org (and its remote-server list)

A curated "awesome list" style site whose remote servers page is one of the better-maintained catalogues of *hosted* endpoints specifically — a couple of hundred official remote servers with one-click connect details. Narrower than the big directories, and better for it.

GitHub's MCP Registry

GitHub also surfaces an MCP registry view (github.com/mcp) tied to repositories, which is convenient when your discovery already starts on GitHub and you want stars/activity signals inline.

---

A Workflow That Avoids Abandonware

After a year of connecting servers for real work, this is the order that saves time:

1. Check the vendor's docs first. If the product you want has an official server (as GitHub, Notion, Linear, Stripe, Sentry, Atlassian and most major SaaS now do), the vendor's own documentation is the source of truth for the endpoint and auth. Directories sometimes lag or list superseded community versions.

2. Verify in the official registry. Confirms the namespace and publisher identity — thirty seconds against typosquatting.

3. Discovery pass in one community directory. For products without official servers, filter PulseMCP or Glama. Prefer: recent commits (within ~3 months), a real README with tool documentation, an identifiable maintainer, and — for anything touching credentials — OAuth support over pasted keys.

4. Inspect before you connect. Glama's inspector (or a local run of the MCP Inspector) shows the actual tool list and schemas. If the tools returned don't match the README, walk away.

5. Prefer remote endpoints for anything shared. A hosted server one teammate found becomes the team's server with a URL; a local server becomes a support burden. Our remote MCP servers guide covers the trade-offs.

---

Where OpenHelm Fits in the Directory Landscape

OpenHelm isn't a directory — it's five task-execution servers you'll find *listed in* these directories and documented at openhelm.ai/mcp: general-purpose, deep research, SEO & GEO, email outreach, and dev changes, all remote endpoints at mcp.openhelm.ai with OAuth 2.1.

The relevant distinction when you're browsing directories: most listings are API wrappers around a single product, while task-execution servers accept a goal and run it as an asynchronous agent job in an isolated sandbox. Directories don't currently separate these categories well — a "tools count" tells you nothing about whether a tool call takes 200ms or does twenty minutes of real work — so it's worth knowing the distinction exists before you evaluate listings side by side. Setup for OpenHelm's servers is in the MCP servers docs.

---

Programmatic Discovery: Registries as Agent Infrastructure

A shift worth watching: registries are stopping being websites humans browse and becoming infrastructure *agents* consume. The official registry's API-first design is explicit about this — the intended consumers are MCP clients and aggregators that resolve "I need a server that does X" at runtime, the way package managers resolve dependencies.

You can see the early shape of it today. Clients are beginning to offer in-app server search backed by registry data rather than sending users to a browser. Gateways (Glama's, and others) sit in front of multiple servers and expose a single endpoint with per-tool access control, effectively making the directory a routing layer. And enterprises are standing up *private* registries — internal catalogues of approved servers — using the same server.json format, so the corporate AI client only discovers vetted tools. The registry spec supporting namespaced, verified publishing is what makes that governance model possible.

The practical takeaway for teams: treat the official registry's manifest format as the durable interface. Directories will keep competing on discovery UX, but the manifest is what your tooling should depend on — it's the piece with a standards process behind it.

---

What's Still Broken in MCP Discovery

Being honest about the state of things in mid-2026:

• Fragmentation persists. Publishers list in the official registry, several directories, and their own docs; none of these stay perfectly in sync. The official registry is winning as the metadata source, but the browsing layer remains split.
• Quality signals are weak. Stars, download counts and automated scans all proxy poorly for "will this server still work in six months."
• Security review is on you. No directory audits what a server *does* with your data. An MCP server sits between your AI client and your credentials — vet it like a browser extension, not like an npm dev-dependency.
• Duplicates confuse models and humans. Four community Notion servers plus one official one means directory search results need human judgment. Official-provider filters help; use them.

---

Frequently Asked Questions

What is the MCP registry?

The MCP Registry is the official, community-run metadata catalogue for publicly available MCP servers, hosted at registry.modelcontextprotocol.io under the Model Context Protocol project. It launched in preview in September 2025 and provides a machine-readable API of standardised server manifests with publisher verification — the canonical upstream that many community directories build on.

What's the difference between the MCP registry and an MCP directory?

The registry is infrastructure: an unopinionated, API-first catalogue of server metadata with verified namespaces. Directories (PulseMCP, Glama, mcp.so, Smithery) are consumer-facing layers that add search, rankings, security scans, reviews, and sometimes hosting. Registry = source of truth; directories = discovery experience.

How many MCP servers are there?

Directory counts in July 2026 range from 20,000+ (PulseMCP) to 50,000+ (Glama's open-source index). The honest caveat: the large majority are unmaintained experiments or duplicates. The set of official, maintained servers from real vendors is in the low hundreds, and the set of hosted *remote* ones is smaller still.

Is there a directory of remote MCP servers specifically?

Yes — mcpservers.org maintains a dedicated remote-servers list, and PulseMCP's directory can filter to remote-capable, official-provider servers. For a curated, verified take, see our best remote MCP servers in 2026 survey.

How do I publish my own MCP server to the registry?

Publish a server.json manifest via the official registry's publishing flow (documented at registry.modelcontextprotocol.io/docs), using a namespace you can verify — GitHub-based namespaces verify through your repo identity, domain-based ones through DNS. Community directories will generally pick your server up from the registry automatically, though most also accept direct submissions.