Where to Find MCP Servers: Registries and Directories

There is no one MCP server list, but there is an official starting point: the MCP Registry at registry.modelcontextprotocol.io, which holds verified metadata for public servers. Around it sit catalogs built for a particular client or runtime: GitHub’s MCP Registry for Copilot and VS Code, Docker’s MCP Catalog for servers that run in containers, Anthropic’s Connectors Directory for Claude, and the marketplaces inside Cursor and Gemini CLI. Use the catalog that belongs to the client you will connect from, because it installs in one step and may carry an admin’s allow list. Then check the server itself, because none of these listings is a security review.

If you want a shortlist by job rather than a full catalog, start with the sister guide, best MCP servers by job. For how the official registry works inside, including namespaces and publishing, see the MCP Registry.

The official MCP Registry

The registry is the upstream source for most other lists. Its own overview↗ (opens in a new tab) says it is “currently in preview,” that breaking changes or data resets may occur, and that it is “intended to be consumed primarily by downstream aggregators” rather than read straight by your editor. What it gives you:

• A name you can trust to mean one publisher. Names are reverse-DNS, such as io.github.github/github-mcp-server, and only the owner of that GitHub account or domain can publish under it.
• How to run the server: an npm, PyPI or container package, a remote URL, or both, with the arguments and environment variables it needs.
• Public servers only. A server on a private network or a private package feed does not belong there; the registry suggests running your own registry for those.

What it does not give you is a verdict on safety. The registry delegates security scanning to package registries such as npm and to downstream aggregators, and its maintainers remove spam and malicious entries by hand. Browse it in a web browser, or query the API as shown in the MCP Registry.

The list of MCP servers on GitHub

Searches for a GitHub list of MCP servers usually mean one of three things, and they are easy to confuse.

• The MCP project’s own servers repository. It used to carry a long list of community servers. Its README now says: “If you are looking for a list of MCP servers, you can browse published servers on the MCP Registry,” and keeps only a handful of reference servers (Everything, Fetch, Filesystem, Git, Memory, Sequential Thinking and Time). Older ones such as the original GitHub, Slack, Postgres and Puppeteer servers are archived, and some entries point to a replacement maintained elsewhere, such as Brave’s own search server.
• The GitHub MCP Registry at github.com/mcp. GitHub describes it↗ (opens in a new tab) as “a curated list of MCP servers from partners and the community,” currently in public preview. In VS Code, typing @mcp in the Extensions view opens the same gallery, and in Copilot CLI the experimental /mcp search command browses it, or your organization’s own registry if an admin has set one.
• Community “awesome” lists. Useful for discovery, but they are someone’s bookmarks: no verification, and entries go stale.

One more that shows up in the same searches: list_issues is not a directory at all. It is one of the tools inside GitHub’s own MCP server, which lists a repository’s issues. That server is covered in Claude and the GitHub MCP server.

The Docker MCP server list

The Docker MCP Catalog↗ (opens in a new tab) lists servers packaged as container images on Docker Hub, browsable at hub.docker.com/mcp or in Docker Desktop’s MCP Toolkit. Docker’s documentation says it builds and signs the local servers in the catalog and ships them with provenance and SBOM metadata, and that an organization can make a custom catalog that restricts which servers are approved or adds private ones. Its pages give different totals (“over 200 tools and services” in one place, “300+ servers” in another), so treat any count as approximate. Running them is covered in Docker MCP Toolkit. A signed image tells you who built it, not whether its tools are safe to hand an assistant.

Directories inside the AI clients

• Claude. Anthropic’s Connectors Directory↗ (opens in a new tab) is one catalog for claude.ai, Claude Desktop, mobile, Claude Code and Cowork, with verified and community connectors. Anthropic states plainly that “Verification isn’t a security audit,” and that ranking is usage-based. On Team and Enterprise plans an Owner adds a connector for the organization.
• Cursor. Its marketplace lists MCP servers and plugins with one-click install, grouped by category. It does not publish vetting criteria on the directory page, so treat an entry as a listing, not an endorsement.
• Gemini CLI. Extensions bundle MCP servers with prompts, commands and other pieces, and are browsed in the extension gallery and installed with gemini extensions install and a repository URL. Read what an extension bundles before installing it.
• VS Code and GitHub Copilot. The @mcp gallery above; admins can point it at their own registry and allow only servers from it, as the MCP Registry explains.

Automation tools keep their own lists too: n8n, for example, has a registry of servers its MCP Client Tool can connect without a credential, covered in n8n MCP.

Six checks before you connect a server from any list

1. Is the publisher the product’s maker? Match the namespace, package owner or domain to the vendor. A server named after a product but published by a stranger is the classic trap.
2. Is it maintained? Look at the last release and whether issues get answers. Archived reference servers still install, and that is not a recommendation.
3. Remote with OAuth, or local with a pasted key? A hosted server with a browser sign-in keeps secrets out of config files. A local one runs with your user’s rights on your machine.
4. What is the smallest access it offers? Look for a read-only mode, tool filtering or narrow scopes, and start there.
5. What do its tools say? Read the tool names and descriptions, because the model reads them as instructions. Notice if they change after an update.
6. Does the security guidance hold up? The MCP project’s security best practices↗ (opens in a new tab) set out what a server must do, and OWASP’s MCP Top 10 lists what goes wrong most often. Scanning MCP servers turns both into a routine.

Keep your own approved list

Every catalog above is somebody else’s list. What a team needs is its own: the servers it has checked, who asked for each, and what access each gets. MCP governance covers who decides. On fenbs, a task board that is itself an MCP server at https://fenbs.ai/api/mcp, one way to run it is to file each “add this server” request as a task, record the outcome on the Decisions and rules page, and make the standing ones rules, such as “connect only servers from the vendor’s own namespace.” A rule is a decision that holds from now on, the decider is always a person, and every connected AI assistant reads the rules before it starts work. History shows who changed what.