The Complete Guide to MCP Server Registries: Where to List, How to Submit, and What to Know

You built an MCP server. Now where does it go?

I recently went through the process of publishing our Parallect MCP tool to a few different registries. If you haven't checked it out, Parallect is a deep research tool that fans out queries to multiple AI providers and synthesizes the results. We built an MCP server for it so developers could plug it directly into their workflows. When I started publishing it to some of the registries so that it can be discovered, I found that there are a lot and the submission process for each is a bit different. So I figured I'd put together this guide for future reference, hopefully it's useful to anyone else in the same boat.

As of early 2026, there are thousands of MCP servers out there. Tools for talking to databases, managing files, querying APIs, you name it. But building the server is only half the battle. If nobody can find it, nobody can use it.

There are several major platforms where you can list your server, and they all work a bit differently. Some are curated, some are community-driven, and one is the official metadata backbone of the whole protocol. This guide covers each of them, what they are, how to get listed, what transports they support, and a cross-listing strategy that actually makes sense.

A Quick Primer on MCP Transports

Before getting into the registries, it helps to understand the three transport types. These determine how clients connect to your server, and some registries care about which one you use.

stdio (Standard I/O): The client launches your server as a local subprocess and talks to it via stdin/stdout using newline-delimited JSON-RPC 2.0. This is the go-to for local servers. The MCP spec says clients "SHOULD support stdio whenever possible." Servers should bind only to localhost for security.

Streamable HTTP: The current standard for remote servers. One HTTP endpoint handles both directions: POST for client-to-server, GET with SSE for server-to-client streaming. It supports optional session IDs for stateful stuff. If you're building a new remote server, this is what you want.

SSE (HTTP+SSE): The old transport from protocol version 2024-11-05, kept around for backwards compatibility. Don't use it for new projects. If you need to support older clients, implement both and let clients try Streamable HTTP first, falling back to SSE on 4xx errors.

The Registries

1. Official MCP Registry

URL: registry.modelcontextprotocol.io

This is the canonical source. The Official MCP Registry is a community-owned metadata repository backed by Anthropic, GitHub, PulseMCP, and Microsoft. It launched in preview around September 2025.

The important thing to understand is that it only stores metadata. Your server.json manifest points to where the server actually lives: npm, PyPI, Docker Hub, GHCR, Google Artifact Registry, or Azure Container Registry. The registry itself doesn't host any code.

How to submit:

Everything goes through the mcp-publisher CLI. No web form, no PRs. The workflow:

