Ein Verzeichnis, kein Marktplatz

Am 25. September hat Anthropic das Claude-Verzeichnis für externe Entwickler geöffnet. Jeder mit einem bezahlten Claude-Plan kann jetzt einen MCP-Server, eine Sammlung von Agent Skills oder beides verpacken, über ein Portal einreichen und, sobald das Review durch ist, dort gelistet werden, wo Claude-Nutzer nach Erweiterungen suchen. Die Ankündigung nennt diese Pakete Plugins und sagt, sie seien jetzt „der wichtigste Weg, Drittanbieter-Erweiterungen für Claude zu bauen“.

Die Kurzformel, die ich seitdem am häufigsten gelesen habe, lautet „Anthropic hat einen Plugin-Marktplatz gestartet“. Sie wirft zwei Dinge zusammen. Das Plugin-Verzeichnis ist kostenloser Vertrieb mit einem Review-Schritt, den der Launch-Post leichter klingen lässt als die Dokumentation, und nichts darin erlaubt dir, Geld zu verlangen. Bezahlte Produkte laufen über eine separate Bewerbung bei Claude Marketplace und werden aus dem fest zugesagten Anthropic-Budget eines Unternehmens gekauft. Und das Vertrauen, das das Wort „geprüft“ suggeriert, deckt weniger ab, als die meisten annehmen.

Ich betreibe zwei Open-Source-MCP-Server, also habe ich die Dokumentation gelesen wie jemand, der einreichen will, und dann beide Server gegen die Regeln geprüft. Keiner ist unverändert einreichbar, und die Gründe sagen viel darüber, wofür das Verzeichnis gebaut ist. Alles Folgende stammt aus Anthropics Launch-Post, seiner Dokumentation, der MCP-Spezifikation und, wo ich vergleiche, aus der Skill- und Plugin-Dokumentation der jeweiligen Anbieter, Stand 4. Oktober 2026. Wo Ankündigung und Dokumentation sich widersprechen, folge ich der Dokumentation.

Was hat Anthropic eigentlich gestartet?

Zwei Dinge, zwei Tage auseinander. Am 23. September Claude Marketplace: eine Website zum Stöbern in Plugins, Connectors, Partnerprodukten und Service-Partnern, die laut Ankündigung schon „mehr als 2,000“ Connectors und Plugins von Firmen wie Atlassian, Google, Microsoft, Notion und Salesforce enthält. Am 25. September der Teil, der für Entwickler zählt: ein Einreichungsportal unter claude.ai/directory/manage, offen für jeden mit bezahltem Plan, ohne vorher einem Partnerprogramm beitreten zu müssen.

Die beiden hängen zusammen, sind aber nicht dasselbe. Für Plugins und Connectors hat Claude Marketplace keine eigene Einreichung: Du reichst beim Verzeichnis ein, und das Verzeichnis ist das, was Claude-Nutzer in der App unter Customize > Plugins sehen. Die Dokumentation sagt das ausdrücklich:

If you came here from Claude Marketplace, the website where you browse plugins, connectors,
partner products, and service partners, you're in the right place: there's no separate Claude
Marketplace submission, and you submit to the directory instead

Geändert hat sich, wer einreichen darf. Das Verzeichnis, in dem Partner-Integrationen schon standen, nimmt jetzt Einreichungen von jedem mit bezahltem Plan an, über ein Portal und eine Review-Pipeline.

Marketplace hat durchaus eine bezahlte Seite, und die übersieht man leicht. Dieselbe Ankündigung lädt jeden, der „einen Claude-basierten Agenten oder ein Produkt verkauft“, ein, sich für ein Listing zu bewerben, und sagt, Teams „können dann einen Teil ihres zugesagten Anthropic-Budgets nutzen, um es zu kaufen“. Das ist eine separate Bewerbung, für Produkte, die an Firmen mit einer Anthropic-Zusage verkauft werden, keine Kasse für Plugins. Wer die beiden auseinanderhält, ist den größten Teil der Verwirrung um diesen Launch los.

Was ist ein Plugin, ganz konkret?

Ein Ordner. Genauer: ein Ordner mit einem Manifest unter .claude-plugin/plugin.json und beliebigen Komponentenordnern daneben. Es ist dasselbe Format, das Claude Code seit Oktober 2025 für Plugins nutzt, und das ist die leise Schlagzeile dieses Launches: Ein Claude-Code-Plugin und ein Verzeichnis-Plugin sind dasselbe Artefakt.

my-plugin/
  .claude-plugin/
    plugin.json        # name, version, description, author, license
  .mcp.json            # MCP servers the plugin brings
  skills/
    my-skill/
      SKILL.md         # an Agent Skill: name, description, instructions
  commands/            # slash commands (Markdown files)
  agents/              # subagents (Markdown files)
  hooks/
    hooks.json         # lifecycle hooks
  README.md
  LICENSE

