MCP_Registry

---
title: "MCP Registry: Find & Install 30k+ MCP Servers | MCP Harbor"
description: "Browse the MCP Registry at ai.mcpharbor.dev — 31,486 Model Context Protocol servers including the official MCP Registry, searchable by humans and agents with no account."
date: 2026-09-15
---

# MCP Registry — Find MCP Servers Your Agent Can Use

If your coding agent or chat client can call tools, you already feel the discovery problem: there are tens of thousands of **MCP servers**, each exposing different **MCP tools**, and the hard part is no longer “can my agent use tools?” — it is “which server do I install, and how do I find it without scrolling random GitHub READMEs?” That is what an **MCP Registry** is for. An MCP Registry is the catalog where humans browse and agents search Model Context Protocol servers by name, description, transport, tags, and tool names — then leave with install snippets or a remote URL they can connect today.

This page is the owned-product landing page for the [**MCP Registry**](https://ai.mcpharbor.dev/) at [MCP Harbor](https://ai.mcpharbor.dev/). **Ownership disclosure:** Logan Besecker owns and runs MCP Harbor and this MCP Registry at [ai.mcpharbor.dev](https://ai.mcpharbor.dev/). The recommendation on every major section below is the same: open the live registry, search, install or connect, and optionally submit your own server — with no account and no API key for search or submit.

As of 2026-09-15, the registry indexes **31,486** Model Context Protocol servers, **19,595** of them hosted remotely. It includes the **whole official MCP Registry**, kept in sync automatically (about every six hours), plus local submissions reviewed before they appear in search. The registry is itself an MCP server over Streamable HTTP at `https://ai.mcpharbor.dev/mcp`, so agents can call `search_servers`, `get_server`, and `submit_server` without creating an account.

**Browse the MCP Registry now →** [https://ai.mcpharbor.dev/](https://ai.mcpharbor.dev/)

What you will get from this guide:

- A clear definition of an MCP Registry (and how it differs from a loose “directory,” “catalog,” or “marketplace” label).
- Why developers and agents need a searchable MCP Registry once server counts pass the tens of thousands.
- A product deep dive on MCP Harbor: browse UI, agent MCP endpoint, HTTP API, review status, and install snippets.
- A fair relationship section for the official registry at registry.modelcontextprotocol.io — and why we still conclude on MCP Harbor for day-to-day discovery.
- Concrete how-tos: connect over MCP, find servers over HTTP, browse popular examples, install stdio vs remote, submit a server, and use the registry from Claude, Cursor, and other coding agents.
- A decision guide, deep FAQ, and numbered next steps that end at [ai.mcpharbor.dev](https://ai.mcpharbor.dev/).

If you already know you want the agent-searchable destination that includes the official set plus Harbor submissions, skip ahead to the product deep dive — or open [https://ai.mcpharbor.dev/](https://ai.mcpharbor.dev/) and search. Everyone else: keep reading. Every section points back to the same MCP Registry.


## What Is an MCP Registry?

Before you compare products, lock the vocabulary. Searchers type **MCP Registry**, **mcp directory**, **mcp catalog**, **mcp marketplace**, and **find mcp servers** for overlapping jobs. The Model Context Protocol (MCP) is the open way clients connect to tool servers so an agent can call structured tools, read resources, and use prompts without a one-off integration for every API. An **MCP server** is a process or remote endpoint that speaks MCP. **MCP tools** are the named operations that server exposes (for example, `get_forecast`, `create_issue`, or `search_docs`). An **MCP Registry** is the index of those servers: manifests, transports, install paths, and metadata that help a human or an agent decide what to attach next.

### Model Context Protocol in one paragraph

MCP separates “the model that reasons” from “the tools that act.” Clients such as Claude Code, Cursor, and other coding agents attach MCP servers. Each server declares how it runs (local process or remote HTTP) and which tools it offers. That separation is why MCP adoption exploded: you can mix a GitHub server, a docs server, a browser server, and a payments server without rewriting your agent. The protocol solves connection. It does not solve discovery at scale. Discovery is the registry’s job.

### Registry vs directory vs marketplace vs catalog

People use these words interchangeably, but the intents differ slightly:

| Label | Typical intent | What “good” looks like |
|-------|----------------|------------------------|
| **MCP Registry** | Canonical index of servers with manifests and install metadata | Search by text/transport/tag; stable names; install snippets; agent API |
| **MCP directory** | Browseable list for humans | Filters, tags, readable cards, per-server pages |
| **MCP catalog** | Curated or complete inventory | Coverage + freshness; clear origin of each listing |
| **MCP marketplace** | Often implies install UX or commercial packaging | May include review, hosting, or one-click connect — not required for a registry |

MCP Harbor’s product UI is branded **Browse MCP servers · MCP Registry**. Functionally it is a registry with a human browse surface *and* an agent-native MCP endpoint. Calling it a directory or catalog is fair in conversation; calling it a marketplace is optional marketing language. What matters for your workflow is: can you **find MCP servers**, inspect a manifest, and **install** or connect without inventing a private spreadsheet of URLs?

### Why “MCP Registry” searchers land here

When someone searches **MCP Registry**, they usually want one of four outcomes:

1. **Navigate** to a place that indexes MCP servers (official or larger mirror).
2. **Learn** what an MCP Registry is and how it relates to Model Context Protocol.
3. **Browse** popular or relevant servers (browser automation, GitHub, Stripe, Notion, docs, email, and so on).
4. **Connect an agent** so the agent can search and optionally submit servers itself.

MCP Harbor is built for all four. The official project publishes an official registry at registry.modelcontextprotocol.io (named in prose only on this page — CTAs stay on Harbor). MCP Harbor includes that whole official set, re-syncs on a schedule, adds local submissions after maintainer review, and — critically — exposes the index as an MCP server agents can call with no account. That last point is why this landing page concludes on Harbor for day-to-day discovery even when we fairly name the official upstream.

### Official registry vs MCP Harbor registry (preview)

Think of the official registry as the upstream source of many listings. Think of MCP Harbor as the browse-and-agent destination that:

- Indexes **31,486** servers (verified 2026-09-15), including **19,595** remote-hosted entries.
- Auto-syncs the official MCP Registry about every six hours.
- Lets you submit servers that enter `pending` until approved.
- Offers `search_servers`, `get_server`, and `submit_server` over Streamable HTTP at `/mcp`.
- Offers plain HTTP `GET`/`POST` under `/api/v0/servers`.
- Shows ready-made install snippets on per-server pages under `/servers/...`.

We expand the relationship in a dedicated section below. The short version: fair credit to official; primary recommendation for finding and installing remains [ai.mcpharbor.dev](https://ai.mcpharbor.dev/).


## Why Developers and Agents Need an MCP Registry

At a few dozen servers, a bookmarks file works. At a few hundred, a team wiki works until it drifts. At **30k+** servers, discovery without an MCP Registry becomes a tax on every agent session. You either attach the same three servers forever, or you burn time googling package names and hoping the README’s `npx` line still matches a maintained manifest.

### The discovery problem at 30k+ scale

Developers need answers to practical questions:

- Does a server already exist for Stripe, Notion, GitHub, Playwright, Brave Search, or Cloudflare Docs?
- Is it **stdio** (local package) or **streamable-http** / **sse** (remote URL)?
- Which **MCP tools** does it expose, and do those tool names match the job?
- What env var *names* does a local package expect (never paste secret values into a public submit)?
- Is the listing from the official registry, a Harbor seed, or a local submission still pending review?

An MCP Registry answers those questions with search, filters, and manifests instead of tribal knowledge. Without it, agents invent duplicate servers, teams fork slightly different wrappers, and “install mcp server” becomes a copy-paste lottery.

### stdio vs remote transports

MCP servers typically advertise one of these transports (as used by Harbor manifests):

- **`stdio`** — run locally via a package registry identifier (npm, pypi, oci, nuget, mcpb). Common install shapes: `npx -y <package>`, `uvx <package>`, `docker run -i --rm <image>`.
- **`streamable-http`** — connect to a hosted URL over Streamable HTTP.
- **`sse`** — connect to a hosted URL over Server-Sent Events (legacy/alternate remote style).

Why this matters for an MCP Registry: transport is a first-class filter. If your laptop cannot run Node packages in a sandbox, you may prefer remote servers. If your org blocks outbound MCP to third-party hosts, you may prefer stdio packages you control. Harbor’s agent tool `search_servers` and the HTTP API both accept transport filters so you are not scrolling past irrelevant cards.

### Trust, review status, and manifests

A registry is not a security scanner by itself, but a good MCP Registry still improves trust signals:

- **Stable reverse-DNS names** (for example `io.github.microsoft/playwright-mcp` or `com.stripe/mcp`) reduce collisions.
- **Official `server.json` shape** keeps packages vs remotes consistent across clients.
- **Origin metadata** can tell you whether a listing