Claude Plugin veröffentlichen: vom eigenen Workflow ins Verzeichnis
Ein Claude Plugin veröffentlichen lässt sich seit dem 25. September über ein neues Entwicklerportal vorbereiten und verfolgen. Für Softwareanbieter und Teams mit wiederverwendbaren Arbeitsabläufen entsteht damit ein direkter Weg zu Claude-Nutzern. Dieser Leitfaden behandelt die Einreichung, die nötige Produktvorbereitung und den laufenden Betrieb. Die Auswahl und Installation bestehender Erweiterungen erläutert unser separater Marketplace-Ratgeber.
Claude Plugin veröffentlichen: Was das neue Portal bietet
Anthropic öffnete das Portal für Entwickler mit einem kostenpflichtigen Claude-Plan. Eingereicht werden können ein entfernter MCP-Server oder ein auf GitHub liegendes Plugin-Paket. Automatische Validierung, Sicherheitsscan und Review begleiten die Einreichung. Nach erfolgreicher Prüfung bestimmt der Anbieter den Veröffentlichungszeitpunkt. Anschließend stehen Nutzungs- und Entdeckungsdaten bereit, etwa Installationen nach Oberfläche und Version sowie Suchbegriffe, über die der Eintrag gefunden wurde. Quelle: Build plugins for Claude, 25. September 2026.
Ein Plugin ist damit auch ein betreutes Produkt: Nutzer brauchen eine verständliche Beschreibung, einen funktionierenden Einstieg und jemanden, der Fehler bearbeitet. Plane diese Aufgaben vor der Einreichung ein. Ein öffentlich auffindbarer Eintrag bringt wenig, wenn die erste Anmeldung scheitert oder niemand erklären kann, welche Daten verarbeitet werden. Für die Käuferperspektive hilft unser Überblick zum Claude Marketplace.
MCP-Connector, Skill oder gemeinsames Paket?
Laut Entwicklungsdokumentation können Plugins MCP-Connectoren, Skills und optional interaktive Oberflächen kombinieren. Ein Skill vermittelt einen Ablauf; ein MCP-Server verbindet Claude mit einem Dienst oder Datenbestand. Welche Komponenten funktionieren, hängt auch von der verwendeten Claude-Oberfläche ab. Prüfe daher vor der Entwicklung die offizielle Bauanleitung und die Funktionsübersicht nach Plattform.
Unsere Entscheidungshilfe: Soll Claude nur ein klar definiertes Format aus vorhandenen Dateien erzeugen, starte mit einem Skill. Muss es aktuelle Daten aus deinem Produkt abrufen, ist eine technische Verbindung erforderlich. Werden beide Aufgaben gebraucht, beschreibe im Skill den fachlichen Ablauf und halte die Schnittstelle auf die nötigen Aktionen begrenzt. Ein großes Paket mit vielen unverbundenen Funktionen lässt sich schwerer erklären und testen.
Eine öffentliche Veröffentlichung passt zu einem wiederholbaren Angebot für mehrere Kunden. Ein internes Verfahren mit vertraulichen Vorlagen braucht möglicherweise nur eine Verteilung innerhalb der Organisation. Entscheide zuerst über diese Zielgruppe. Das öffentliche Verzeichnis ist kein geeigneter Ablageort für Geschäftsgeheimnisse, Zugangsdaten oder kundenspezifische Dokumente. Unser Skills-Leitfaden erklärt, wie aus einer Arbeitsanweisung ein nutzbarer Ablauf wird.
Voraussetzungen und Eigentümerschaft richtig vorbereiten
Die aktuelle Einreichungsdokumentation nennt Pro, Max, Team und Enterprise als berechtigte Pläne. In Organisationen sind Rolle und Einreichungsrecht zu beachten. Der Eintrag gehört der Organisation, aus der er eingereicht wird. Bei Plugin-Paketen muss das GitHub-Repository vor der Veröffentlichung öffentlich sein. Ein zugehöriger eigener Remote-MCP-Server wird zusätzlich als Connector eingereicht. Quelle: Publish to the directory.
Lege deshalb früh fest, welches Geschäftskonto dauerhaft verantwortlich bleibt. Dokumentiere Repository, Serverbetreiber, Supportkontakt und die Person, die neue Versionen freigibt. Bei einer Agenturleistung sollte vor dem ersten Eintrag geklärt sein, ob der Kunde oder die Agentur das Produkt besitzt. Eine technisch schnelle Einreichung über ein privates Konto kann später organisatorisch teuer werden.
Bereite außerdem eine kurze Produktbeschreibung mit drei Bestandteilen vor: die konkrete Aufgabe, die benötigten Zugänge und das Ergebnis. Schreibe beispielsweise „Erstellt einen belegten Entwurf für einen Wartungsbericht aus freigegebenen Prüfdaten“. Vermeide pauschale Versprechen wie „automatisiert den ganzen Betrieb“. Der Nutzer sollte vor der Installation verstehen, was er selbst noch prüfen und freigeben muss.
Pilotvorschlag: ein Plugin für Wartungsberichte
Eigenes Beispiel: Ein Softwareanbieter möchte aus seinen Wartungsdaten einen strukturierten Berichtsentwurf erzeugen. Der Connector liest einen freigegebenen Auftrag samt Messwerten. Ein Skill ordnet diese Daten in die Berichtsvorlage ein und markiert fehlende Angaben. Im ersten Umfang sind keine Änderungen am Auftrag, keine Unterschriften und kein Versand an Kunden vorgesehen.
Das Team erstellt dafür zehn künstliche Prüfaufträge: vollständige Angaben, fehlende Werte, widersprüchliche Termine und ein Auftrag ohne Zugriffsrecht. Ein Fachmitarbeiter definiert zu jedem Fall, welche Fakten im Ergebnis vorkommen müssen. Besonders wichtig ist die Unterscheidung zwischen „nicht geprüft“ und „ohne Mangel“. Das Plugin darf fehlende Informationen nicht in positive Prüfergebnisse umdeuten.
Der Test misst die Qualität des freigabefähigen Berichts. Erst wenn Fundstellen, offene Punkte und Ausgabestruktur stimmen, wird eine größere Testgruppe eingeladen. Die Beispiele enthalten keine realen Kundendaten. Spätere Schreibfunktionen wären ein eigener Entwicklungsschritt mit klarer Bestätigung vor jeder Änderung. Für den technischen Anschluss erläutern wir den Aufbau eines eigenen MCP-Servers.
Von der ersten Version bis zum geplanten Release
- Umfang festschreiben: Definiere einen Hauptanwendungsfall, ein Beispielergebnis und klare Grenzen. Eine vollständige erste Aufgabe ist wichtiger als viele halbfertige Aktionen.
- Technisch prüfen: Teste Anmeldung, Berechtigungen, Serverantworten und den Ablauf mit den vorgesehenen Oberflächen. Eine erfolgreiche Prüfung im Terminal ersetzt keinen Test im beworbenen Produkt.
- Einreichung vorbereiten: Kontrolliere Beschreibung, Repository, Lizenzen, Kontaktweg und die vorgesehenen Konten. Entferne private Testdaten und echte Schlüssel aus Paket und Historie.
- Review bearbeiten: Reiche über das Portal ein, lies die Befunde und behebe sie nachvollziehbar. Prüfe danach die betroffenen Testfälle erneut.
- Veröffentlichung terminieren: Schalte erst frei, wenn Support und Dokumentation bereitstehen. Halte die freigegebene Version fest.
- Erste Nutzung begleiten: Prüfe, ob neue Nutzer ohne persönliche Hilfe zur ersten brauchbaren Ausgabe gelangen. Bearbeite wiederkehrende Einstiegsfehler zuerst.
Die Scan- und Review-Schritte des Portals sind im Veröffentlichungsprozess von Anthropic beschrieben. Unsere Checkliste ergänzt sie um die eigene Produktabnahme. Ein bestandener Plattformscan bestätigt nicht automatisch, dass ein Bericht fachlich richtig oder jeder betriebliche Einsatz geeignet ist.
Analytics sinnvoll lesen und Updates beherrschen
Installationen zeigen Interesse. Für deine Produktentscheidung zählt zusätzlich, ob Nutzer die versprochene Aufgabe erfolgreich erledigen. Definiere dafür eine eigene, datensparsame Messung: beispielsweise gestartete Testberichte, technisch abgeschlossene Läufe und freiwillig gemeldete Probleme. Erfasse keine vollständigen Kundenunterlagen, nur um ein Diagramm zur Nutzung zu erzeugen.
Unser Betriebsvorschlag: Führe eine kleine Liste reproduzierbarer Fehlerfälle und prüfe sie vor jedem Release. Beobachte besonders Anmeldung, geänderte Datenfelder, leere Antworten und langsame Fremdsysteme. Kommuniziere Änderungen an benötigten Rechten sichtbar. Wenn eine neue Version falsche Ergebnisse erzeugt, pausiere die betroffene Funktion und stelle eine nachweislich funktionierende Fassung wieder bereit.
Ein gutes Plugin wächst aus einem klaren Arbeitsproblem und einer verlässlichen Betreuung. Ein Claude Plugin für deinen Prozess planen: Nenne uns Zielgruppe, Datenquelle und gewünschtes Ergebnis. Wir helfen dabei, den ersten Umfang zu begrenzen, den Prototyp zu prüfen und die Veröffentlichung vorzubereiten.
Quellen und Produktstand
Produktangaben wurden am 29. September 2026 geprüft. Der Zugang kann je nach Tarif und Rollout abweichen.