Claude Plugins veröffentlichen: Vom Repository ins Directory

Claude Plugins veröffentlichen: die Kurzfassung

Für die Veröffentlichung eines Claude Plugins gilt diese Reihenfolge:

1. Prüfen, ob das einreichende Claude-Konto einen Pro-, Max-, Team- oder Enterprise-Tarif nutzt.
2. Die Organisation wählen, der der Eintrag langfristig gehören soll.
3. Das Plugin mit .claude-plugin/plugin.json, README und Lizenz paketieren.
4. Den Ordner lokal testen und anschließend in ein GitHub-Repository übertragen, für das das verbundene GitHub-Konto Schreibrechte besitzt.
5. Das Entwicklerportal öffnen, Plugin bundle wählen, Repository, optionalen Plugin-Pfad sowie den überwachten Branch oder Tag eintragen und Validate ausführen.
6. Angaben zu Datenverarbeitung, Compliance, Kontakt und Updates vervollständigen und danach Submit for review auswählen.
7. Verweist das Plugin auf einen selbst betriebenen Remote-MCP-Server, für diesen Server eine separate Einreichung als MCP connector anlegen.

Das Repository darf während Validierung und Prüfung privat bleiben, sofern die Bedingungen von Anthropic für GitHub-Zugriff und Quellcode-Upload erfüllt sind. Bevor das Plugin live geht, muss es öffentlich sein.

Vor dem Portal den richtigen Eintragstyp wählen

Plugin und Connector gehören oft zusammen, sind aber nicht austauschbar. Das Plugin lässt sich als verpacktes Betriebshandbuch verstehen, der Remote-MCP-Server als besetzte Servicestelle dahinter. Das eine vermittelt Claude den Arbeitsablauf, das andere verschafft Claude Live-Zugriff auf Produkt oder Daten.

Ein Skill ist keine dritte Einreichungsart. Er gehört in ein Plugin-Bundle. Verweist dieses Bundle auf einen selbst gehosteten MCP-Server, sollten beide Produkte aus derselben Claude-Organisation eingereicht werden und dieselbe Server-URL verwenden. So kann das Portal die Einträge einander zuordnen, ohne Nutzern doppelte Tool-Sammlungen anzuzeigen.

Wem der Eintrag gehören soll

Die Wahl der Organisation ist eine langfristige Produktentscheidung, keine administrative Nebensache. Bei einem Plugin-Bundle gehört der Eintrag der ersten Organisation, die den betreffenden Repository-Ordner einreicht. Eine zweite Organisation kann dasselbe Repository mit demselben Ordner nicht erneut einreichen.

Für die Konten gelten klare Regeln:

• Bei Pro oder Max erfolgt die Einreichung über das eigene Konto.
• Bei Team oder Enterprise kann ein Owner einreichen.
• Bei Enterprise kann ein Owner die Berechtigung Directory über eine benutzerdefinierte Rolle vergeben.
• Das innerhalb dieser Claude-Organisation verbundene GitHub-Konto muss in das Repository pushen können.

Entwickelt eine Agentur das Plugin, während dessen öffentliche Identität dem Kunden gehören soll, muss die Kundenorganisation die Einreichung übernehmen. Ein späterer Repository-Transfer ist nicht dasselbe wie die Übertragung des Directory-Eintrags.

Welche Kosten auf diesem Weg entstehen

In den öffentlichen Anleitungen von Anthropic ist keine separate Gebühr für den Directory-Eintrag genannt. Ein Free-Konto kann jedoch nichts einreichen. Die finanzielle Untergrenze ist damit das kostenpflichtige Konto, das überhaupt Zugang zur Einreichung gewährt.

• Wer allein startet und noch kein Bezahlkonto hat, kann Pro bei monatlicher Abrechnung einen Monat für $20 nutzen oder im Jahrestarif $17 pro Monat bei $200 Vorauszahlung zahlen.
• Team beginnt bei zwei Personen. Zwei Standard-Plätze kosten bei monatlicher Abrechnung $50 für einen Monat oder im Jahrestarif $40 pro Monat.
• Max beginnt bei $100 pro Monat, ist für die reine Einreichung aber nicht erforderlich.

