MCP Registry MCP Server

---

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 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:

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:

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

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:

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:

{
  "servers": [
    {"server": {}, "_meta": {}}
  ],
  "metadata": {
    "count": 30,
    "total": 120,
    "limit": 30,
    "offset": 0,
    "next_offset": 30
  }
}

Page by setting offset to metadata.next_offset until next_offset is null. Do not invent your own off-by-one scheme — follow next_offset. For large crawls, be polite: reasonable page sizes, backoff on errors, and no tight loops that look like abuse.

Get one server by name

GET https://ai.mcpharbor.dev/api/v0/servers/<name>

Names look like io.github.acme/weather. The slash may be sent as-is or as %2F. The response is one {"server": ..., "_meta": ...} entry and works for pending submissions too — useful right after you POST.

Examples:

curl -sS 'https://ai.mcpharbor.dev/api/v0/servers/io.github.microsoft/playwright-mcp'
curl -sS 'https://ai.mcpharbor.dev/api/v0/servers/com.stripe%2Fmcp'

server.json at a high level

Harbor stores and returns official-shaped server.json manifests. At a high level (details in /llms.txt and the official schema documented there — named in prose, not linked off-host from this page):

• packages[0] — locally run server: registryType (npm, pypi, oci, nuget, mcpb), identifier, and environmentVariables to set.
• remotes[0] — hosted endpoint: type (streamable-http or sse) and url.
• _meta["io.mcpregistry/tools"] — tool names the server exposes.
• Entry _meta origin — _meta["io.mcpregistry/official"].origin may be official, seed, or local.

You do not need to memorize every schema field to use the registry. For discovery, q + transport + get_server is enough. For submit, either POST the simplified Harbor JSON fields or a full server.json — both are accepted.

HTTP troubleshooting

When in doubt, prefer the MCP tools from an agent session — they wrap the same index with install snippets already formatted — or browse https://ai.mcpharbor.dev/.

Browse Popular MCP Servers (Examples)

This section is descriptive, not a fake review farm. The examples below are real listings featured on the MCP Harbor homepage. Open live cards and per-server pages on https://ai.mcpharbor.dev/ for the freshest tool counts and install snippets.

How to use tags and transport filters in practice

Before the list, a quick method:

1. Start with a job statement: “I need browser automation,” “I need Stripe tools,” “I need docs search.”
2. Prefer transport that matches your runtime constraints (remote vs local).
3. Use tags when the UI or API exposes them (browser, documentation, payments, github, and so on).
4. Confirm tool names via get_server or the server page before you install.
5. Install from Harbor snippets rather than from a remembered blog post from six months ago.

Featured and reference examples (descriptive)

Playwright (io.github.microsoft/playwright-mcp, stdio) — Playwright tools for MCP; tagged around browser automation, testing, and web; useful when an agent must drive a real browser stack locally via a package install.

Context7 (io.github.upstash/context7, streamable-http) — Up-to-date code docs for prompts; documentation / developer-tools oriented; remote HTTP so you connect rather than run a local docs crawler.

GitHub (io.github.github/github-mcp-server, streamable-http) — Connect assistants to GitHub for repos, issues, PRs, and workflows through natural language; a common default for coding agents that live in pull-request loops.

Stripe (com.stripe/mcp, streamable-http) — Stripe integration for customers, products, payments, and related billing tools; hosted remote server pattern.

Notion (com.notion/mcp, streamable-http) — Official Notion MCP server for notes and documents productivity workflows; hosted.

Agent Email List (com.agentemaillist/agent-email-list, streamable-http) — Email sending and receiving for AI agents with a Mailgun-shaped API; agents can open a free account with create_account, verify a sending domain, send with test mode, and read inbox/delivery events. Listed on Harbor as one example among many — this landing page does not cross-promote that product’s silo; it is simply a real registry card you can open on MCP Harbor.

Brave Search (com.brave/brave-search, stdio) — Web, local, news, image, and video search via Brave Search API; needs an API key from Brave’s developer portal configured locally as an env var (name only in manifests).