1. Publish your package to npm, PyPI, Docker Hub, or another supported artifact registry
2. Run mcp-publisher init to generate a server.json manifest
3. Authenticate using one of:
   • GitHub OAuth for io.github.username/* namespaces
   • DNS TXT record for custom domain namespaces (e.g., com.yourcompany/*) using Ed25519 key pairs
   • HTTP .well-known/mcp-registry-auth file verification
4. Run mcp-publisher publish

Server names use reverse-DNS notation (e.g., io.github.username/server-name) and namespace ownership is cryptographically verified.

There are also per-package verification quirks: npm packages need "mcpName" in package.json, PyPI packages need mcp-name: $SERVER_NAME somewhere in the README, and Docker/OCI images need the io.modelcontextprotocol.server.name annotation matching what's in server.json.

Transport support: All of them. It's transport-agnostic at the metadata level.

Private repos: You don't have to open-source your code. Closed-source servers with publicly accessible artifacts work fine. The only hard rule is that the artifact can't be locked behind a private network or private package registry. If you need a private catalog for your org, you can self-host a compatible registry using the published OpenAPI spec, run it as a Docker container, or use Azure API Center.

Worth noting: Still in preview, so expect possible breaking changes. Publishing here can automatically propagate to Smithery and PulseMCP since they ingest from this registry. List here first.

2. Smithery

URL: smithery.ai

Smithery is a marketplace and managed gateway with around 6,000 servers. The big selling point is how easy it makes integration: they handle OAuth, provide a CLI installer, and proxy remote connections through their gateway.

How to submit:

Two ways in:

• Web dashboard at smithery.ai/new
• Smithery CLI via smithery mcp publish

For remote servers, you need a public HTTPS endpoint. Local servers can be distributed as MCP bundles (MCPB format). If you've already published to the Official Registry, Smithery may pick it up automatically since they ingest from there.

Once you publish, Smithery scans your server to pull out tools, resource schemas, and prompts. If scanning fails because of auth requirements, you can put a static /.well-known/mcp/server-card.json on your server as a fallback.

Transport support: Remote servers need Streamable HTTP specifically. Local servers use stdio via MCP bundles.

Private repos: The most flexible option here. Your source code can stay private. Plenty of commercial servers are listed on Smithery without open-sourcing anything. Just need a reachable endpoint.

Security note: In October 2025, Smithery had a path traversal vulnerability that exposed around 3,000 hosted servers and API keys. Worth checking their current security posture if you're deploying anything with sensitive credentials through their infrastructure.

3. Glama

URL: glama.ai/mcp/servers

Glama takes a different angle: quality curation. They index around 7,500 remote servers and 3,600 local ones, and each gets a scorecard covering security, licensing, docs quality, and operational readiness. If you care about your server's reputation, getting a good Glama score is worth the effort.

How to submit:

A few ways to get listed:

• Use the "Add Server" button on their site
• Submit a PR to their community-managed listings
• Drop a glama.json metadata file in your repo for automatic discovery
• Do nothing and wait for their GitHub crawler to find you (they also pull from the Official Registry)

You can verify your project via GitHub login to get an "Author verified" badge on your listing.

Transport support: All types. They categorize servers as Remote, Local, or Hybrid but don't restrict which transport you use.

Private repos: Geared toward public projects. Their crawler won't find private repos, and even if you submit manually, they may not be able to pull much metadata without code access.

Glama also has its own MCP server ("Glama MCP") that AI assistants can use to search the directory. Kinda meta.

4. MCP.so

URL: mcp.so

MCP.so is the community-driven option with around 19,000 servers listed. It's open-source itself and leans into grassroots contribution.

How to submit:

Just use the submission form at mcp.so. Fill in your server name, description, features, and connection details. That's it.

Transport support: No restrictions.

Private repos: They call themselves an "Open-Sourced MCP Servers Directory," but in practice you can probably get listed if you provide enough public-facing info about how to connect and use it. You'll need some kind of public presence though.

They also have a personal dashboard for managing your listings and a feed showing recently added servers.

5. Awesome MCP Servers (GitHub)

URL: github.com/punkpeye/awesome-mcp-servers

Heads up: As of writing this, the main punkpeye repo is returning a 404. Not sure if it got taken down, moved, or is temporarily unavailable. There are a few other forks and competing lists floating around (appcypher, wong2, sammcj all maintain their own versions), so if the primary one is still dead when you're reading this, check those out instead.

When it's up, this is a classic GitHub "awesome list" organized by category: databases, browser automation, file systems, productivity, etc. It's manually curated, which means getting listed carries a bit of an implicit endorsement.

How to submit:

Open a pull request against the repo. Most of these lists have a CONTRIBUTING.md with the rules: add your entry in the right category, keep alphabetical order, write a short description. Pretty standard awesome-list stuff.

Transport support: They don't filter by transport. Everything is organized by what the server does, not how it connects.

Private repos: Not really an option. The whole point of the list is linking to public repos and docs. If your code is private, there's nothing to link to.

6. PulseMCP

URL: pulsemcp.com

PulseMCP is more of a discovery and tracking platform than a traditional registry. They have over 12,500 servers indexed, with popularity metrics, a weekly newsletter, and labels for "official vs. community" servers. Some of the MCP core contributors are involved in running it.

You don't really "submit" to PulseMCP. They scrape the Official Registry and GitHub, and accept community tips. If you've published to the Official Registry, you'll probably show up here on your own.

Honorable Mentions

MCP Market (mcpmarket.com): Claims around 27,000 servers with daily top lists and leaderboards. Haven't been able to verify that number independently, and submission details are thin.

OpenMCP (open-mcp.org): Does something different from the rest. It's a standard for converting existing web APIs (OpenAPI, gRPC, GraphQL, SOAP, PostgREST) into MCP servers, with CLI tooling and its own registry of converted APIs. If you already have a REST API and want to MCP-ify it without starting from scratch, this is worth a look.

Side-by-Side Comparison

Registry	Submission Method	Transports	Private Repos	Approx. Servers	Standout Feature
Official MCP Registry	mcp-publisher CLI	All (metadata-level)	Closed-source OK, public artifact required	Growing	Canonical metadata source
Smithery	Web form or CLI	Streamable HTTP (remote), stdio (local)	Fully supported	~6,000	Managed gateway + OAuth
Glama	Web form, PR, or auto-discovery	All	Public preferred	~11,000	Security scoring + curation
MCP.so	Web form	All	Public footprint needed	~19,000	Community-driven, open-source
Awesome MCP Servers	GitHub PR	All	No (links to public repos)	Curated	Editorial endorsement
PulseMCP	Auto-ingested	All	Public artifact required	~12,500	Popularity tracking + newsletter

The Recommended Listing Strategy

Cross-list. Seriously. Here's the order I'd go in:

1. Official MCP Registry first. It's the foundation. Smithery and PulseMCP both pull from it, so one publish can cascade to multiple platforms.

2. Smithery and/or Glama next. Smithery's gateway makes integration dead simple for users. Glama's scoring adds credibility. Pick one or both depending on what matters more to you.

3. MCP.so for broader reach. Quick web form, big directory, active community.

4. Awesome MCP Servers PRs if the repos are accessible. The curated nature means being listed there carries some weight.

5. PulseMCP and MCP Market will probably find you if you've done steps 1-4. Nothing extra needed.

Wrapping Up

This space is still pretty young. The Official Registry is in preview, server counts change weekly, and the platforms are still sorting out how they fit together. But the wave is here and it's only getting bigger. The approach is straightforward: publish your artifact, get it on the Official Registry with mcp-publisher, then hit Smithery, Glama, and MCP.so.

More listings means more eyeballs. Most of these platforms make it easy enough that there's no reason to skip any of them. Hope this helps you get your server out there.