Der größere Aufwand entsteht durch die Veröffentlichung selbst. Ein gehostetes Produkt benötigt zwei vorbereitete Einreichungen: eine für das Bundle und eine für den Connector. Außerdem braucht ein Plugin ein stabiles Manifest, ein README mit mindestens 40 Wörtern, eine Lizenz, Antworten zur Datenverarbeitung, einen Prüfungskontakt und ein Repository, das öffentlich werden kann. Das neue Portal senkt den Koordinationsaufwand, weil Validierung, Scan-Ergebnisse, Prüfstatus, Veröffentlichung, Updates und Nutzung an einem Ort zusammenlaufen. Die eigentliche Arbeit entfällt dadurch nicht.

Ein veröffentlichungsreifes Plugin-Bundle vorbereiten

Ein kleinstmögliches, aber belastbares Bundle sieht so aus:

your-plugin/
  .claude-plugin/plugin.json
  skills/your-workflow/SKILL.md
  README.md
  LICENSE

Das Manifest benötigt einen dauerhaften, kleingeschriebenen name, einen für Menschen lesbaren displayName, eine version, eine aussagekräftige description, einen Autor und eine Lizenzangabe beziehungsweise eine separate Lizenzdatei. Der dauerhafte Name sollte mit Bedacht gewählt werden: displayName lässt sich ändern, der Manifest-Name definiert dagegen die Identität des Plugins.

Das README ist mehr als Repository-Pflege. Das Directory verwendet es als Material für den Eintrag, und die Validierung blockiert ein Plugin, dessen README weniger als 40 Wörter außerhalb von Code enthält. Es sollte erklären, was das Plugin leistet, wie es verwendet wird und welche Daten es sendet. Echte Zugangsdaten gehören niemals in das Repository.

Verweist das Bundle auf einen Remote-Server, kommt dessen HTTPS-Endpunkt in .mcp.json. API-Schlüssel dürfen dort nicht stehen, denn alle Nutzer erhalten bei der Installation die Plugin-Dateien.

Erst lokal testen, dann im Portal erneut validieren

Die lokale Validierung erkennt fehlerhafte Plugin-Dateien, bevor GitHub ins Spiel kommt:

claude plugin validate ./your-plugin
claude --plugin-dir ./your-plugin

Der erste Befehl prüft Dateisyntax und Schema. Der zweite startet eine Sitzung von Claude Code mit dem geladenen Arbeitsordner, sodass sich Skills und Commands praktisch erproben lassen. Die lokale Prüfung ersetzt nicht den Button Validate im Portal. Dort werden zusätzlich Directory-Anforderungen, Repository-Struktur, Namenskonflikte, Dateirichtlinien und weitere Einreichungsregeln kontrolliert.

Für diesen Praxisdurchlauf entstand ein kleines Plugin namens release-note-builder mit einem Skill und drei synthetischen Issue-Dateien: ein neuer CSV-Export für Audit-Logs, eine verbesserte Paginierung und eine Korrektur für doppelte E-Mail-Adressen. Claude Code 2.1.283 meldete Validation passed, Exit-Code 0, ohne Fehler oder Warnungen.

Danach wurde der Ordner für einen Testlauf mit claude --plugin-dir geladen. Auf diesem Rechner war keine Claude-Sitzung authentifiziert, weshalb die Anfrage noch vor einem Modellaufruf mit Not logged in · Please run /login stoppte. Eine erzeugte Release Note ließ sich daher nicht beobachten. Diese Grenze ist wichtig: Die Ordnervalidierung funktioniert lokal, ein Funktionstest setzt jedoch authentifizierten Modellzugriff voraus. Ein ausführlicherer Ablauf dafür steht im separaten Leitfaden zu Claude Code Plugin-Evals.

Die Plugin-Einreichung vollständig ausfüllen

Die öffentliche Dokumentation gliedert das Portal praktisch in sechs Phasen.

1. Quelle

Das GitHub-Repository wird als URL oder im Format owner/repo eingetragen. Liegt das Plugin unterhalb des Repository-Stammverzeichnisses, kommt der Plugin-Pfad hinzu. Für künftige Versionen kann ein Branch oder Tag gewählt werden; ohne Angabe folgt das Portal dem Standard-Branch. Danach Validate auswählen.

Die Validierung liest genau einen Commit. Nach einem gepushten Fix muss Re-validate ausgewählt werden, damit der Bericht den neuen Commit prüft.

