Es gibt über 12.000 MCP-Server im April 2026, verteilt auf mindestens 33 Registries, Marketplaces und Directories. Wir haben uns bei den meisten beworben. Zwei haben uns indexiert, bevor wir überhaupt gefragt haben. Ein Maintainer hat uns weggeschickt. Ein Marketplace ist seit Wochen durch einen Bug auf unserem Account blockiert. Das ist der tatsächliche Zustand der MCP-Distribution gerade. Und warum es der erste Fehler ist, das Ganze als einen Markt zu behandeln.
Die meisten Ratgeber zur MCP-Distribution in 2026 lesen sich wie Einreichungs-Checklisten. Bei Glama listen, bei Smithery listen, bei mcp.so listen, beim Official Registry einreichen, auf Reddit posten, einen dev.to-Artikel schreiben. Haken dran, warten.
So funktioniert das nicht. Nachdem wir vier MCP-Produkte (Memory, CRM, Crew, GEO) über die letzten zwei Monate auf mehr als 20 Plattformen gelistet haben, haben wir gelernt: MCP-Discovery ist nicht ein Markt. Es sind vier verschiedene Märkte mit unterschiedlichen Regeln, unterschiedlichen Gatekeepern und unterschiedlicher Ökonomie. Die Teams, die gewinnen, verstehen, welcher Markt für ihr Produkt zählt und welcher nicht.
Hier ist die Karte.
Das MCP-Discovery-Problem, konkret
Vor einem Jahr war die komplette Liste der MCP-Server ein GitHub-README mit etwa vierzig Einträgen. Heute indexiert Glama über 21.500 Open-Source-MCP-Server. MCP.so hat mehr als 20.000. PulseMCP liegt bei 12.650. MCP Market reklamiert über 10.000 in 23 Kategorien. Smithery hostet 7.000 bis 8.000, je nachdem wen man fragt. Mehr als 300 MCP-kompatible Clients existieren inzwischen, und die offiziellen SDKs kommen auf 97 Millionen monatliche Downloads.
Das Ökosystem ist real. Das Problem ist, dass sich keine dieser Zahlen sauber überlappen. Ein Server, der bei Glama gelistet ist, steht oft auch bei MCP.so und PulseMCP. Ein Server bei Smithery ist manchmal nirgendwo sonst. Ein Server, der nur auf GitHub mit einem guten README liegt, wird vielleicht innerhalb einer Woche automatisch von Glama eingesammelt und taucht nie bei Smithery auf. Das Official MCP Registry, das im September 2025 im Preview gestartet ist und von einer Steering Group aus Anthropic, GitHub, PulseMCP und Microsoft gepflegt wird, sollte das eigentlich vereinheitlichen. In der Praxis ist es ein weiterer Eintrag in der Liste geworden, nicht der Index über der Liste.
Wer heute einen MCP-Server veröffentlicht, wird die Empfehlung bekommen, überall einzureichen. Das ist schlechter Rat. Es kostet Stunden, bringt schnell abnehmende Erträge und verfehlt den Punkt: Jedes Directory existiert für eine bestimmte Nutzergruppe, und manche dieser Gruppen haben mit deinem Produkt nichts zu tun.
Vier Märkte, nicht einer
Die Directories sortieren sich sauber in vier Gruppen, sobald man aufhört, sie alphabetisch zu lesen.
Der erste Markt ist das Protocol-Registry: die offizielle kanonische Quelle, die von den Spec-Autoren gepflegt wird. Sie existiert, um eine einzige Frage zu beantworten: „Folgt dieser Server dem Protokoll?" Ihr primäres Publikum sind andere Registries und Tooling.
Der zweite Markt sind die Community-Directories: Glama, PulseMCP, MCP.so, MCP Market. Deren Nutzer sind Entwickler, die Server zum Installieren suchen. Sie konkurrieren über Größe, Aktualität und wie nützlich ihre Metadaten sind (Security-Badges, Wochen-Visitor-Counts, Tool-Listings).
Der dritte Markt sind die Awesome-Lists: kuratierte GitHub-Repositories wie punkpeye/awesome-mcp-servers mit 84.000 Sternen und das kleinere, aber wachsende awesome-remote-mcp-servers. Diese sind für Überflieger gebaut. Leute, die nicht durch einen Marketplace stöbern wollen, sondern eine Liste bekannter guter Dinge brauchen, die sie in ihre Config kopieren.
Der vierte Markt sind die Monetarisierungs-Plattformen: Smithery, MCPize, AgenticMarket. Das sind Distributions-Kanäle mit eingebauten Payment-Rails, Hosting und Revenue-Share. Denen ist weniger wichtig, ob dein Server in einer Suche auffindbar ist, und wichtiger, ob er Transaktionen erzeugt.
Eine Einreichungsstrategie, die alle vier gleich behandelt, optimiert für keinen. Gehen wir durch, was jeder einzelne tatsächlich belohnt.
Das Official Registry ist nützlicher als es aussieht
Das offizielle Registry unter registry.modelcontextprotocol.io sieht nicht nach viel aus. Eine nüchterne Liste, eine minimalistische Web-UI, ein GitHub-Repo mit einer mcp-publisher-CLI. Es promotet nicht, rankt nicht, empfiehlt nicht.
Genau das ist der Punkt. Das Registry ist als Upstream-Metadaten-Quelle für alle anderen konzipiert. Wenn Claude Desktop, Cursor, VS Code Copilot oder ein anderer Client nach verifizierten MCP-Servern sucht, ist das die erste Anlaufstelle. Wenn Glama, LobeHub oder ein zukünftiges Meta-Registry einen kanonischen Feed braucht, ziehen sie ihn von hier.
Die Einreichung ist leicht fummelig. Man generiert einen Ed25519-Key, hostet den Public Key unter /.well-known/mcp-registry-auth auf der eigenen Domain, authentifiziert die mcp-publisher-CLI und veröffentlicht eine server.json mit Reverse-DNS-Namen (io.deineddomain/servername). Für gehostete Server braucht man keinen npm-Account, und das CONTRIBUTING-Dokument verbietet explizit PRs. Entweder CLI oder gar nicht.
Du willst hier sein. Nicht weil Nutzer deinen Server durch Browsen im Registry finden werden (werden sie nicht). Sondern weil jedes Downstream-Directory irgendwann von dort zieht. Bei unseren vier MCP-Produkten ist das Registry-Listing einmal passiert. Alles andere ging danach schneller.
Community-Directories: Zuerst aufs Auto-Indexing optimieren
Die Community-Directories (Glama, PulseMCP, MCP.so, MCP Market) sind, wo browsende Nutzer tatsächlich Server entdecken. Hier enden auch die meisten Distributions-Ratgeber: bei denen einreichen, Nutzer holen, fertig.
Der Trick ist, dass die meisten automatisch indexieren, wenn du die Rahmenbedingungen richtig setzt. Glama crawlt automatisch öffentliche GitHub-Repositories mit sauberem MCP-Manifest, aktualisiert täglich und vergibt jedem Server ein Score-Badge basierend auf Signalen wie README-Qualität, Lizenz und Aktivität. PulseMCP macht ähnliches Indexing und fügt einen interessanten Datenpunkt hinzu: wöchentliche Visitor-Counts pro Server, die nach einer Weile als Social Proof wirken. Apigenes Analyse nennt Glamas Security-Scorecards als den größten einzelnen Unterscheidungsfaktor. Und da über ein Drittel der öffentlichen MCP-Server SSRF-Schwachstellen haben, fangen Nutzer an, genau danach zu filtern.
MCP.so und MCP Market haben schnelleres Indexing, aber brauchen ein manuelles Submit-Formular. Beide dauern etwa zwei Minuten und ziehen dein README automatisch rein. MCP Market macht zusätzlich noch ein manuelles Review vor dem Listing.
Die praktische Reihenfolge: Ein sauberes öffentliches GitHub-Repo mit richtigem Manifest veröffentlichen, drei bis sieben Tage warten, bis Glama auto-indexiert, dann manuell bei MCP.so, MCP Market und FastMCP einreichen. PulseMCP indexiert automatisch, aber eine E-Mail an hello@pulsemcp.com beschleunigt das.
Eine strukturelle Warnung gibt es. TrueFoundrys Analyse weist darauf hin, dass diese Directories teils über Größe konkurrieren, was bedeutet, dass viele auto-ingestieren, was sie finden können. Das Ergebnis: Ein Directory, das „20.000 Server" listet, enthält oft Hunderte toter Repos, verlassener Forks und Low-Quality-Duplikate. In einem 20.000-Server-Directory zu stehen, ist weniger wertvoll, als einer von 254 kuratierten Einträgen in einer eng gefilterten Liste zu sein.
Der Hosted-vs-OSS-Split, über den niemand spricht
Das ist die Lektion, die uns am meisten Zeit gekostet hat. Die kuratierten Awesome-Lists sind nicht eine Kategorie, sondern zwei, und die Trennlinie ist unsichtbar, bis man hineinrennt.
Wir haben Anfang April zwei PRs bei punkpeye/awesome-mcp-servers eingereicht. Einen für unseren Memory-Server, einen für unseren CRM-Server. Beide wurden innerhalb von Tagen geschlossen. Der Grund war non-github-url. Der Maintainer, Frank Fiegel, akzeptiert in dieser Liste nur github.com/*-URLs. Gehostete Services wie memory.studiomeyer.io werden prinzipiell abgelehnt, unabhängig von Qualität, Lizenz oder Manifest-Korrektheit.
Das ist nicht willkürlich. Fiegel betreibt auch Glama, und er hat ein paralleles Ziel eingerichtet, glama.ai/mcp/connectors, speziell für gehostete Services. Wenn ein Hosted-PR geschlossen wird, sagt die Antwort des Maintainers wörtlich: Reich dort ein. Die Awesome-List ist für OSS, das Connectors-Directory für Hosted. Saubere Trennung, ein Maintainer, zwei Ziele.
Wir haben das wochenlang falsch gelesen. Zweimal. Der richtige Move für Hosted-Produkte wäre gewesen, punkpeye/awesome-mcp-servers komplett zu überspringen und direkt zu awesome-remote-mcp-servers (kleiner, etwa 1.000 Sterne, aber akzeptiert gehostete URLs) plus Glama Connectors zu gehen. Für OSS-MCP-Server ist punkpeye/awesome-mcp-servers weiterhin der Preis. Ein 84K-Sterne-README auf der GitHub-Frontseite ist für organische Entdeckung schwer zu schlagen.
Wer einen gehosteten MCP-Service veröffentlicht, sollte aufhören, bei punkpeye/awesome-mcp-servers einzureichen. Wer OSS veröffentlicht, für den lohnt der PR weiterhin. Die meisten Teams vermischen das gerade.
Monetarisierungs-Plattformen sind unreif, aber entwickeln sich
Der vierte Markt ist, wo tatsächlich Geld fließt. Diese Schicht ist die am wenigsten ausgereifte der vier und die, die sich am schnellsten verändert.
Smithery wird oft als „Docker Hub für MCP" beschrieben. Die smithery mcp publish-CLI ist die sauberste Developer-Experience im Feld, und Smithery hostet Remote-Execution für Server, die keine eigene Infrastruktur betreiben wollen. Wenn es läuft, ist es exzellent. Wenn nicht, ist es ehrlich kaputt. Der „Organization context required"-Bug blockiert seit Wochen einige Accounts, unserer inklusive, und es gibt keinen offensichtlichen Eskalationspfad.
MCPize ist die Plattform, mit der wir den meisten Erfolg hatten. Sie handhabt Cloud-Run-Hosting, nimmt einen 85-Prozent-Revenue-Share an den Creator zurück und hat eine funktionierende Billing-Integration für MCP-Server, die pro Call abrechnen wollen. Der Tradeoff: Man muss den Buildpack-Konventionen folgen. Cloud Run hat keinen IPv6-Egress, Supabase-Direct-Verbindungen sind IPv6-only, also muss die Datenbank-URL über den Supavisor-Pooler laufen. Wenn man das verpasst, startet der Container, Sessions öffnen sich, und Tool-Calls laufen still in den Timeout. Wir haben einen Tag damit verbrannt.
AgenticMarket ist der jüngste Entrant, mit einem auf 100 Plätze limitierten Founding-Creator-Programm und eingebautem Per-Call-Pricing. Einen Blick wert, wenn man heute einen bezahlten MCP-Server veröffentlicht.
Die ehrliche Einschätzung dieser Schicht: Eine Monetarisierungs-Marketplace für MCP zu bauen, ist die Art Idee, die gerade jeder zweite Indie-Entwickler hat, und die Übersättigung zeigt sich. Ein kürzlicher Reddit-Kommentar hat es gut auf den Punkt gebracht: „Einen Marketplace dafür zu bauen, ist low hanging fruit, völlig übersättigt." Wir benutzen MCPize weiter, weil Revenue-Share und Gateway wirklich nützlich sind. Wir erwarten aber nicht, dass die meisten dieser Plattformen die nächsten achtzehn Monate überleben.
Worauf ich heute einreichen würde
Sieben Kanäle, in dieser Reihenfolge.
Erstens: ein öffentliches Docs-Only-GitHub-Repo unter einer sauberen Organization veröffentlichen. Der eigentliche Server-Code kann privat bleiben, aber Docs, Manifest und Install-Anweisungen müssen auf github.com liegen. Das ist die Voraussetzung für alles Weitere.
Zweitens: beim Official Registry einreichen. Es ist der Upstream, aus dem alle anderen irgendwann trinken.
Drittens: darauf warten, dass Glama auto-indexiert. Wenn es nach einer Woche nicht gefunden hat, manuell bei glama.ai/mcp/connectors einreichen für Hosted, oder den Auto-Crawler das Repo finden lassen für OSS.
Viertens: bei MCP.so, MCP Market und FastMCP über deren Webformulare einreichen. Gesamtzeit: zehn Minuten.
Fünftens: sich für eine Monetarisierungs-Plattform entscheiden. MCPize für eine Payment-Rail. Smithery für Developer-Brand. Beide nur, wenn es überhaupt Billing gibt.
Sechstens: eine VS-Code-Extension bauen. Keine Marketplace-Einreichung, sondern eine echte Thin-Client-Extension, die auf die gehostete URL verbindet. Keine Approval-Queue, sofort live nach vsce publish. Die MCP-Clients, die auf VS Code Copilot aufsetzen, sind das am schnellsten wachsende Nutzer-Segment.
Siebtens: ehrlich schreiben über das, was man gebaut hat. Ein dev.to-Artikel von einem frischen Account, ein Reddit-Post in r/mcp, ein Show HN, wenn erste zahlende Kunden da sind. Nicht alle drei in der gleichen Woche posten.
Das war's. Sieben Kanäle, ein Nachmittag Setup, und das erreicht mehr Nutzer als eine 33-Directory-Einreichungs-Tabelle abzuklappern, in der drei Seiten seit 2025 stillgelegt sind.
Was das alles bedeutet
Die MCP-Marketplace-Ebene 2026 ist nicht schlecht. Sie ist nur auf eine Weise fragmentiert, die Verständnis über Aufwand belohnt. Die Teams, die gerade bei der Distribution verlieren, sind nicht die, die an zu wenigen Stellen eingereicht haben. Es sind die, die an zu vielen eingereicht haben, ohne zu verstehen, für welchen Markt jede Einreichung überhaupt zählt. Discovery ist auf der Index-Ebene kaputt und auf der Specialist-Directory-Ebene solide. Billing ist noch früh. Kuratierte Listen sind in Hosted- und OSS-Fraktionen gespalten, vor denen niemand warnt.
Wir bauen MCP-Server als Teil unseres Kerngeschäfts bei StudioMeyer, und wir haben das auf die langsame Art gelernt. Wer selbst einen baut: Der kürzeste Weg ist ein sauberes öffentliches Repo, das Official Registry, Glama und zwei oder drei Specialist-Directories. Der Rest kann warten, bis messbar ist, ob er überhaupt Nutzer bringt.
Wer sehen will, wie der komplette Distribution-Stack in der Praxis aussieht: Wir veröffentlichen unsere MCP-Server als gehostete Endpoints unter memory.studiomeyer.io, crm.studiomeyer.io, crew.studiomeyer.io und geo.studiomeyer.io, mit Docs-Only-GitHub-Repos unter github.com/studiomeyer-io. Die Blaupause liegt offen, die Tradeoffs sind dokumentiert, und die Einreichungs-Erfahrung ist noch live. Darf gerne kopiert werden. Das Ökosystem braucht nicht mehr Marketplaces, sondern kompetentere Distribution.
