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 at MCP Harbor. Ownership disclosure: Logan Besecker owns and runs MCP Harbor and this MCP Registry at 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/

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.

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/ 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.

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 was copied from the official MCP Registry, seeded, or submitted locally.
• Pending review for new local submissions means a random POST does not instantly pollute search results.

MCP Harbor reports "status": "pending" for submissions awaiting maintainer review. get_server and the HTTP GET-by-name path still work for pending entries so submitters can check status without guessing.

Agent-native discovery (registry-as-MCP)

The decisive reason agents need an MCP Registry that is itself an MCP server: agents live in a tool loop. If discovery requires a human to open a website, paste a URL, and edit a config file every time, the agent cannot improve its own toolchain mid-task. Harbor’s registry endpoint at https://ai.mcpharbor.dev/mcp lets an agent:

1. search_servers for a capability (“browser automation”, “stripe”, “notion”).
2. get_server for install snippets and review status.
3. Decide whether to ask the human to install, or (for remote servers) connect immediately when the client supports it.
4. submit_server when the team built something new — after searching to avoid duplicates.

No account. No API key. That is the agent-native path this landing page is optimized for — and the reason “MCP Registry” for us means MCP Harbor, not a static listicle of links.

MCP Harbor MCP Registry — Product Deep Dive

MCP Harbor’s MCP Registry is the product this page sells — clearly, with live numbers, and without inventing features. Open it here: https://ai.mcpharbor.dev/.

Scale you can verify

On the homepage (verified 2026-09-15):

• 31,486 Model Context Protocol servers indexed.
• 19,595 hosted remotely.
• Includes the whole official MCP Registry, kept in sync automatically.
• Resync cadence documented in /llms.txt: about every six hours.

Those numbers move as the official set grows and as Harbor accepts local submissions. Always re-check the live homepage if you need a citation for a slide deck; this article freezes the verified snapshot above for SEO clarity.

What is included

Harbor’s index is not “a random subset of interesting servers.” It includes:

1. Official copies — listings synced from the official MCP Registry.
2. Seed / curated starters — the hand-curated starter set shown prominently on the browse UI.
3. Local submissions — servers anyone (including agents) submits via MCP or HTTP; they stay pending until a maintainer approves them for search.

Each entry’s metadata can indicate origin via _meta["io.mcpregistry/official"].origin values such as official, seed, or local (see /llms.txt for the contract). That transparency matters when you are deciding whether a listing is upstream-official or Harbor-local.

Browse UI for humans

The human path is intentionally simple: land on ai.mcpharbor.dev, browse cards, open a server page, copy an install snippet. Cards show transport (stdio vs streamable-http), reverse-DNS name, short description, tags, and tool counts. Popular examples on the homepage include Playwright, Context7, GitHub, Stripe, Notion, Agent Email List, Brave Search, Cloudflare Docs, DeepWiki, Hugging Face, Linear, Sentry, Supabase, and the official reference servers (Everything, Fetch, Filesystem, Git, Memory, Sequential Thinking, Time). We describe those examples later without fabricating reviews.

Per-server HTML pages live under https://ai.mcpharbor.dev/servers/... and show ready-made install snippets. That is the fastest path when a human already knows the server name.

MCP endpoint for agents (no account)

The registry is itself an MCP server:

https://ai.mcpharbor.dev/mcp

Transport: Streamable HTTP. Auth: none for normal use. Claude Code one-liner:

claude mcp add --transport http mcp-registry-search https://ai.mcpharbor.dev/mcp

Any other client: add a remote MCP server with "type": "http" and that URL. The same registry is also listed in the official MCP Registry under a long reverse-DNS name documenting search/find/discover/install directory/catalog/marketplace intents — useful if your client only installs from official listings, but not required to use Harbor directly.

Tools: search_servers, get_server, submit_server

Three tools cover the loop:

Tool	Job
search_servers	Find servers by text, transport, or tag
get_server	Return one server’s manifest, review status, and install snippets
submit_server	Add a server (search first to avoid duplicates)