2. Angaben zum Eintrag

Das Portal erzeugt den Eintrag aus plugin.json und dem README. Stimmen Name, Beschreibung oder Erklärung nicht, werden die Repository-Dateien korrigiert und erneut validiert. Das schafft eine nützliche Verbindlichkeit: Öffentliches Versprechen und ausgeliefertes Paket bleiben im selben Release verankert.

3. Datenverarbeitung

Anzugeben ist, ob das Plugin personenbezogene Daten liest oder speichert, Daten an andere Ziele als die deklarierten Connectoren sendet, Daten aufbewahrt oder für Personen unter 18 Jahren gedacht ist. Diese Antworten sind Teil des Produktversprechens und kein bloßes Ausfüllen eines Formulars.

4. Compliance und Kontakt

Benötigt wird eine E-Mail-Adresse, über die Anthropic die Prüfung abstimmen kann. Anschließend sind die vier verpflichtenden Bestätigungen abzuschließen. Da das Portal eine Version mit Befunden oder Änderungswünschen zurückgeben kann, sollte das angegebene Postfach tatsächlich überwacht werden.

5. Updates

Zur Wahl stehen der standardmäßige GitHub-Push-Webhook oder ausschließlich geplante Prüfungen. Beide Wege erlauben dem Directory, den überwachten Branch oder Tag zu beobachten. Für die Einrichtung des Webhooks sind Administratorrechte am Repository erforderlich.

6. Prüfen und einreichen

Nach der abschließenden Kontrolle Submit for review auswählen. Eine Organisation kann innerhalb von 24 Stunden bis zu 10 Einreichungen erstellen; Entwürfe und zurückgezogene Einreichungen zählen mit. Wer eigentlich einen vorhandenen Entwurf fortsetzen will, sollte deshalb keine Duplikate anlegen.

Den Remote-MCP-Server separat einreichen

Ruft das Plugin einen selbst betriebenen Remote-MCP-Server auf, führt der Weg zurück zu Submit new und dort zu MCP connector. Für den Connector verlangt das Portal mehr Betriebsdetails, weil hier ein Live-Dienst und kein Ordner gelistet wird.

Vorbereitet sein sollten die Server-URL, URLs für Dokumentation und Datenschutzrichtlinie, ein Icon, Testzugangsdaten für die Prüfer sowie gegebenenfalls Bilder für das MCP-App-Karussell. Der dokumentierte Ablauf umfasst Verbindung, synchronisierte Tools, öffentlichen Eintrag, Anwendungsfälle, Unternehmen, Authentifizierung, Datenverarbeitung, Testanweisungen, Compliance und die abschließende Prüfung.

Zu den öffentlichen Feldern gehören ein Servername mit bis zu 100 Zeichen, eine einzeilige Beschreibung mit bis zu 200 Zeichen, eine längere Beschreibung mit bis zu 2,000 Zeichen, eine bis fünf Kategorien, Dokumentation, Datenschutz, Support, Icon und ein dauerhafter URL-Slug. Wenn das Produkt ein Konto voraussetzt, brauchen die Prüfer zudem einen mit Daten befüllten Testzugang. Ein erreichbarer Health-Endpunkt allein macht einen Connector noch nicht einsatzbereit. Zuvor sollte jedes Tool über den MCP Inspector oder als benutzerdefinierter Connector in Claude ausgeführt werden.

Den Status als Aufgabenliste lesen

Eine feste Prüfdauer wird nicht zugesagt. Entscheidend ist weniger die Frage „Wie lange dauert das Review?“, sondern vielmehr: „Wer ist als Nächstes am Zug?“

Approved bedeutet noch nicht installierbar, Published dagegen schon. In der Standardeinstellung muss möglicherweise weiterhin ein Anthropic-Prüfer eine bestandene Version veröffentlichen. Für manche Plugins lässt sich später die automatische Veröffentlichung bestandener Updates aktivieren; eine zurückgehaltene Version wartet dennoch auf Freigabe.

Updates schon vor dem ersten Launch planen

Nach der Veröffentlichung wird entweder in den überwachten Branch gemergt oder der überwachte Tag verschoben. Das Directory liest den neuen Commit, validiert und scannt ihn auf Sicherheitsprobleme und zeigt ihn als weitere Version an. Bei jedem Release muss die version in plugin.json erhöht werden.