Das Manifest ist klein. Das Beispiel aus Anthropics eigener Dokumentation:

{
  "name": "expense-reports",
  "displayName": "Expense Reports",
  "version": "1.0.0",
  "description": "File, track, and approve expense reports from a conversation, using your finance system's connector and your company's approval rules.",
  "author": { "name": "Example Corp", "url": "https://example.com" },
  "license": "MIT"
}

MCP-Server werden in .mcp.json deklariert, entweder als Remote-Server per URL oder als lokaler Befehl, den die App startet. Achte auf die Hülle mcpServers, die man leicht versehentlich weglässt:

{
  "mcpServers": {
    "expenses": {
      "type": "http",
      "url": "https://mcp.example.com/mcp"
    }
  }
}

Skills sind schlichte SKILL.md-Dateien im offenen Agent-Skills-Format: ein Name, eine Beschreibung und Anweisungen, die Claude lädt, wenn die Beschreibung zur Aufgabe passt. Eine Warnung aus der Dokumentation lohnt sich vollständig zu wiederholen, weil Leute es falsch machen werden: Leg keine API-Keys oder andere Secrets in die MCP-Datei, „denn jede Person, die das Plugin installiert, bekommt seine Dateien“.

Das Verzeichnis unterscheidet außerdem zwei Arten von Listings, und dieser Unterschied prägt alles Weitere.

Skills allein sind kein Einreichungstyp. Wenn du nur einen Skill hast, kommt er in ein Bundle. Und noch ein Name, den man auseinanderhalten sollte: claude-plugins-official, Anthropics eigener Claude-Code-Marketplace, nimmt keine Einreichungen über dieses Portal an. Selbst gehostete Claude-Code-Marketplaces, also ein Git-Repository mit einer Marketplace-Datei, funktionieren weiterhin als eigener Vertriebsweg; sie bekommen nur nicht das Review und die Reichweite des Verzeichnisses.

Wo funktioniert ein Plugin?

Nicht überall, wo es sich installieren lässt. Ein auf claude.ai hinzugefügtes Plugin wird in deinem Account gespeichert und folgt dir in Cowork und Claude Code, aber jede Oberfläche lädt laut der Seite zur Plattformunterstützung einen anderen Teil davon. Mit dieser Tabelle hätte der Launch-Post meiner Meinung nach anfangen sollen:

Die praktische Folge: Ist dein Tool ein lokaler Prozess, liefert ein Plugin es an Claude Code und an Cowork auf dem eigenen Rechner des Nutzers aus, im Chat an niemanden. Chat-Nutzer bekommen deine Skills und sonst nichts. Alles mit einem bin/-Ordner auf oberster Ebene lehnen claude.ai und Cowork rundweg ab.

Wie installierst und verwaltest du eins als Nutzer?

Über Customize > Plugins > Discover in claude.ai oder der Desktop-App. Verzeichnis-Plugins erscheinen in den Plänen Pro, Max, Team und Enterprise. Wähl eins aus, lies, was drin ist, und wähl Add. Danach landet es in Cowork, sobald du die nächste Aufgabe startest, und in Claude Code, sobald du die nächste Session mit demselben Account startest, wo es als synchronisiertes Plugin auftaucht. Claude-Code-Nutzer können ab Version 2.1.287 auch mit /plugin directory stöbern.

Zwei Details übersieht man hier leicht. Ein Plugin hinzuzufügen verbindet nichts: „Ein Plugin hinzuzufügen fügt deinem Account keinen Connector hinzu und meldet dich nirgends an.“ Einen mitgelieferten Remote-Server verbindest du separat, über den Connectors-Tab des Plugins. Und Updates kommen still:

Get updates: plugins from a marketplace or the directory update from their source. After a new
version syncs from the source, you get it on your account automatically, with nothing to accept.

Verwalten heißt: Du kannst ein Plugin per Schalter deaktivieren oder über sein Menü entfernen; einen Connector, den es mitgebracht hat, trennst du separat. In den Plänen Team und Enterprise entscheidet ein Owner, was Mitglieder sehen (Admin-Kontrollen). Jedes Plugin kann Not available, Available to install, Installed by default (Mitglieder können es ausschalten) oder Required sein (immer an, Mitglieder können es nicht entfernen). Der Standardzugriff, den ein Owner für Anthropics Verzeichnis als Ganzes festlegt, ist auf Not available oder Available to install beschränkt, und ein Owner kann das Verzeichnis als Quelle komplett entfernen. Enterprise ergänzt die Verfügbarkeit pro Nutzergruppe. Claude Code auf der Kommandozeile hat eine eigene Policy-Schicht: verwaltete Einstellungen, die Marketplaces per Allowlist zulassen oder blockieren und Installationen erzwingen.