Cloudflare Docs (com.cloudflare/docs, streamable-http) — Hosted documentation server searching developers.cloudflare.com so answers about Workers, R2, D1, and related products can cite current docs.

DeepWiki (com.deepwiki/mcp, streamable-http) — Hosted server from Cognition that answers questions about public GitHub repositories using DeepWiki-generated documentation; no authentication required per the Harbor card description.

Everything (io.github.modelcontextprotocol/server-everything, stdio) — Reference test server exercising MCP features (tools, resources, prompts, sampling, logging, progress). Useful for testing clients, not production workloads.

Fetch (io.github.modelcontextprotocol/fetch, stdio) — Reference server that fetches a URL and converts the page to markdown for a model, with optional raw mode and pagination.

Filesystem (io.github.modelcontextprotocol/server-filesystem, stdio) — Reference local file operations scoped to directories you pass as arguments.

Git (io.github.modelcontextprotocol/git, stdio) — Reference server for local Git status, diffs, log, commits, branches, and checkouts.

Memory (io.github.modelcontextprotocol/server-memory, stdio) — Reference knowledge-graph memory so an agent can persist entities and relations across conversations.

Sequential Thinking (io.github.modelcontextprotocol/server-sequential-thinking, stdio) — Reference structured scratchpad for step-by-step problem solving with revision/branching.

Time (io.github.modelcontextprotocol/time, stdio) — Reference time and time-zone conversion utilities.

Exa Search (io.github.exa-labs/exa-mcp-server, stdio) — Neural web search oriented to agents (live crawling, code-context search, company research); needs an Exa API key locally.

Hugging Face (com.huggingface/mcp, streamable-http) — Hosted Hub search for models, datasets, papers, and Spaces; run selected Spaces as tools.

Linear (com.linear/mcp, streamable-http) — Hosted issues/projects/cycles/comments; OAuth on first connection per card description.

Sentry (com.sentry/mcp, streamable-http) — Hosted issues, errors, traces, and performance context for debugging agents.

Supabase (com.supabase/mcp-server-supabase, stdio) — Manage Supabase projects: SQL, schemas, migrations, logs, edge functions — with project scoping and read-only modes where available.

Newer and niche cards also appear on the homepage

Harbor’s browse UI also surfaces many community and niche servers (image/video generation, WhatsApp bridges, Godot harnesses, homelab helpers, prediction-market data, Adobe Photoshop control, and more). Treat the homepage as a living shelf: sort and search rather than memorizing this article. The point of an MCP Registry is that the index updates; this page teaches the method.

CTA back to live browse

Descriptions go stale; the registry does not have to. Browse live MCP servers → https://ai.mcpharbor.dev/

Install Patterns: stdio vs Remote

Finding a server is only half the job. Installing or connecting it correctly is the other half. Harbor’s rule of thumb: copy snippets from get_server or from the per-server HTML page on ai.mcpharbor.dev, then adapt env vars locally.

Local package runners (stdio)

From product docs in /llms.txt:

• npm package: npx -y <package>
• pypi package: uvx <package>
• oci image: docker run -i --rm <image>

These commands are templates. The real identifier comes from the manifest’s package fields. Never invent a package name because a blog post looked similar — resolve it through the MCP Registry first.

Remote URL connect (streamable-http / sse)

For hosted servers, you connect to the remote url with the given transport. In Claude Code style flows that often means an HTTP transport add with the remote server’s URL (not Harbor’s /mcp URL — Harbor’s /mcp is the registry; the remote server URL is the tool provider). Keep those two mental slots separate:

1. Registry connection — https://ai.mcpharbor.dev/mcp so you can search.
2. Workload connection — the specific Stripe/Notion/GitHub/Docs URL from that server’s manifest.

Claude Code add patterns

Docs summarize:

claude mcp add -- <npx -y package-or-equivalent>

or for a remote server:

claude mcp add --transport http <name> <remote-url>

And for the registry itself (again):

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