Ein fehlgeschlagenes oder zurückgehaltenes Update nimmt den funktionierenden Eintrag nicht offline. Bis der Ersatz live ist, liefert das Directory weiterhin die zuletzt veröffentlichte Version aus. Der Branch wird damit zum Release-Feed und ist nicht nur ein Ablageort für Quellcode.

Der Tab „Usage“ schließt anschließend den Feedback-Kreislauf. Er kann Installationen, aktive Konten, Retention, Versionsanteile, Komponentennutzung, Ladefehler, MCP-Aufrufe und Latenz, Aufrufe des Eintrags, Installationsklicks und Installationen für einen ausgewählten Zeitraum von bis zu 90 Tagen anzeigen. Die Kennzahlen werden einmal täglich in UTC aktualisiert und lassen sich als CSV exportieren. Eine Installationszahl sollte erst genannt werden, wenn das Portal tatsächlich eine erfasst hat.

Für welche sechs Teams sich das besonders lohnt

1. SaaS-Teams mit einem Remote-MCP-Produkt

Das Produktteam reicht den Live-Server als Connector ein und verpackt den passenden Workflow-Skill als Plugin. Kunden erhalten damit sowohl Tool-Zugriff als auch die Anleitung, durch die das Tool seinen Nutzen entfaltet. Das Team gewinnt Zustands- und Nutzungsdaten auf Tool-Ebene aus dem Connector sowie Installations- und Komponentendaten aus dem Plugin.

2. Anbieter von Workflow-Software

Eine Plattform für Ausgaben, Recruiting, Support oder Vertrieb kann ihren besten Betriebsablauf in einen Skill überführen und mit dem Produkt-Connector kombinieren. Der Gewinn liegt in einer besseren Nutzung: Anwender fügen einen kompletten Workflow hinzu statt einer Sammlung unerklärter API-Methoden.

3. Maintainer von Open-Source-Plugins

Der Code kann öffentlich bleiben, während das Portal als stabiler Eintrags- und Update-Kanal dem Release-Branch folgt. Solange ein neuer Commit korrigiert wird, bleibt die letzte bestandene Version verfügbar. Dadurch muss nicht jeder Push in das Repository sofort veröffentlichungsreif sein.

4. Agenturen, die Plugins für Kunden ausliefern

Eine Agentur kann den Ordner entwickeln und testen. Soll der Eintrag jedoch dem Kunden gehören, muss die Kundenorganisation ihn einreichen. Das sorgt für eine saubere Übergabe: Repository-Kontrolle, Eigentum am Directory-Eintrag, Supportkontakt und Analysen landen beim Auftraggeber statt beim Dienstleister.

5. Enterprise-Plattformteams

Ein Enterprise Owner kann ausgewählten Mitgliedern die Berechtigung Directory geben, statt eine umfassende Owner-Rolle zu teilen. So lässt sich die Release-Arbeit von der allgemeinen Organisationsverwaltung trennen, während der Eintrag in der Unternehmensorganisation verbleibt.

6. Entwickler von Claude Code-Tools, die über das Terminal hinauswollen

Ein Command oder Skill kann in das breitere Directory wechseln – allerdings erst nach einer Prüfung der unterstützten Oberflächen. Skills funktionieren in Chat, Cowork und Claude Code. Agents und Hooks laufen nicht in Chat, lokale MCP-Server ebenfalls nicht; LSP-Server bleiben ausschließlich Claude Code vorbehalten. Damit lässt sich vermeiden, dass ein Eintrag überall dasselbe Nutzungserlebnis verspricht, obwohl das Paket es technisch nicht liefern kann.

Drei Produktideen rund um das Portal

1. Plugin Release Gate – die stärkste Chance

Naheliegend ist ein GitHub-Check, der ein Plugin prüft, bevor ein Release-Branch das Portal erreicht. Er würde die lokale Validierung ausführen, README und Lizenz kontrollieren, nicht unterstützte Komponentenkombinationen markieren, die Manifest-Version vergleichen und einen Bericht zur Directory-Bereitschaft erstellen.