Wer kann einreichen, und wie?

Jeder mit Pro, Max, Team oder Enterprise. Free-Accounts können es nicht. Bei Team und Enterprise reicht ein Owner ein, und bei Enterprise kann ein Owner anderen Mitgliedern über eine eigene Rolle eine Directory-Berechtigung geben. Das Listing gehört der Organisation, aus der du einreichst, und bei einem Bundle gehört ein bestimmter Repository-Ordner der ersten Organisation, die ihn einreicht. Reich also aus der Organisation ein, der das Listing langfristig gehören soll. Eine Organisation kann innerhalb von 24 Stunden bis zu zehn Einreichungen anlegen, und gespeicherte Entwürfe und zurückgezogene Einreichungen zählen mit.

Weg eins: ein Remote-MCP-Server als Connector

Du gibst dem Portal eine https://-URL und gehst durch Connection, Tools, Listing, Use cases, Company, Authentication, Data handling, Test & launch, Compliance und Review. Ein paar Anforderungen entscheiden, ob du durchkommst:

• Der Server muss remote sein und über HTTPS erreichbar. Ein lokaler Server lässt sich nicht als Connector einreichen; er kommt in ein Bundle.
• Jedes Tool braucht einen title und entweder eine readOnlyHint- oder eine destructiveHint-Annotation. Das Portal markiert Tools ohne diese.
• Du stellst Zugangsdaten für einen vollständig befüllten Testaccount bereit, die nur Reviewer sehen.
• Authentifizierung ist OAuth mit Dynamic Client Registration, OAuth mit einem Client ID Metadata Document, von Anthropic gehaltene Client-Credentials, eine eigene Verbindung, bei der Nutzer ihre eigene URL oder Zugangsdaten mitbringen, oder keine.
• Sieben Policy-Bestätigungen, alle verpflichtend, zu den Verzeichnisrichtlinien, der Nutzung der First-Party-API, Finanztransaktionen, KI-Mediengenerierung, Prompt Injection, dem Sammeln von Gesprächsdaten und öffentlicher Dokumentation.
• Listing-Material: URLs zu Dokumentation und Datenschutzerklärung, ein Support-Kontakt, ein Icon und ein URL-Slug, der nach der Veröffentlichung nicht mehr änderbar ist.
• Nutzt dein Server MCP Apps, brauchst du drei bis fünf PNG-Screenshots mit mindestens 1000 Pixeln Breite, jeweils mit dem Prompt, der sie erzeugt hat. Videos und GIFs werden nicht akzeptiert.

Die Authentifizierungsseite dokumentiert mehrere Claude-spezifische OAuth-Anforderungen für gehostete Connectors: Ein 401 ist nötig, um die Anmeldung zu starten, Claude nutzt nur den ersten Eintrag in deinen authorization_servers-Metadaten, ein Client ID Metadata Document wählt es nur, wenn deine Metadaten sowohl client_id_metadata_document_supported: true als auch none als Auth-Methode des Token-Endpoints ausweisen, dein Server muss S256 PKCE unterstützen, und die zu registrierende gehostete Redirect-URI ist https://claude.ai/api/mcp/auth_callback. Claude Code meldet sich stattdessen über einen Loopback-Callback an, dein Server muss also localhost und 127.0.0.1 unabhängig vom Port akzeptieren. Discovery-, Registrierungs- und Token-Endpoints haben 10 Sekunden für eine Antwort, Refresh-Anfragen 30. Von Anthropic gehaltene Client-Credentials und eigene Verbindungen musst du mit dem Review-Team absprechen, und Auth per statischem Header ist in einer begrenzten Beta. Ein Machine-to-Machine-Grant per client_credentials wird nicht unterstützt. Anthropics Traffic kommt aus 160.79.104.0/21, gut zu wissen, wenn du nach IP filterst.

Weg zwei: ein Plugin-Bundle aus GitHub

Vor dem Portal lokal testen: claude plugin validate ./my-plugin fängt einen Teil dessen ab, was das Portal prüft, und mit claude --plugin-dir ./my-plugin probierst du das Plugin wirklich aus. Danach testest du es auf jeder Oberfläche, die dir wichtig ist, weil Chat, Cowork und Claude Code unterschiedliche Teile davon laden. Du verbindest deinen GitHub-Account auf claude.ai (das Portal prüft, ob du in das Repository pushen darfst, und ein privates Repository braucht zusätzlich die Claude-GitHub-App), dann: Portal öffnen, Quelle eingeben und validieren (Repository, optional Plugin-Pfad, optional Branch oder Tag), Listing-Details prüfen (aus plugin.json und der README gelesen), Fragen zum Datenumgang beantworten (personenbezogene Daten, Daten an nicht deklarierte Dienste, Aufbewahrung, für unter 18-Jährige gedacht), Compliance-Schritt abschließen, prüfen und einreichen.