Exact flags can evolve with Claude Code releases; if a flag errors, check your client’s help — the Harbor URL and transport intent remain stable.

Env vars: names only, secrets locally

Manifests may list environment variable names such as WEATHER_API_KEY or a vendor API key name. Configure the values in your local secret store, shell profile, or client env configuration. When submitting servers to Harbor, env_vars holds names only — never send secret values in POST bodies or submit_server arguments. Secrets in a public registry payload are a permanent leak.

Per-server pages beat memory

Each server’s HTML page at https://ai.mcpharbor.dev/servers/... shows ready-made snippets. Bookmarking a Harbor server page is safer than bookmarking a random README that might document an old binary name. If your team shares an internal “approved MCP servers” list, link those Harbor pages (on ai.mcpharbor.dev) rather than pasting bare npx lines into a wiki that nobody updates.

Install decision tree

Use this when you are stuck between stdio and remote:

1. Does your environment allow outbound MCP HTTP to the vendor? If no, prefer stdio packages you can run inside your network boundary.
2. Do you need zero local runtime (no Node/Python/Docker)? Prefer streamable-http remotes.
3. Is the server a reference implementation for learning? Prefer official reference stdio servers (Everything, Fetch, Filesystem, Git, Memory, Time, Sequential Thinking) from the registry cards.
4. Are you still discovering? Keep Harbor /mcp connected permanently; add workload servers only when a task needs them.
5. Did install fail? Re-fetch get_server — you may have an outdated identifier — then retry.

Common install failures and fixes

Mid-article CTA

When you are ready to install for real, start from a live card:

Find a server, open its page, copy the snippet → https://ai.mcpharbor.dev/

Submit a Server to the MCP Registry

Anyone may add a server, and agents are welcome to. That openness is deliberate: the ecosystem grows when builders can publish without filing a ticket. Harbor keeps search quality with maintainer review before new local listings appear in search results.

Who can submit

• Human maintainers publishing their MCP server.
• Agents acting on behalf of a team after a server is built and documented.
• Anyone who can craft a valid JSON body or server.json manifest.

You do not need a Harbor account for ordinary submit. Search first with search_servers or GET /api/v0/servers so you do not add a duplicate.

POST over HTTP

POST https://ai.mcpharbor.dev/api/v0/servers
Content-Type: application/json

Example body from product docs:

{
  "name": "io.github.acme/weather-mcp",
  "title": "Weather",
  "description": "Forecasts and severe-weather alerts by location.",
  "version": "1.0.0",
  "transport": "stdio",
  "package_registry": "npm",
  "package_identifier": "@acme/weather-mcp",
  "env_vars": ["WEATHER_API_KEY"],
  "tools": ["get_forecast", "get_alerts"],
  "tags": ["weather"],
  "repository_url": "YOUR_REPO_URL",
  "license": "MIT"
}

A server.json manifest in the official registry’s format is accepted too. Over MCP, call submit_server with the same information.

Note on the example repository_url: that field may contain a third-party repository URL as data inside JSON. This article still does not turn third-party hosts into markdown hyperlinks; CTAs stay on Harbor.

Naming rules (reverse-DNS)

name is a reverse-DNS namespace, a slash, and a short name. For a GitHub-hosted project, the conventional pattern is io.github.<owner>/<repo-or-short-name>. Pick names that will not collide with official vendors (com.stripe/..., com.notion/..., and similar). Bad names are a common 422 cause.

Transport field rules

• stdio — requires package_registry and package_identifier.
• streamable-http or sse — require remote_url.
• package_registry — one of npm, pypi, oci, nuget, mcpb.

Mismatch these and validation fails. Fix the named fields and resend.

Review / pending status

New listings are reviewed by a maintainer before they appear in search. Until approval, get_server (or GET-by-name) reports "status": "pending". That is expected, not an error. Tell your agent not to panic-retry submit when status is pending — retrieve instead.

Response codes you should handle

Submit checklist (humans and agents)

Documentation truncated — see the full README on GitHub.