Over 12,000 MCP servers across 33 registries. We've submitted to most of them. Why MCP discovery is four markets not one, and which seven channels actually matter.
There are over 12,000 MCP servers in April 2026, spread across at least 33 registries, marketplaces, and directories. We've submitted to most of them. Two indexed us before we asked. One maintainer told us to go somewhere else. One marketplace is still broken by a bug on our own account page. This is the actual shape of MCP distribution right now, and why treating it as a single market is the first mistake.
Most advice about MCP distribution in 2026 reads like a submission checklist. Add to Glama, add to Smithery, add to mcp.so, add to the Official Registry, post to Reddit, write a dev.to article. Tick the boxes and wait.
That's not what we found. After listing four MCP products (Memory, CRM, Crew, GEO) across more than 20 platforms over the past two months, we learned that MCP discovery is not one market. It is four different markets with different rules, different gatekeepers, and different economics. The teams that win are the ones who understand which market matters for their product and which don't.
Here's the map.
The MCP Discovery Problem, Concretely
A year ago, the complete list of MCP servers was a GitHub README with about forty entries. Today Glama indexes over 21,500 open-source MCP servers. MCP.so has more than 20,000. PulseMCP sits at 12,650. MCP Market claims over 10,000 across 23 categories. Smithery hosts 7,000 to 8,000 depending who you ask. More than 300 MCP-compatible clients now exist, and the official SDKs cross 97 million monthly downloads.
The ecosystem is real. The problem is that none of these numbers overlap cleanly. A server listed on Glama is often also on MCP.so and PulseMCP. A server listed on Smithery may not be anywhere else. A server listed only on GitHub with a good README might get auto-pulled into Glama within a week and never reach Smithery. The Official MCP Registry, which launched in preview September 2025 and is maintained by a steering group of Anthropic, GitHub, PulseMCP, and Microsoft, was supposed to unify this. In practice it has become another entry in the list, not the index above the list.
If you are shipping an MCP server today, you will be told to submit everywhere. That's bad advice. It takes hours, yields diminishing returns fast, and misses what matters: each directory exists for a specific type of user, and some of those users have nothing to do with your product.
Four Markets, Not One
The directories sort cleanly into four groups once you stop looking at them alphabetically.
The first market is the protocol registry: the official canonical source maintained by the spec authors. It exists to answer one question, "does this server follow the protocol?", and its primary audience is other registries and tooling.
The second market is the community directories: Glama, PulseMCP, MCP.so, MCP Market. Their users are developers trying to find servers to install. They compete on size, freshness, and how useful their metadata is (security badges, weekly visitor counts, tool listings).
The third market is the awesome-lists: curated GitHub repositories like punkpeye/awesome-mcp-servers with 84,000 stars, and the smaller but growing awesome-remote-mcp-servers. These are built for skimmers. People who don't want to browse a marketplace, they want a list of known-good things to copy into their config.
The fourth market is the monetization platforms: Smithery, MCPize, AgenticMarket. These are distribution channels with built-in payment rails, hosting, and revenue share. They care less about whether your server is findable in a search and more about whether it generates transactions.
A submission strategy that treats all four as equivalent optimizes for none of them. Let's walk through what each one actually rewards.
The Official Registry Is More Useful Than It Looks
The official registry at registry.modelcontextprotocol.io doesn't look like much. A plain list, a minimal web UI, a GitHub repo with an mcp-publisher CLI. It doesn't promote, doesn't rank, doesn't recommend.
That's the point. The registry is designed as upstream metadata for everyone else to consume. When Claude Desktop, Cursor, VS Code Copilot or another client starts looking for verified MCP servers, this is the first place they reach for. When Glama, LobeHub or a future meta-registry wants a canonical feed, this is where they pull from.
Submission is slightly fiddly. You generate an Ed25519 key, host the public key at /.well-known/mcp-registry-auth on your domain, authenticate the mcp-publisher CLI, and publish a server.json with reverse-DNS naming (io.yourdomain/servername). There is no npm account required for hosted servers, and the CONTRIBUTING doc explicitly forbids PRs. It's CLI or nothing.
You want to be here. Not because users will find your server by browsing the registry, they won't. But because every downstream directory eventually pulls from it. For our four MCP products, the registry listing happened once. Everything else indexed faster afterwards.
Community Directories: Optimize for Auto-Indexing First
The community directories (Glama, PulseMCP, MCP.so, MCP Market) are where browsing users actually discover servers. This is also where most distribution advice stops: submit to these, get users, done.
The trick is that most of them auto-index if you set things up right. Glama automatically crawls public GitHub repositories with proper MCP manifests, updates daily, and assigns each server a score badge based on signals like README quality, license, and activity. PulseMCP does similar indexing and adds an interesting data point, weekly visitor counts per server, which doubles as social proof once you have traction. Apigene's analysis notes Glama's security scorecards as the single biggest differentiator. Since over one third of public MCP servers have SSRF vulnerabilities, users are starting to filter on that.
MCP.so and MCP Market have faster indexing but need a manual submit form. Both take about two minutes and auto-pull your README. MCP Market also does a manual review before listing.
The practical order: publish a clean public GitHub repo with a proper manifest, wait three to seven days for Glama to auto-index, then submit to MCP.so, MCP Market, and FastMCP manually. PulseMCP indexes automatically but an email to hello@pulsemcp.com accelerates it.
There is one structural warning. TrueFoundry's analysis points out that these directories compete partly on size, which means many of them auto-ingest everything they can find. The result is that a directory listing "20,000 servers" might include hundreds of dead repos, abandoned forks, and low-quality duplicates. Being in a 20,000-server directory is less meaningful than being one of 254 curated entries on a tightly filtered list.
The Hosted vs OSS Split Nobody Talks About
This is the lesson that cost us the most time. The curated awesome-lists are not one category but two, and the divide is invisible until you hit it.
We submitted two PRs to punkpeye/awesome-mcp-servers in early April. One for our Memory server, one for our CRM server. Both were closed within days. The reason was non-github-url. The maintainer, Frank Fiegel, accepts only github.com/* URLs in that list. Hosted services like memory.studiomeyer.io are rejected on principle, regardless of quality, license, or manifest correctness.
This is not arbitrary. Fiegel also runs Glama, and he has built a parallel destination called glama.ai/mcp/connectors specifically for hosted services. When a hosted PR gets closed, the maintainer's response literally tells you to submit there instead. The awesome-list is for OSS, the Connectors directory is for hosted. Clean separation, one maintainer, two destinations.
We misread this for weeks. Twice. The right move for hosted products was to skip punkpeye/awesome-mcp-servers entirely and go directly to awesome-remote-mcp-servers (smaller, around 1,000 stars, but accepts hosted URLs) plus Glama Connectors. For OSS MCP servers, punkpeye/awesome-mcp-servers is still the prize. An 84K-star README on the front page of GitHub is hard to beat for organic discovery.
If you are shipping a hosted MCP service, stop submitting to punkpeye/awesome-mcp-servers. If you are shipping OSS, it's still worth the PR. Most teams are mixing these up.
Monetization Platforms Are Immature but Improving
The fourth market is where money actually changes hands. This layer is the least mature of the four and the most rapidly evolving.
Smithery is commonly described as "Docker Hub for MCP." Its smithery mcp publish CLI is the cleanest developer experience in the space, and it hosts remote execution for servers that don't want to run their own infrastructure. When it works, it's excellent. When it doesn't, it's genuinely broken. The "Organization context required" bug has been blocking some accounts, ours included, for weeks, and there's no obvious escalation path.
MCPize is the platform we've had the most success with. It handles Cloud Run hosting, takes an 85% revenue share back to the creator, and has a working billing integration for MCP servers that want to charge per call. The tradeoff is that you have to follow its buildpack conventions. Cloud Run has no IPv6 egress, Supabase Direct connections are IPv6-only, so your database URL needs to route through the Supavisor pooler. Miss that and your container starts, sessions open, and tool calls silently timeout. We burned a day on that one.
AgenticMarket is the newest entrant, with a Founding Creator program limited to 100 slots and per-call pricing built in. Worth a look if you're shipping a paid MCP server today.
The honest read on this layer: building a monetization marketplace for MCP is the kind of idea every second indie developer has right now, and the oversaturation is showing. One recent Reddit comment captured it well: "Building a marketplace for this is low hanging fruit, way too oversaturated." We still use MCPize because the revenue share and gateway are legitimately useful. We don't expect most of these platforms to survive the next eighteen months.
What I'd Submit to If I Were Starting Today
Seven channels, in order.
First, publish a public docs-only GitHub repo under a clean organization name. Keep your actual server code private if you want, but the docs, manifest, and install instructions must live on github.com. This is the prerequisite for everything else.
Second, submit to the Official Registry. It's the upstream that everyone else eventually drinks from.
Third, wait for Glama to auto-index. If it hasn't picked you up in a week, submit manually at glama.ai/mcp/connectors for hosted, or let the auto-crawler find your repo for OSS.
Fourth, submit to MCP.so, MCP Market, and FastMCP via their web forms. Combined time, ten minutes.
Fifth, decide on a monetization platform. MCPize if you want a payment rail. Smithery if you want developer brand. Both only if you have billing to expose.
Sixth, ship a VS Code extension. Not a marketplace submission, an actual thin-client extension that connects to your hosted URL. No approval queue, instant live after vsce publish. The MCP clients built on top of VS Code Copilot are the fastest-growing user segment.
Seventh, write honestly about what you've built. One dev.to article on a new account, one Reddit post in r/mcp, one Show HN when you have paying customers. Do not post all three the same week.
That's it. Seven channels, one afternoon of setup, and it reaches more users than cargo-culting a 33-directory submission spreadsheet that includes three sites abandoned since 2025.
What This All Means
The MCP marketplace layer in 2026 is not bad. It's just fragmented in a way that rewards understanding over effort. The teams losing distribution right now are not the ones who submitted to too few places. They are the ones who submitted to too many without understanding which market each submission serves. Discovery is broken at the index level and solid at the specialist-directory level. Billing is still early. Curated lists are split into hosted and OSS factions that nobody warns you about.
We build MCP servers as part of our core service at StudioMeyer, and we've learned this the slow way. If you are building one too, the shortest path is a clean public repo, the Official Registry, Glama, and two or three specialist directories. Skip the rest until you can measure whether they sent anyone.
If you want to see what the full distribution stack looks like in practice, we publish our MCP servers as hosted endpoints at memory.studiomeyer.io, crm.studiomeyer.io, crew.studiomeyer.io, and geo.studiomeyer.io, with the docs-only GitHub repos at github.com/studiomeyer-io. The blueprint is open, the tradeoffs are documented, and the submission experience is still live. Feel free to copy the pattern. The ecosystem needs more competent distribution, not more marketplaces.
Matthias Meyer
Founder & AI Director at StudioMeyer. Has been building websites and AI systems for 10+ years. Living on Mallorca for 15 years, running an AI-first digital studio with its own agent fleet, 680+ MCP tools and 6 SaaS products for SMBs and agencies across DACH and Spain.