Das Repository kann während des Reviews privat bleiben. Der Preis: Sein Quellcode wird zum Scannen zu Anthropic hochgeladen und ist für Reviewer sichtbar, und es muss öffentlich sein, bevor das Listing live geht. Ein Claude-Code-Marketplace-Repository mit mehreren Plugins ist keine einzelne Einreichung: Jeder Plugin-Ordner wird für sich validiert und eingereicht, und Repository oder Ordner lassen sich nach dem Einreichen nicht mehr ändern.

Nach der ersten Einreichung veröffentlichst du so, wie du es ohnehin tust. Merge in den beobachteten Branch, und das Verzeichnis holt sich den Commit (standardmäßig per GitHub-Webhook, oder nach Zeitplan) und scannt ihn. Die Veröffentlichung folgt dann der Publishing-Einstellung deines Plugins, und die bedeutet standardmäßig: Du beantragst sie, und ein Reviewer veröffentlicht die Version, wie unten beschrieben. Nutzer behalten die zuletzt veröffentlichte Version, bis ihr Nachfolger veröffentlicht ist, und wenn eine neue Version den Security-Scan nicht besteht, warten spätere Versionen, bis ein Reviewer das Plugin freigibt. Setzt deine plugin.json eine Version, erhöh sie bei jedem Release. Zum Aussteigen werden Plugins über das Portal delistet, Connectors per E-Mail.

Was prüft das Review?

Jede Bundle-Version wird gescannt, und neue Listings sieht sich zusätzlich ein Mensch an. Das fängt schlampige und täuschende Verpackung ab. Für das Verhalten bürgt es nicht.

Die Validierung läuft, wenn du Validate drückst, und erneut bei jedem neuen Commit. Ihre Ergebnisse haben vier Stufen: Blocks, Held for a reviewer, Warning, Note. Was eine Einreichung blockiert, ist größtenteils Hygiene:

• eine README mit weniger als 40 Wörtern, oder keine Lizenz;
• ein reservierter Name (claude, anthropic, official, plugin, mcp oder test als kompletter Name); ein Doppelgänger einer bekannten Marke wird stattdessen zurückgehalten;
• ein Launcher, der ein nicht gepinntes Paket ausführt. npx <package>@1.2.3 oder uvx <package>==1.2.3 kommen durch, ein Versionsbereich oder @latest nicht;
• ein echtes Credential irgendwo in den Dateien, Dokumentation und Beispiele eingeschlossen;
• eine Remote-MCP-URL, die nicht https:// oder wss:// ist;
• eine Datei über 5 MiB, oder ein Repository über den Grenzwerten (50 MiB archiviert, 256 MiB entpackt, 10,000 Einträge).

Manche Entscheidungen schicken das Plugin normalerweise zu einem Menschen, sofern keine andere Regel es vorher blockiert: Binaries und kompilierte Executables unter der Größengrenze, Dateien über 256 KiB, die keine Bilder oder Fonts sind, mehr als 512 Dateien, aus einem Lockfile installierte Pakete, ein gepinntes npx- oder uvx-Paket (weil „die eigenen Abhängigkeiten des Pakets zur Installationszeit aufgelöst werden“), und ein Plugin, das ein bereits in der Umgebung des Nutzers gesetztes Credential liest und an einen Server schickt. Zurückhalten ist keine Ablehnung; es heißt, dass ein Mensch draufschaut, bevor die Version weitergeht.

Dann der Security-Scan, in Anthropics Worten:

The security scan looks for behavior that a plugin doesn't disclose, such as sending data
elsewhere, running hidden code, or changing Claude's permission settings.

Eine erste Einreichung, die den Scan nicht besteht, wird abgelehnt, und eine spätere Version, die durchfällt, kann nicht live gehen. Der Rat der Dokumentation folgt daraus: Beschreib in der README alles, was das Plugin ausführt, sendet oder abruft, und committe lesbaren Quellcode statt kompiliertem oder minifiziertem, weil zurückgehalten wird, was der Scan nicht lesen kann. Sie ergänzt, zu Recht, dass eine vollständige README ein Verhalten noch nicht erlaubt macht.

Und dann der Teil, den der Launch-Post weichzeichnet. Der Post sagt: „Veröffentliche, wenn du so weit bist.“ Die Dokumentation sagt das hier:

A version that passes every check isn't live until it's published. When the version passes,
select Publish on the plugin's page. By default, the portal records this as a request for an
Anthropic reviewer, who then publishes the version.