Die Nachfrage ist bereits sichtbar: claude code plugins kommt in den USA auf rund 5,400 Suchanfragen pro Monat, mit kommerzieller Suchabsicht und einem CPC von $6.22. Die kleinste verkäufliche Variante besteht aus einer GitHub App, einem Webbericht und einem Repository-Badge. Die entscheidende Einschränkung: Eine Portal-Freigabe darf sie nicht seriös versprechen, weil die Directory-Prüfungen und das menschliche Review von Anthropic über den lokalen Befehl hinausgehen. Ihr Wert liegt in weniger vermeidbaren Fehlern, nicht in einer garantierten Annahme.

2. Directory Listing Optimizer

Eine Berichtsschicht könnte den CSV-Export des Portals importieren und aus Aufrufen, Installationsklicks, Installationen, Herkunftskanälen, Versionen und Komponentennutzung konkrete Empfehlungen für Releases und Einträge ableiten. Zielgruppe sind Plugin-Publisher mit genug Reichweite, damit tägliche Daten einen praktischen Nutzen haben.

claude plugins erreicht in den USA rund 8,100 Suchanfragen pro Monat, zeigt kommerzielle Suchabsicht und hat einen CPC von $9.05. Ein MVP benötigt CSV-Upload, Funnel-Berechnungen, Versionsvergleich und eine wöchentliche Maßnahmenliste. Der Haken ist der Kaltstart: Vor Veröffentlichung und echter Nutzung fehlen proprietäre Daten für die Analyse. Zudem hängt das Produkt von einem Export statt von einer dokumentierten Analytics-API ab.

3. Cross-Surface Plugin Auditor

Ein statischer Scanner könnte einem Team präzise zeigen, welche Bestandteile aus einem Plugin-Ordner in Chat, Cowork und Claude Code geladen werden. Er sollte ein bin/-Verzeichnis auf oberster Ebene, Annahmen über lokale MCP-Server, in Chat ignorierte Agents und Hooks sowie Claude-Code-exklusive LSPs markieren und daraus eine Testmatrix erzeugen.

claude-plugins marketplace erreicht in den USA rund 1,900 Suchanfragen pro Monat, bei Schwierigkeit 16 und kommerzieller Suchabsicht. Das MVP wäre ein Repository-Scanner auf Grundlage der Support-Tabelle von Anthropic. Die Herausforderung liegt in der Pflege: Die Plattformunterstützung wird sich verändern, und reine Terminal-Entwickler interessieren sich womöglich nicht für eine breitere Kompatibilität.

Das Release Gate ist die beste Wette, weil es bei jeder Version zum Einsatz kommt und nicht nur beim ersten Eintrag. Außerdem ergänzt es das Portal, statt es ersetzen zu wollen.

Was das Portal nicht löst

Es macht aus einem schwachen Plugin kein nützliches Produkt. Die Validierung kann nachweisen, dass Dateien formal korrekt und richtlinienkonform sind, aber nicht, dass ein Skill Ergebnisse verbessert. Ebenso wenig garantiert sie ein identisches Verhalten der Komponenten in jeder Claude-App, eine feste Prüfdauer, ein Verified-Label auf Anfrage oder zum Launch ein Publikum, das das Plugin installiert.

Auch ein gehostetes MCP-Produkt wird nicht zu einem einzigen Eintrag zusammengeführt. Die separate Connector-Einreichung ist beabsichtigt, weil Serverauthentifizierung, Zustand, Tools und Richtlinien einen eigenen betrieblichen Datensatz benötigen.

Die einheitliche Auffindbarkeit wird in den Wochen nach dem Launch am 25. September weiterhin ausgerollt. Veröffentlicht werden sollte für die heute dokumentierten Oberflächen; eine breitere Auffindbarkeit ist künftige Distribution und keine gegenwärtige Reichweite, die sich bereits versprechen ließe.

Was am Montag zu tun ist

Zuerst die Claude-Organisation festlegen, der der Eintrag gehören soll. Danach einen echten Arbeitsablauf als Plugin-Bundle umsetzen, einen stabilen Manifest-Namen, ein nützliches README und eine Lizenz vergeben und die lokale Validierung ausführen. Ruft das Plugin einen gehosteten MCP-Server auf, wird parallel die Connector-Einreichung vorbereitet. Das Portal sollte erst geöffnet werden, wenn Eigentümerschaft und Repository-Pfad endgültig feststehen.

Wenn Plugin und produktiver Connector als ein verlässliches Release-System entstehen sollen, helfen KI-Produktionssysteme weiter.