That is the entire agent surface for discovery and contribution. There is no secret fourth tool inventing analytics dashboards or paid tiers on this page. Product docs live at https://ai.mcpharbor.dev/llms.txt.

HTTP API for scripts and non-MCP clients

Prefer curl, CI, or a language without an MCP client? Use:

• GET https://ai.mcpharbor.dev/api/v0/servers — search/list with optional q, transport, tag, limit, offset
• GET https://ai.mcpharbor.dev/api/v0/servers/<name> — one server by reverse-DNS name
• POST https://ai.mcpharbor.dev/api/v0/servers — submit (JSON body or server.json shape)

Details and response shapes are in the HTTP sections below and in /llms.txt.

Hard CTA

If you are evaluating where to browse MCP servers today, start here:

Open the MCP Registry → https://ai.mcpharbor.dev/

Connect your agent in parallel with the Claude command above, then search from inside the tool loop. That combination — human browse plus agent search — is the product.

How MCP Harbor Relates to the Official MCP Registry

Fairness matters on an owned-product page. The official MCP Registry at registry.modelcontextprotocol.io is a real upstream. MCP Harbor does not pretend to replace the official project’s role; it builds a discoverability layer on top of it and adds agent ergonomics.

Upstream: registry.modelcontextprotocol.io

The official registry is the community’s canonical publish/list surface for many Model Context Protocol servers. If you are a maintainer aligning with official schema and official distribution norms, you should know that URL. Harbor’s docs explicitly state that Harbor includes every server in the official MCP Registry and re-syncs every six hours.

What auto-sync gives you

Auto-sync means you do not have to choose between “official coverage” and “Harbor UX.” When you search on MCP Harbor, official listings are already in the index (origin official). When official adds servers, Harbor picks them up on the next sync window. You get:

• One browse UI for humans.
• One MCP endpoint for agents.
• One HTTP API for scripts.
• Official coverage without maintaining a second mental model for “where did this listing come from?” — because origin metadata tells you.

What you get extra on Harbor

Beyond the mirror/sync of official listings, Harbor adds:

1. Agent MCP search and submit — search_servers, get_server, submit_server with no account.
2. Local submit + pending review — anyone may add a server; search stays clean until approval.
3. Browse UX branded around finding MCP servers your agent can use.
4. Install snippets on per-server pages (npx / uvx / docker / remote).
5. Acceptance of official server.json on submit, so you are not locked into a proprietary payload shape.

When you might still hit the official API directly

A minority of workflows still go official-first:

• You are publishing primarily to the official registry’s process and only care about official listing state.
• Your compliance checklist requires “official host only” with no third-party browse UI.
• You are debugging sync lag and want to compare official vs Harbor for a brand-new official listing before the next six-hour window.

Those are valid. Even then, most developers and agents still want a single place to find mcp servers, filter by transport, and connect. For that daily job, this page’s conclusion does not change: use MCP Harbor’s MCP Registry.

Connect the Registry Over MCP (Agent Path)

The fastest path for coding agents is to treat the MCP Registry as just another MCP server. You connect once; after that, discovery is a tool call instead of a browser tab.

Endpoint and Claude Code one-liner

Registry MCP URL (Streamable HTTP, no auth):

https://ai.mcpharbor.dev/mcp

Claude Code:

claude mcp add --transport http mcp-registry-search https://ai.mcpharbor.dev/mcp

After that command succeeds, your Claude session can call Harbor tools the same way it calls any other MCP server. You do not create an account on MCP Harbor. You do not paste an API key. Leave Authorization headers out unless you are a maintainer using a publish token (ordinary submitters should never send Authorization — sending a wrong one can yield 401).

Other clients: type http + URL

If your client is not Claude Code, the pattern is still the same: add a remote MCP server with HTTP transport and the Harbor /mcp URL. Exact config keys differ by product, but the intent is always:

• Transport / type: HTTP (Streamable HTTP)
• URL: https://ai.mcpharbor.dev/mcp
• Name: something memorable like mcp-registry-search