Selbst veröffentlichen gibt es in zwei Formen: Ein Reviewer veröffentlicht nur deine erste Version und danach veröffentlichst du selbst, oder du veröffentlichst ab der ersten Version selbst, und die Dokumentation beschreibt Letzteres als Einstellung, die ein Anthropic-Reviewer beim Freigeben deines Plugins setzt. Du wählst sie nicht selbst. Die Review-Dauer „ist nicht festgelegt“. Die Status lauten Draft, Scanning, Needs changes, In review, Approved, Published, dazu Not live yet, Delisted und Withdrawn, und die Dokumentation weist sorgfältig darauf hin, dass Approved nicht installierbar ist: Das ist nur Published.

Was deckt das Review nicht ab?

Vor allem die Zukunft. Ein Plugin-Bundle verweist per URL auf einen Remote-MCP-Server, und der Bundle-Scan liest die Dateien, die du hochgeladen hast. Der Server bekommt sein eigenes Review, wenn er als Connector gelistet wird: Community-Connectors werden gescreent, und in einem Verified-Review testet ein Mensch jedes Tool. Aber das ist ein Test des Servers, wie er an diesem Tag war, und Anthropic sagt klar, was er nicht ist:

Verification means Anthropic has reviewed the connector more closely than a Community
connector. It isn't a security audit or a guarantee of how the connector will perform. The
developer operates the connector and controls its tools, which can change after review.

Leg das neben zwei andere Fakten aus derselben Dokumentation. Tool-Änderungen an einem Connector werden auf dem Server ausgerollt, ohne erneute Einreichung. Plugin-Updates erreichen Nutzer „automatisch, ohne dass etwas zu bestätigen ist“, auch wenn jede neue Bundle-Version erneut gescannt wird. Das Verhalten, auf das es ankommt, liegt dort, wo der Entwickler es kontrolliert, und es kann sich nach dem Review ändern, ohne dass jemand gefragt wird. Ich lese das nicht als Fehler in Anthropics Design. Einen Remote-Dienst einmal zu prüfen ist alles, was überhaupt jemand tun kann. Es ist ein Grund, „im Verzeichnis gelistet“ als „wurde beim Listing geprüft“ zu lesen, und das ist eine kleinere Aussage als „ist sicher“. Das Review deckt außerdem nur das Verzeichnis ab: Plugins, die über eine Marketplace-URL hinzugefügt oder von Hand hochgeladen werden, bekommen nichts davon. Über die allgemeine Version davon habe ich vor ein paar Wochen geschrieben: Ein Connector ist ein nicht vertrauenswürdiger Autor, und das Verzeichnis ändert daran nichts.

Was bekommst du nach der Veröffentlichung?

Einen Usage tab, der bis zu 90 Tage abdeckt und nach CSV exportiert. Er zählt Installationen, aktive Accounts und Retention, schlüsselt Installationen nach Oberfläche und Herkunft auf (zum Beispiel den Discover-Tab), zeigt den Anteil der Accounts pro Version und sagt dir, wie oft jeder Skill, jeder Command, jeder Agent, jeder Hook und jeder MCP-Server tatsächlich genutzt wird. Zur Qualität meldet er Ladefehler pro Claude-Code-Version, dazu Aufrufe, Fehlerrate und Latenz für jeden MCP-Server. Und es gibt einen Verzeichnis-Funnel: Listing-Aufrufe, Klicks auf Installieren, Installationen. Die Zahlen werden einmal am Tag in UTC berechnet, und bis echte Nutzung eintrifft, zeigt der Tab Beispielzahlen mit der Markierung Preview.

Connectors bekommen ein eigenes Dashboard: ein Health-Badge (Healthy bei bis zu 2% fehlerhaften Requests, Worth a look über 2%, Degraded über 5%), einen Rang im Verzeichnis mit einem Trending-Tag, Tool-Aufrufe und Fehlerrate über 30 Tage, Latenz-Perzentile nach Produkt und die Top 15 Tools.

Der Launch-Post verspricht außerdem, dass du siehst, „welche Suchen Leute dorthin führen“. Die Metrikliste der Dokumentation enthält keine Suchbegriffe, behandle diese Metrik also als Versprechen, bis sie im Tab auftaucht. Und das Connector-Dashboard benennt seinen blinden Fleck offen: „Verbindungen, die Leute aus anderen MCP-Clients zu deinem Server aufbauen, und lokale Server, die auf dem eigenen Rechner eines Nutzers laufen, sind für Anthropic nicht sichtbar und werden nicht gezählt.“ Der Usage tab für Plugins sagt nicht, ob ein lokaler Server in einem Plugin gezählt wird, also geh nicht davon aus.

Gibt es „MCP 2.0“ wirklich?

Nicht als Name einer Spezifikation. Die MCP-Spezifikation nutzt datierte Revisionen, und die aktuelle ist 2026-07-28. Der Launch-Post sagt, Claude unterstütze „die neueste MCP-Spec, gemeinhin MCP 2.0 genannt“, und das ist ein Spitzname, höchstwahrscheinlich von den SDKs geborgt: Die Dokumentation von Claude Code beschreibt das „MCP TypeScript SDK 2.0, das die MCP-Protokollrevision 2026-07-28 hinzufügt“. MCP-Revisionen werden über ein Datum identifiziert; „2.0“ ist keine davon.

Die Revision selbst ist echt und bricht Kompatibilität. Sessions auf Protokollebene sind weg, ebenso der initialize-Handshake: Jeder Request deklariert seine Protokollversion in _meta, Server müssen einen server/discover-Aufruf implementieren, der ihre Versionen, Capabilities und Identität in einem Request zurückgibt, und Clients können ihn vor allem anderen aufrufen. Es gibt einen formalen extensions-Mechanismus. Roots, Sampling, Logging und Dynamic Client Registration sind deprecated. Die Spezifikation dokumentiert Fallback-Pfade, über die Implementierungen weiter mit älteren, handshake-basierten Servern sprechen können, bestehende Server werden durch die Revision selbst also nicht abgeschnitten.

Eine Spannung, die du kennen solltest, wenn du Connectors baust: Claudes Dokumentation zur Connector-Authentifizierung listet weiterhin die Autorisierungsspezifikationen 2025-03-26, 2025-06-18 und 2025-11-25 und sagt, Claude unterstütze noch keine Resource Subscriptions, kein Sampling und keine „fortgeschrittenen oder Entwurfs-Capabilities“. „Unterstützt die neueste Spec“ stimmt für den Kern. Es ist kein Versprechen, dass jeder Teil der neuesten Spec in Claude funktioniert.

Was sind MCP Apps?

Ein Weg für einen MCP-Server, einem Tool eine interaktive Oberfläche mitzugeben, neben dem Textergebnis, das Clients ohne UI-Unterstützung weiterhin bekommen. Es ist eine offizielle Extension, io.modelcontextprotocol/ui, stabil seit Januar 2026. Die Beschreibung eines Tools trägt ein _meta.ui.resourceUri, das auf eine ui://-Ressource zeigt, eine HTML-Seite mit ihren Skripten und Styles. Der Host holt sie ab, rendert sie (Web-Hosts typischerweise in einem sandboxed iframe, Claude mobil in einer nativen WebView) und spricht über postMessage mit ihr. Aus der Spezifikation:

The sandbox prevents your app from accessing the parent window's DOM, reading the host's
cookies or local storage, navigating the parent page, or executing scripts in the parent
context.

Die App kann zusätzliche Berechtigungen anfordern und deklarieren, von welchen externen Origins sie laden darf, und der Host entscheidet, was er zulässt. In Claude wird der Nutzer vorher gefragt: Allow, oder Always allow für einen Server, dem er vertraut.

Claude im Web, Claude Desktop und Claude mobil rendern MCP Apps. Laut der Client-Matrix des MCP-Projekts tun das auch VS Code mit GitHub Copilot, Microsoft 365 Copilot, Goose, Postman und einige andere. Ich habe kein Claude-Dokument gefunden, das sagt, ob Cowork oder Claude Code sie rendern. Wenn der Wert deines Plugins also in seiner Oberfläche liegt, teste es auf den Oberflächen, die deine Nutzer tatsächlich verwenden.

Was ist Enterprise Managed Auth?

Single Sign-on für MCP-Server, damit Mitarbeiter sich nicht für jeden Connector durch einen OAuth-Zustimmungsdialog klicken. Die Spezifikation nennt es Enterprise-Managed Authorization. Wenn sich ein Nutzer über den Identity Provider der Firma bei Claude anmeldet, holt sich der Client von diesem Provider eine signierte Identitätsassertion, ein ID-JAG. Die tauscht er dann am Token-Endpoint deines Servers gegen ein Access-Token, über den standardisierten JWT-Bearer-Grant aus RFC 7523. Kein Browser-Redirect, keine Zustimmungsseite, und der Identity Provider der Firma entscheidet, wer Zugriff bekommt.

Es hat Grenzen. In Claude ist es nur in den Plänen Team und Enterprise verfügbar, allgemein verfügbar seit dem 24. August 2026. Okta ist zum Start der einzige Identity Provider. Es lässt sich nicht mit Dynamic Client Registration kombinieren. Und es passiert nicht automatisch für jede Firma mit SSO: Ein Administrator muss es konfigurieren, und dein Autorisierungsserver muss dem Identity Provider des Kunden vertrauen und den JWT-Bearer-Grant ausweisen. Wenn deine Nutzer Einzelpersonen sind und keine Firmen, ist diese Extension für dich irrelevant.

Bedient ein Repository jeden Agenten?

Die Skills ja. Die Verpackung nur mit etwas Arbeit.

Die Skills wandern mit. Agent Skills ist ein offenes Format, und SKILL.md-Ordner laden in OpenAI Codex und ChatGPT, GitHub Copilot, Cursor, Gemini CLI und Dutzenden anderen Clients. GitHub Copilot und Cursor lesen sogar .claude/skills. Schreib einen guten Skill einmal, und der Großteil der Branche kann ihn nutzen.

Das Bundle nicht. Am 6. August 2026 haben AWS, Cursor, Microsoft, OpenAI und Vercel Agent Plugins 1.0.0 veröffentlicht, einen herstellerneutralen Plugin-Standard. Anthropic fehlt in seinem veröffentlichten Steering Committee. Sein Manifest ist eine plugin.json im Plugin-Root und seine MCP-Datei heißt mcp.json, während Claudes .claude-plugin/plugin.json und .mcp.json heißen. Claudes Dokumentation erwähnt das Agent-Plugins-Layout nicht. OpenAIs Dokumentation kommt Claude ein Stück entgegen: Die ChatGPT-Desktop-App liest eine .claude-plugin/marketplace.json im Claude-Stil, und Codex lädt Plugin-Hooks über seine eigene Extension. Aber seine Plugin-Dokumentation warnt auch davor, die MCP-Datei einfach umzubenennen, weil das portable Format für jeden Server einen Transport-type deklariert.

Die praktische Antwort lautet also: Ein Repository kann Claude und die Agent-Plugins-Clients bedienen, wenn es beide Manifeste mitbringt, und beide MCP-Dateien, falls es Server ausliefert. Beide Formate legen Skills unter skills/<name>/SKILL.md ab, die Skills selbst werden also geteilt. Hooks liegen außerhalb des portablen Kerns und bleiben clientspezifisch. Die Branche hat sich darauf geeinigt, was ins Repo gehört. Auf die Verpackung hat sie sich nicht geeinigt.

Was passierte, als ich meine eigenen zwei Server verpacken wollte?

Keiner ist unverändert einreichbar. Die Gründe sagen mehr über das Verzeichnis als über meinen Code.

clipboard-mcp ist ein Rust-Server, der die Zwischenablage liest und schreibt. Als Connector funktioniert er in seiner jetzigen Form nicht. Ein Remote-Connector läuft auf Infrastruktur, die ich hoste, und Claude erreicht ihn aus Anthropics Adressbereich, ein gehosteter Clipboard-Server würde also die Zwischenablage meines Servers freigeben, nicht die des Nutzers. Sein vorhandener HTTP-Modus ändert daran nichts: Er bindet an localhost und hat keine Authentifizierung. Die Zwischenablage des Nutzers in einen Connector zu bekommen, würde etwas Neues erfordern, einen Agenten auf dem Rechner des Nutzers und ein abgesichertes Relay dorthin. Die allgemeine Regel: Ein Tool, dessen Wert im Zugriff auf den eigenen Rechner des Nutzers liegt, braucht mehr als eine URL, um ein Connector zu werden.

Als Bundle läuft er in die Regeln für Binaries. Mein lokaler Release-Build ist etwa 7.9 MB groß, das übersteigt die Grenze von 5 MiB pro Datei, ihn zu committen stoppt also die Validierung. Ein kompiliertes Executable unter der Grenze würde trotzdem für einen Reviewer zurückgehalten. Liegt es in einem bin/ auf oberster Ebene, lehnen claude.ai und Cowork das Plugin ab. .mcp.json auf ein herunterladbares Bundle zeigen zu lassen wird blockiert, und eigenständige Desktop-Extension-Listings gibt es nicht mehr; eine im Plugin committete .mcpb wird zurückgehalten, und bei dieser Größe stoppt sie ohnehin zuerst die Dateigrenze. Eine weitere Option ist, ein separat installiertes Binary vorauszusetzen. Das wird zurückgehalten, weil der Befehl keine Datei im Plugin ist, und es beendet die Installation per Klick. Jede dieser Varianten würde nur in Claude Code und im lokalen Cowork funktionieren, weil der Chat lokale Server ignoriert.

agent-recall ist ein Python-Memory-Server über einer lokalen SQLite-Datei. Als Connector bräuchte er einen Remote-Transport und ein Konzept für Zugriffskontrolle, die er nicht hat; er ist heute nur stdio und mit Absicht local-first. Als Bundle ist er plausibel, aber nicht sauber. Sein Server und seine Hooks setzen ein vorheriges pip install voraus, und die Checkliste will jede Datei, die ein Hook oder Server nutzt, im Plugin-Ordner haben. Ein gepinnter uvx-Launcher erfüllt die Pinning-Regel und wird trotzdem für das Review zurückgehalten, weil seine Abhängigkeiten zur Installationszeit aufgelöst werden. Und die Verpackung ist nur die halbe Sache: Ein Memory-Server, der proaktiv Dinge speichert, muss das mit den Grenzen der Verzeichnis-Policy beim Sammeln von Gesprächsdaten vereinbaren, und das kann ein Repository-Audit wie dieses nicht klären.

Es hat mir auch den Fallstrick gezeigt, den ich in jeder Checkliste an die erste Stelle setzen würde. Kommt ein MCP-Server aus einem Plugin, versieht Claude Code seine Tools mit dem Namespace mcp__plugin_<plugin-name>_<server-name>__<tool-name>. Die Dokumentation sagt es direkt:

A hook matcher written against the bare server key, such as `mcp__database-tools__.*`, never
fires for a plugin-bundled server.

Mein eigenes Plugin ist der Sonderfall. Es liefert Hooks, aber keinen Server: Seine .mcp.json ist leer, und die README lässt Leute den Server selbst unter dem Key memory hinzufügen, heute ist der nackte Matcher also richtig. Sobald ich den Server ins Plugin packe, feuert dieser Matcher nicht mehr, ohne Fehlermeldung, und der Handler dahinter ebenso wenig, weil er ebenfalls auf die nackten Tool-Namen filtert. Niemand würde es merken, bis Erinnerungen still nicht mehr geschrieben werden. Wenn du Hooks hast, die auf MCP-Tool-Namen hören, und den Server in ein Plugin verschiebst, schreib die Matcher um und jeden Code, der die Namen prüft.

Das Muster bei beiden: Das Verzeichnis ist für Remote-Server mit echter Authentifizierung gebaut, plus Skills, die Claude beibringen, sie zu nutzen. Lokale Tools erreichen Claude Code und das lokale Cowork, und die Regeln, die Nutzer schützen (lesbarer Quellcode, nichts, was zur Installationszeit hinter dem Rücken des Reviewers aufgelöst wird, jede Datei im Ordner), sind genau die Regeln, die lokale Tools zu einem menschlichen Reviewer schicken.

Wer sollte es nutzen, und wie?

Wenn du einen Remote-Dienst mit ordentlichem OAuth-Setup betreibst, ist die Empfehlung der Dokumentation selbst die richtige: zweimal einreichen. Den Server als MCP-Connector, dann ein Plugin-Bundle, dessen Skills Claude beibringen, ihn zu nutzen, wobei die .mcp.json des Bundles auf dieselbe URL zeigt, damit Leute, die beides haben, nur einen Satz Tools sehen. Du bekommst ein Listing, ein Review, die Chance, dass Anthropic dich zu Verified hochstuft, Analytics und, bei Team und Enterprise, Admins, die dein Plugin zum Standard machen können.

Ist dein Tool lokal, liefere es über ein Plugin an Claude-Code-Nutzer aus, halte alles im Plugin-Ordner in lesbarem Quellcode und akzeptiere, dass Chat-Nutzer nur deine Skills bekommen.

Wenn du gehofft hast, ein Plugin zu verkaufen, wird das Verzeichnis das nicht für dich erledigen. Es gibt keine Preise, keine Umsatzbeteiligung und keine Auszahlung, weder im Launch-Post noch in der Verzeichnisdokumentation, den Directory Terms oder der Directory Policy, und die Policy geht weiter: Software, die Geld bewegt oder Finanztransaktionen ausführt, ist ein nicht unterstützter Anwendungsfall, ebenso Software, die Werbung oder gesponserte Inhalte ausspielt. Ein Geschäftsmodell sitzt hinter deinem eigenen Server und deinen eigenen Accounts, so wie vorher. Wenn du ein ganzes Produkt an Firmen verkaufst, ist die separate bezahlte Bewerbung bei Marketplace die Tür, die du dir ansehen solltest.

Was ist es also?

Für Plugins ein Verzeichnis, kein Marktplatz: Vertrieb und Review, verkauft wird woanders. Das Claude-Code-Plugin-Format zum Verzeichnisformat zu machen war die kluge Entscheidung. Wenn du schon ein Claude-Code-Plugin gebaut hast, bist du größtenteils am Ziel.

Das Review liest, was du hochlädst, und ein Connector-Review testet den Server, wie er an diesem Tag war. Was der Server danach tut und was das nächste stille Update tut, bleibt zwischen Entwickler und Nutzer. Lies das Listing-Badge entsprechend. Und wenn du veröffentlichst, schreib die README, als wäre sie der Vertrag, denn für den Scan ist sie das, und vergiss dabei nicht die Warnung der Checkliste selbst, dass ein beschriebenes Verhalten dadurch noch nicht erlaubt ist. Für meine zwei Server ist der nächste Schritt keine Einreichung. Er heißt: die Verpackung reparieren und dann die Policy-Frage ehrlich beantworten.