Cursor and other coding agents that support remote MCP servers follow the same idea. If a client only supports stdio packages, use the human browse path on ai.mcpharbor.dev to copy an npx/uvx/docker snippet for the target server you want — and still use Harbor’s website or HTTP API for discovery. Prefer clients that can attach Harbor over HTTP so the agent can search mid-loop.

Walkthrough: search_servers → get_server → install decision

A practical agent loop looks like this:

Step 1 — search_servers. Ask for a capability in natural language mapped to a query, for example q-style text such as “playwright”, “stripe payments”, “notion”, or “cloudflare docs”. Optionally constrain transport to stdio, streamable-http, or sse, and constrain tag when you know the taxonomy (browser, documentation, payments, and so on).

Step 2 — read the hit list. Each hit should give you enough to decide whether to inspect further: name, title, description, transport, tags, tool hints. Do not install from the first fuzzy match if three servers claim the same job — open the best two with get_server.

Step 3 — get_server. Fetch the full manifest, review status, and install snippets for one reverse-DNS name. Confirm:

• Is status approved for search, or still pending?
• Is the origin official, seed, or local?
• For stdio: which package registry and identifier?
• For remote: which URL and transport type?
• Which env var names are listed (configure secrets in your local client, never in a Harbor submit payload)?

Step 4 — install or connect. Use the snippet from get_server or from the per-server page under /servers/... on ai.mcpharbor.dev. For remote servers, claude mcp add --transport http <name> <url>-style flows apply. For npm/pypi/oci, use the documented local runners.

Step 5 — optional submit_server. Only after search_servers shows nothing suitable — and only with a valid reverse-DNS name and transport fields. Prefer submitting via the tool or HTTP API documented in /llms.txt rather than inventing a parallel channel.

Troubleshooting the agent path

Symptom	Likely cause	What to try
Client cannot add remote HTTP MCP	Client only supports stdio	Browse Harbor in a browser; install a stdio target server; or switch clients
Empty search results for a known official server	Sync lag (up to ~6 hours) or typo in query	Broaden q; search by tool name; retry later; check homepage scale still looks healthy
get_server shows pending	Local submission awaiting review	Wait for maintainer approval; entry is retrievable but not in search yet
Accidental 401	You sent an Authorization header that is not the maintainers’ token	Remove the header entirely for normal search/submit
Agent proposes submitting a duplicate	Skipped search	Always search_servers first; Harbor’s own docs tell agents to search before submit

No API key, no account — what that means in practice

“No account” is not marketing fluff here; it is the security and UX model. Search and submit are open, with rate limits (429 + Retry-After on too many submissions) and maintainer review on new local listings. That combination keeps the door open for agents while preventing an instant spam flood into search results. If a tutorial tells you to “sign up for the MCP Registry API key” for Harbor search, that tutorial is wrong for this product — ignore it and use https://ai.mcpharbor.dev/mcp.

Connect your agent to the MCP Registry → use the Claude command above, or open https://ai.mcpharbor.dev/ and follow the agent panel.

Find Servers Over HTTP

Not every workflow speaks MCP. CI jobs, custom dashboards, and quick terminal checks often want plain HTTP. Harbor exposes a small, documented API under /api/v0/servers. Full contract: https://ai.mcpharbor.dev/llms.txt.

List and search: GET /api/v0/servers

GET https://ai.mcpharbor.dev/api/v0/servers?q=&transport=&tag=&limit=30&offset=0

Every parameter is optional:

Param	Role
q	Matches name, title, description, tags, and tool names
transport	One of stdio, streamable-http, sse
tag	Tag filter
limit	Page size (example default posture in docs: 30)
offset	Pagination offset

Example — find remote documentation servers:

curl -sS 'https://ai.mcpharbor.dev/api/v0/servers?q=documentation&transport=streamable-http&limit=30&offset=0'

Example — find stdio browser-related servers:

curl -sS 'https://ai.mcpharbor.dev/api/v0/servers?q=browser&transport=stdio&limit=30'

Response shape and pagination

A successful list response looks like: