MCP und Plugins

Claude Code bringt eigene Werkzeuge mit: Dateien lesen und schreiben, suchen, Befehle ausführen, Seiten im Netz abrufen. Welche das sind und in welcher Reihenfolge Claude sie wählt, steht in Kapitel 04. Für alles, was außerhalb des Rechners liegt, etwa ein Ticketsystem, eine Datenbank oder ein Dienst für Fehlermeldungen, braucht es eine Verbindung nach draußen. Dafür gibt es MCP, das Model Context Protocol.

Dieses Kapitel hat zwei Teile. Der erste zeigt, wie Claude Code einen MCP-Server einbindet, für wen er gilt und wie die Anmeldung läuft. Der zweite handelt von Plugins: Pakete, die Skills, Subagents, Hooks und MCP-Server bündeln und sich mit einem Befehl installieren lassen. Was MCP als Protokoll festlegt und was es offen lässt, erklärt Agenten und Harness, Kapitel 02 im Pfad zu Agenten.

Wann sich ein Server lohnt

Die Doku nennt ein einfaches Zeichen. Wer Daten aus einem anderen Werkzeug immer wieder ins Gespräch kopiert, sollte dieses Werkzeug als Server anbinden (MCP-Doku (externe Seite, code.claude.com)). Danach liest Claude das System selbst und handelt darin. Das Kopieren von Hand entfällt.

Ein Server bringt Werkzeuge und Zugriff auf Daten. Wie man diese Werkzeuge gut benutzt, gehört in einen Skill. Die Übersicht der Erweiterungen (externe Seite, code.claude.com) trennt die beiden genau so. MCP verbindet Claude mit äußeren Diensten. Skills erweitern, was Claude weiß, auch über den Umgang mit diesen Diensten. Ein typisches Paar ist ein Server für die Datenbank und ein Skill, der das Schema und die üblichen Abfragen des Teams beschreibt. Wie Skills arbeiten, erklärt Kapitel 17. Wann ein Hook, ein Mod, ein Skill oder ein MCP-Server passt, zeigt Kapitel 18.

Einen Server einbinden

claude mcp gehörte zum ersten Funktionsumfang. Schon die Doku vom Februar 2025 führte den Befehl, um MCP-Server einzurichten (Archivfassung (externe Seite, docs.anthropic.com)). Eingebunden wird ein Server im Terminal, außerhalb einer Sitzung. Der Befehl braucht einen Namen, den man frei wählt, und die Angabe, wie Claude Code den Server erreicht:

claude mcp add \
  --transport http \
  notion \
  https://mcp.notion.com/mcp

Die Doku nennt vier Arten der Verbindung. Ein Server im Netz wird über HTTP angesprochen, und das ist der empfohlene Weg für entfernte Server (MCP-Doku (externe Seite, code.claude.com)). Ein lokaler Server ist ein Programm, das Claude Code auf dem eigenen Rechner startet und über Standardein- und -ausgabe anspricht (stdio). Das ältere Verfahren SSE gilt als veraltet. Dazu kommt WebSocket für Server, die von sich aus Ereignisse schicken. Die Einzelheiten stehen auf der zweiten Ebene.

Ob die Verbindung steht, zeigt claude mcp list mit einem Zustand je Server, etwa verbunden oder wartet auf Anmeldung (MCP-Doku (externe Seite, code.claude.com)). In einer laufenden Sitzung zeigt und verwaltet /mcp dieselben Server. Je nach Modus fragt Claude Code beim ersten Aufruf eines neuen Werkzeugs um Erlaubnis, wie bei jedem anderen Werkzeug (Schnellstart (externe Seite, code.claude.com)). Wer die Frage dauerhaft beantworten will, schreibt eine Regel; wie das geht, steht in Kapitel 16.

Wo ein Server gilt

Jeder Server liegt in einem von drei Bereichen. Der Bereich entscheidet, in welchen Projekten der Server lädt und ob das Team ihn mitbekommt.

Ohne Angabe landet ein Server im Bereich local (MCP-Doku (externe Seite, code.claude.com)). Das passt für Zugangsdaten, die nicht ins Repository gehören. Mit --scope project schreibt Claude Code den Server in die Datei .mcp.json im Projektordner. Die Doku rät, sie einzuchecken, damit das ganze Team dieselben Werkzeuge hat. Diese Aufteilung gibt es seit Version 0.2.50 vom März 2025 (Versionsliste (externe Seite, code.claude.com)).

Ein Server aus einer fremden .mcp.json startet ein Programm oder schickt Daten an eine Adresse, die jemand anderes eingetragen hat. Deshalb fragt Claude Code in einer interaktiven Sitzung nach, bevor es einen solchen Server benutzt. In einem Lauf mit -p ohne Terminal und in Cloud-Sitzungen fällt diese Frage weg, und die Server laden ungefragt. Was das für Automaten heißt, steht in Kapitel 29.

Server im Netz mit Anmeldung

Ein lokaler Server muss installiert und gepflegt werden. Ein Server im Netz gehört dem Anbieter des Dienstes. Seit Version 1.0.27 vom 18.06.2025 meldet sich Claude Code bei solchen Servern über OAuth an (Versionsliste (externe Seite, code.claude.com)). Dabei meldet man sich einmal im Browser beim Dienst an, und Claude Code bekommt einen Zugangsschlüssel. Die Ankündigung (externe Seite, claude.com) nannte als Vorteil, dass der Anbieter sich um Aktualisierung, Skalierung und Erreichbarkeit kümmert. Dieselbe Eigenschaft hat eine Kehrseite: Ein solcher Server ändert sich, ohne dass man es mitbekommt. Die Abwägung zwischen beiden Bauformen steht in Agenten und Harness, Kapitel 02 auf der zweiten Ebene.

Angemeldet wird in der Sitzung über /mcp, die Seite des Dienstes öffnet sich im Browser. Seit Version 2.1.186 vom 22.06.2026 geht das auch außerhalb einer Sitzung, mit claude mcp login <name>. Claude Code speichert die Zugangsschlüssel und erneuert sie selbst.

Connectors aus dem Konto

Wer Claude auch im Browser oder in der App benutzt, hat dort vielleicht schon Dienste verbunden. Diese Connectors sind MCP-Server, und seit Version 2.1.46 vom 18.02.2026 stehen sie auch in Claude Code bereit (Versionsliste (externe Seite, code.claude.com)). Eine zweite Einrichtung im Terminal entfällt. In /mcp erscheinen sie mit einem Hinweis auf ihre Herkunft (MCP-Doku (externe Seite, code.claude.com)).

Dafür gelten zwei Bedingungen. Claude Code holt die Connectors nur, wenn man mit einem Abo von claude.ai angemeldet ist. Wer über einen API-Schlüssel, Amazon Bedrock oder Google Cloud arbeitet, sieht sie also nicht. In den Tarifen Team und Enterprise dürfen außerdem nur Admins neue Connectors anlegen.

Plugins als Paket

Ein einzelner Server, ein Skill oder ein Hook funktioniert auch ohne Plugin. Ein Plugin wird nützlich, sobald mehrere davon zusammengehören und an andere Leute oder in andere Projekte sollen. Die Doku beschreibt es als Ordner mit Skills, Subagents, Hooks, MCP-Servern oder anderen Bestandteilen, den Claude Code als eine Einheit installiert und lädt (Plugin-Übersicht (externe Seite, code.claude.com)). Meist gibt ein Manifest in .claude-plugin/plugin.json dem Plugin seinen Namen.

Anthropic hat Plugins mit Version 2.0.12 am 09.10.2025 eingeführt (Versionsliste (externe Seite, code.claude.com)), laut Ankündigung (externe Seite, anthropic.com) als öffentliche Beta für alle Nutzer von Claude Code. Seither ist das Format stark gewachsen. Ein Plugin kann heute auch Language Server für die Navigation im Code, Beobachter im Hintergrund und eigene Programme mitbringen. Was die Language Server leisten, erklärt Kapitel 04, die Beobachter Kapitel 28. Hooks als Funktionen in JavaScript oder TypeScript, die auch Bereiche der Oberfläche zeichnen und Befehle anlegen, machen ein Plugin zum Mod (Doku zu Mods (externe Seite, code.claude.com)). Was ein Mod kann und was er darf, erklärt Kapitel 18.

Vor den Skills und Befehlen eines Plugins steht sein Name als Vorsilbe, etwa /commit-commands:commit. So kommen sich zwei Plugins mit gleich benannten Skills nicht in die Quere (Übersicht der Erweiterungen (externe Seite, code.claude.com)).

Woher Plugins kommen

Die meisten Plugins stammen aus einem Marktplatz. Ein Marktplatz ist ein Repository mit einer Datei .claude-plugin/marketplace.json, die Plugins auflistet und sagt, wo jedes zu holen ist (Plugin-Übersicht (externe Seite, code.claude.com)). Der Marktplatz ist also ein Katalog. Die Plugins selbst liegen in seinem Ordner oder anderswo, in Repositories, Archiven oder Paketen. Den offiziellen Marktplatz von Anthropic fügt Claude Code beim ersten Start einer interaktiven Sitzung im Terminal selbst hinzu, sofern die Organisation das nicht sperrt.

Der Name täuscht leicht über den Inhalt. Laut der Seite zu den Marktplätzen von Anthropic (externe Seite, code.claude.com) stammt das meiste im offiziellen Marktplatz von Partnern und anderen Autoren. Am 12.10.2026 führte der Katalog (externe Seite, raw.githubusercontent.com) 315 Plugins, davon 39 mit Anthropic als Autor. Marktplätze anderer Anbieter prüft Anthropic nicht.

Installiert wird in der Sitzung mit /plugin. Der Befehl öffnet eine Übersicht zum Stöbern; mit Name und Marktplatz öffnet er die Detailansicht eines Plugins:

/plugin install commit-commands@claude-plugins-official

Die Detailansicht zeigt, was das Plugin mitbringt, bevor etwas installiert ist. Danach wählt man einen von drei Bereichen, ähnlich wie bei MCP-Servern (Doku zum Installieren (externe Seite, code.claude.com)). Das Plugin gilt dann für einen selbst in allen Projekten, für alle in diesem Repository oder nur für einen selbst in diesem Repository. Der Bereich für das Team schaltet das Plugin über die eingecheckte .claude/settings.json ein. Herunterladen muss es trotzdem jeder auf dem eigenen Rechner. Eine Cloud-Sitzung lädt die Plugins aus den lokalen Einstellungen nicht.

Was ein Plugin darf und kostet

Ein eingeschaltetes Plugin gehört zu jeder Sitzung, auch zu denen, in denen man es nie benutzt (Plugin-Übersicht (externe Seite, code.claude.com)). Das hat zwei Folgen.

Die erste betrifft den Kontext. Name und Beschreibung jedes Skills und jedes Subagents, den Claude selbst aufrufen kann, stehen in jeder Runde im Fenster. Diese Token zählen zum Verbrauch, auch wenn aus dem Plugin nichts läuft. Seine MCP-Server laufen neben jeder Sitzung mit, und seine Hooks feuern bei jedem passenden Ereignis. Was ein Posten im Fenster kostet, erklärt Kapitel 05.

Die zweite betrifft die Rechte. Ein Plugin kann beliebigen Code auf dem eigenen Rechner ausführen, mit den Rechten des Nutzers (Doku zur Sicherheit von Plugins (externe Seite, code.claude.com)). Der Name des Marktplatzes nennt nur den Herausgeber des Katalogs. Die einzelnen Plugins darin prüft man deshalb selbst, aus welchem Marktplatz sie auch kommen. Vor der Installation lohnt deshalb ein Blick in die Detailansicht und in die Dateien des Plugins. Worauf man dabei achtet, steht auf der dritten Ebene.

Wann sich was lohnt

Die Doku zur Übersicht der Erweiterungen ordnet jede Erweiterung einem Anlass zu. Für dieses Kapitel heißt das:

• Daten aus einem Dienst landen immer wieder per Kopieren im Gespräch: einen MCP-Server einbinden, für sich allein im Bereich local.
• Das ganze Team braucht denselben Dienst: den Server in die .mcp.json schreiben und einchecken.
• Der Dienst ist schon in claude.ai verbunden: die Connectors nutzen, sofern man mit dem Abo angemeldet ist.
• Ein zweites Repository braucht dieselbe Einrichtung: sie als Plugin verpacken.
• Ein Team oder eine Organisation will ihre Plugins verteilen: einen eigenen Marktplatz anlegen und ihn über die Einstellungen vorgeben.

Jeder dieser Schritte bringt Werkzeuge ins Fenster und Code auf den Rechner, den man nicht selbst geschrieben hat. Server und Plugins, die man nicht mehr braucht, schaltet man deshalb ab. Die zweite Ebene zeigt die Befehle und die Grenzen für Beschreibungen und Ergebnisse. Sie erklärt den Bau eines eigenen Plugins und Marktplatzes und die Schalter, mit denen eine Organisation festlegt, was erlaubt ist.

Die erste Ebene hat gezeigt, wie ein Server dazukommt und was ein Plugin bündelt. Diese Ebene geht die Einzelheiten durch: Befehle und Dateien, die Grenzen für Beschreibungen, Ergebnisse und Laufzeiten, den Bau eines eigenen Plugins und Marktplatzes. Am Ende steht, was eine Organisation vorgeben kann. Wie die verwalteten Einstellungen auf die Rechner kommen, erklärt Kapitel 15.

Vier Wege zum Server

Die MCP-Doku (externe Seite, code.claude.com) unterscheidet vier Arten der Verbindung. Jede hat ihre eigene Schreibweise.

Bei einem lokalen Server trennt der doppelte Bindestrich die Optionen von Claude Code vom Befehl, der den Server startet. Alles danach geht unverändert an den Server. Ein Beispiel aus der Doku startet einen Server für Airtable mit einem Schlüssel in der Umgebung:

claude mcp add \
  --env \
  AIRTABLE_API_KEY=YOUR_KEY \
  --transport stdio \
  airtable \
  -- npx -y \
  airtable-mcp-server

Ein Server, der nur noch SSE spricht, wird seit Version 2.1.265 wie ein HTTP-Server eingetragen. Claude Code versucht zuerst HTTP und wechselt zu SSE, wenn der Server das ablehnt. WebSocket hält eine Verbindung in beide Richtungen offen, kennt aber weder OAuth noch den Schalter --transport. Für einen Server, der nur auf Anfragen antwortet, rät die Doku deshalb zu HTTP.

Viele Server beschreiben ihre Einrichtung für ein anderes Programm, etwa Claude Desktop oder Cursor. Die Doku übersetzt die drei üblichen Formen:

• Eine Adresse heißt Server im Netz.
• Ein Startbefehl wie npx -y … heißt lokaler Server.
• Ein Block mcpServers in JSON geht mit claude mcp add-json hinein.

Eine Falle steht dabei ausdrücklich in der Doku. Ein Eintrag mit Adresse und ohne type gilt als Fehler, denn ohne Typ liest Claude Code ihn als lokalen Server. Wer in Claude Desktop schon Server eingerichtet hat, holt sie mit claude mcp add-from-claude-desktop, das geht unter macOS und im Linux-Subsystem von Windows.

Für einen einzelnen Lauf gibt es claude --mcp-config <datei>. Damit lädt ein Server nur für diese Sitzung, ohne dass er irgendwo eingetragen wird. Mit --strict-mcp-config lädt Claude Code ausschließlich diese Server.

Steht derselbe Server an mehreren Stellen, verbindet Claude Code ihn einmal, mit der Fassung der höchsten Stufe, und vermischt keine Felder. Die Reihenfolge lautet local vor project vor user, danach kommen Server aus Plugins und zuletzt die Connectors aus claude.ai. Seit Version 2.1.259 stehen Server, die eine Organisation bereitstellt, über allen. In einer .mcp.json dürfen Umge­bungs­va­ria­blen stehen, als ${VAR} oder mit Vorgabe als ${VAR:-wert}. So teilt ein Team eine Datei, und jeder setzt seine eigenen Schlüssel.

Wann ein Projektserver startet

Ein Server aus der .mcp.json eines Projekts startet in einer interaktiven Sitzung erst nach einer Freigabe. Bis dahin führt ihn claude mcp list als wartend. Eine Freigabe, die im Repository selbst steht, zählt dabei erst, wenn man dem Ordner vertraut. Ein geklontes Repository kann seine Server also nicht selbst freigeben (MCP-Doku (externe Seite, code.claude.com)). Freigaben aus den eigenen Benut­zer­ein­stel­lungen und aus verwalteten Einstellungen gelten auch vorher. Mit claude mcp reset-project-choices setzt man die eigenen Antworten zurück.

In einem Lauf mit -p, im Agent SDK und in Cloud-Sitzungen gibt es keine Rückfrage, und die Projektserver laden ungefragt. Wer einen Server dort fernhalten will, hat drei Wege:

• ihn in disabledMcpjsonServers eintragen, was in jedem Modus der Rechte sperrt,
• die Pro­jekt­ein­stel­lungen mit --setting-sources ausschließen,
• mit --strict-mcp-config nur die eigenen Server zulassen.

Wie Vertrauen in einen Ordner sonst wirkt, steht in Vibe-Coding / Agentic Engineering, Kapitel 08 auf der dritten Ebene.

Ein Server lässt sich auch abschalten, ohne ihn zu löschen. Der Schalter in /mcp merkt sich die Wahl je Projekt in ~/.claude.json. Der Server bleibt in der Liste, als ausgeschaltet markiert.

Anmeldung und Zugangsdaten

Bei einem Server mit OAuth reicht in der Regel /mcp und die Anmeldung im Browser. Manche Server erlauben aber nicht, dass sich ein Programm selbst registriert. Für sie gibt es seit Version 2.1.30 vom 03.02.2026 eigene Zugangsdaten (Versionsliste (externe Seite, code.claude.com)). Man legt beim Dienst eine App an und gibt deren Kennung mit --client-id und --client-secret an. Das Geheimnis speichert Claude Code im Schlüsselbund von macOS oder in einer eigenen Datei für Zugangsdaten, getrennt von der Konfiguration.

Bietet ein Dienst mehr Rechte an, als man vergeben will, legt oauth.scopes die angefragten Rechte fest. Die Doku nennt das den vorgesehenen Weg, einen Server auf eine Auswahl zu beschränken, die das Sicherheitsteam freigegeben hat.

Für andere Verfahren als OAuth, etwa Kerberos oder kurzlebige Schlüssel aus einem eigenen Anmeldedienst, gibt es seit Version 1.0.119 den headersHelper. Das ist ein Befehl, den Claude Code bei jeder Verbindung ausführt und dessen Ausgabe als Header mitgeht. Er läuft in einer Shell und hat dafür zehn Sekunden. Steht ein solcher Befehl in der .mcp.json eines Projekts, läuft er seit Version 2.1.238 erst, wenn man dem Ordner vertraut. Kommt er aus einem Projekt oder einem Plugin, bekommt er die Zugangsdaten aus der eigenen Umgebung nicht.

Dieselbe Vorsicht gilt für Variablen in Adresse und Headern eines Servers im Netz. Variablen mit Zugangsdaten wie ANTHROPIC_API_KEY setzt Claude Code dort als leer ein. So kann eine .mcp.json oder ein Plugin die eigenen Schlüssel nicht an einen Server schicken, den es selbst benennt. Einige von Anthropic betriebene Connectors, etwa Microsoft 365, Gmail und Google Calendar, lassen sich gar nicht lokal anmelden. Sie verbindet man in claude.ai, danach erscheinen sie in Claude Code von selbst.

Was ein Server ins Fenster bringt

In der Voreinstellung lädt Claude Code beim Start nur die Namen der Werkzeuge und die Anweisungen der Server. Weitere Server belasten das Kontextfenster deshalb kaum (MCP-Doku (externe Seite, code.claude.com)). Die vollständige Beschreibung holt Claude über die Werkzeugsuche, wenn eine Aufgabe sie braucht. Wie diese Suche den Platz im Fenster schont, steht in Kapitel 05; warum ohne sie jede Anfrage alle Beschreibungen mitschickt, in Agenten und Harness, Kapitel 02. Seit Version 2.1.304 vom 19.10.2026 ist die Suche auch hinter einem eigenen Gateway mit ANTHROPIC_BASE_URL an. Das Gateway muss dafür die nötigen Blöcke weiterreichen. Wer sie mit ENABLE_TOOL_SEARCH=false abschaltet, hat wieder alle Beschreibungen vorab im Fenster.

Beschreibungen und Anweisungen schneidet Claude Code ab einer bestimmten Länge ab. Seit Version 2.1.296 vom 09.10.2026 liegt die Grenze für vorab gesendete Beschreibungen und für die Anweisungen der Server in der Voreinstellung bei 4.096 Zeichen (Versionsliste (externe Seite, code.claude.com)). Eine Beschreibung, die erst über die Werkzeugsuche kommt, darf seit Version 2.1.295 bis zu 16.384 Zeichen lang sein. Die Doku nennt am 15.10.2026 dieselben Zahlen; wie die Grenze gewachsen ist, steht auf der dritten Ebene. Wer einen Server baut, hält Beschreibungen und Anweisungen kurz und schreibt das Wichtigste an den Anfang.

Mit alwaysLoad in der Konfiguration eines Servers stehen seine Werkzeuge immer im Fenster, ohne Suche. Das lohnt nur für wenige Werkzeuge, die Claude in jeder Runde braucht, denn jedes davon belegt Platz für das Gespräch. Wie viele Token jedes geladene Werkzeug belegt, zeigt /context all (Übersicht der Erweiterungen (externe Seite, code.claude.com)).

Auch die Ergebnisse haben Grenzen. Ab 10.000 Token warnt Claude Code, und in der Voreinstellung lässt es höchstens 25.000 Token durch. Die Grenze verschiebt MAX_MCP_OUTPUT_TOKENS. Ein Textergebnis über 50.000 Zeichen speichert Claude Code in eine Datei und gibt Claude den Pfad. Claude liest die Datei, wenn es den Inhalt braucht. Ein Server kann diese Schwelle seit Version 2.1.91 für einzelne Werkzeuge anheben, bis höchstens 500.000 Zeichen, etwa für ein ganzes Datenbankschema.

Lange Aufrufe und Rückfragen

Ein Aufruf, der hängt, soll die Sitzung nicht blockieren. Schickt ein Server weder Antwort noch Fort­schritts­mel­dung, bricht Claude Code den Aufruf nach einer Ruhezeit ab. Sie beträgt fünf Minuten bei Servern im Netz und 30 Minuten bei lokalen Servern. Läuft ein Aufruf im Hauptgespräch länger als zwei Minuten, wandert er seit Version 2.1.212 in den Hintergrund, und Claude arbeitet weiter. Das Ergebnis kommt später als Meldung. Aufrufe von Subagents und Läufe mit -p bleiben im Vordergrund.

Ein Server kann auch zurückfragen. Seit Version 2.1.76 vom 14.03.2026 bittet er über eine Elicitation mitten in der Aufgabe um Angaben. Das geschieht als Formular im Terminal oder als Link, der im Browser aufgeht. Wer einen Server baut, kann ein Werkzeug außerdem so markieren, dass jeder Aufruf eine Rückfrage auslöst, auch im Auto-Modus und bei übergangenen Rechten. Die Doku nennt dafür Werkzeuge, deren Rückfrage selbst der Zweck ist, etwa eine Zustimmung oder eine Freigabe von Zugriff.

Claude Code kann umgekehrt selbst ein Server sein. claude mcp serve stellt seine Werkzeuge anderen Programmen bereit, etwa Claude Desktop. Rückfragen vor einzelnen Aufrufen muss dann das andere Programm übernehmen.

Connectors begrenzen

Wie Connectors aus claude.ai in eine Sitzung kommen, hängt am Ort der Sitzung. Im Terminal, in VS Code, in JetBrains und im Agent SDK holt Claude Code sie selbst. In einer Cloud-Sitzung reicht die Cloud sie herein, und in den lokalen Sitzungen der Desktop-App liefert die App sie direkt (MCP-Doku (externe Seite, code.claude.com)). Die beiden Schalter zum Abschalten wirken nur auf den ersten Fall.

Ganz abschalten lassen sie sich mit disableClaudeAiConnectors in den Einstellungen oder mit ENABLE_CLAUDEAI_MCP_SERVERS=false für eine Shell. Steht der Schalter in irgendeiner Einstellungsdatei auf an, gilt er. Ein Repository kann sich so abmelden. Zurückholen kann es die Connectors nicht, wenn Nutzer oder Organisation sie abgeschaltet haben. Einzelne Connectors sperrt deniedMcpServers mit dem angezeigten Namen, etwa claude.ai Slack.

Eine Organisation kann außerdem einzelne Werkzeuge eines Connectors auf Rückfrage oder gesperrt stellen. Ein gesperrtes Werkzeug filtert Claude Code heraus, bevor Claude es sieht. Eines auf Rückfrage löst bei jedem Aufruf eine Frage aus, auch im Auto-Modus. Einige Connectors stellt Anthropic selbst bereit, ohne dass jemand sie anlegt. Auch sie erscheinen in /mcp und lassen sich dort abschalten.

Plugins verwalten

/plugin öffnet eine Ansicht mit Reitern, darunter Entdecken, Installiert, Marktplätze und Fehler. Für Plugins aus dem offiziellen Marktplatz zeigt die Detailansicht seit Version 2.1.143 zwei Schätzungen der Kosten, sofern man sie über Name und Marktplatz oder über den Reiter Marktplätze öffnet. Die eine nennt den Aufschlag auf jede Nachricht, die andere, was Skills und Subagents des Plugins beim Aufruf hinzufügen (Doku zum Installieren (externe Seite, code.claude.com)). Liegt dieser Aufschlag bei 2.000 Token oder mehr, hebt die Ansicht die Zahl hervor (Doku zu Kosten und Nutzung (externe Seite, code.claude.com)). Plugins aus anderen Marktplätzen zeigen keine solche Schätzung. Für ein schon installiertes Plugin rechnet claude plugin details <name> in der Shell die Zahl aus, seit Version 2.1.139.

Ist dasselbe Plugin in mehreren Bereichen eingetragen, gilt der engste: local vor project vor user. Ein Plugin, das ein Repository einschaltet, lässt sich für sich selbst abschalten, ohne es den anderen zu nehmen. Ohne Sitzung gehen dieselben Schritte mit claude plugin install, enable, disable und uninstall. In einem Lauf mit -p funktioniert /plugin nicht. Schon installierte Plugins laden dort wie gewohnt.

Neue oder geänderte Plugins wirken in einer offenen Sitzung nach /reload-plugins, seit Version 2.1.69. Ändert ein Neuladen die Werkzeuge, wäre der Zwischenspeicher für den Anfang der Anfrage verloren, und Claude Code wartet lieber. Mit --force lädt es trotzdem, und die nächste Anfrage liest das Gespräch ohne Zwischenspeicher neu ein.

Aktualisiert werden Plugins von selbst, wenn ihr Marktplatz das vorsieht. In der Voreinstellung ist das beim offiziellen Marktplatz und bei Marktplätzen aus claude.ai eingeschaltet. Bei allen übrigen ist es aus, auch beim Community-Marktplatz. Die laufende Sitzung behält die Fassung, mit der sie gestartet ist.

Auch die Plugins, die man im Konto bei claude.ai eingeschaltet hat oder die die Organisation dort einschaltet, kommen in jede Sitzung im Terminal, die mit diesem Konto angemeldet ist. Die Versionsliste (externe Seite, code.claude.com) führt das unter Version 2.1.275, die Doku zum Installieren nennt 2.1.273 als Mindestfassung. Sie erscheinen mit der Endung @synced. Die umgekehrte Richtung gibt es nicht: Was man im Terminal installiert, bleibt auf diesem Rechner.

Manche Plugins installiert man und vergisst sie. Bleibt ein selbst installiertes Plugin mindestens 14 Tage und 10 Sitzungen lang ungenutzt, rückt es in /plugin unter die Überschrift für ungenutzte Plugins. Plugins mit Farbschema, Ausgabestil, Beobachter oder Workflow fehlen dort, weil sie ohne erkennbaren Aufruf arbeiten. Auf dieselbe Liste stützt sich der Hinweis im Terminal, der zum Abschalten rät.

Ein eigenes Plugin bauen

Eine Einrichtung, die nur einem Projekt oder nur einem selbst dient, bleibt besser ohne Plugin. Zum Plugin wird sie, wenn sie ans Team gehen, in mehreren Projekten laufen oder in Fassungen erscheinen soll (Doku zum Bauen (externe Seite, code.claude.com)).

Der Aufbau ist fest. In .claude-plugin/ liegt nur das Manifest plugin.json, alles andere liegt eine Ebene darüber im Ordner des Plugins:

mein-plugin/
├── .claude-plugin/plugin.json
├── skills/<name>/SKILL.md
├── agents/<name>.md
├── hooks/hooks.json
└── .mcp.json

Bestandteile, die man versehentlich in .claude-plugin/ legt, lädt Claude Code nicht. Im Manifest ist nur der Name Pflicht. Eine Fassungsnummer hält die Nutzer auf dieser Fassung, bis man sie ändert.

Zum Ausprobieren braucht es keinen Marktplatz. claude --plugin-dir ./mein-plugin lädt das Plugin für eine Sitzung, seit Mai 2026 auch als .zip. Seit Version 2.1.129 holt --plugin-url ein solches Archiv von einer Adresse. claude plugin validate prüft das Manifest und die Kopfdaten aller Skills, Subagents und Befehle, und /reload-plugins übernimmt Änderungen ohne Neustart. claude plugin init legt seit Version 2.1.157 ein Gerüst unter ~/.claude/skills/ an, das in jeder Sitzung lädt.

Wer schon Skills, Subagents und Hooks unter .claude/ hat, kopiert sie in den Ordner des Plugins. Bis man die Originale löscht, laufen beide. Skills und Subagents stören sich dabei nicht, weil die Kopien den Namen des Plugins als Vorsilbe haben. Hooks haben keine Vorsilbe und laufen dann doppelt.

Ob ein Plugin Claude so lenkt wie gedacht, prüft seit Version 2.1.269 claude plugin eval. Es lässt Testfälle mit und ohne das Plugin laufen und bewertet den Unterschied. Jeder Lauf ist ein echter Aufruf des Modells auf eigene Rechnung (Wochenbericht KW 37 (externe Seite, code.claude.com)).

Weitergeben lässt sich ein Plugin auf drei Wegen:

• als Ordner oder .zip direkt an einzelne Leute,
• über einen eigenen Marktplatz,
• über das Verzeichnis von Anthropic.

Ins Verzeichnis kommt es nach einer Prüfung, und von dort erreicht es Claude Code über das Konto bei claude.ai.

Ein eigener Marktplatz

Ein Marktplatz ist ein Ordner oder Repository mit .claude-plugin/marketplace.json. Die Datei braucht einen Namen, einen Besitzer und eine Liste von Plugins. Jeder Eintrag der Liste braucht einen Namen und eine Quelle (Doku zum Marktplatz (externe Seite, code.claude.com)).

{
  "name": "team-werkzeuge",
  "owner": { "name": "Plattform-Team" },
  "plugins": [
    { "name": "formatierer", "source": "./plugins/formatierer" }
  ]
}

Die Quelle eines Plugins kann an sieben Orten liegen:

• in einem Pfad innerhalb des Marktplatzes,
• in einem eigenen Repository auf GitHub,
• in einem Unterordner eines anderen Repositorys,
• in einem Git-Repository bei einem anderen Anbieter,
• in einem Archiv, das über HTTPS kommt,
• in einem npm-Paket,
• in einem Befehl, der den Ordner auf dem Zielrechner erzeugt.

Neue Marktplätze scheitern laut Doku meist an einem von zwei Fehlern. Der eine ist ein relativer Pfad vom falschen Ordner aus. Der andere ist ein Name im Eintrag, der vom Namen im Manifest des Plugins abweicht.

Gehostet wird der Marktplatz in einem Git-Repository. Das Team fügt ihn mit claude plugin marketplace add <owner>/<repo> hinzu und installiert danach nach Namen. Ein privates Repository klont Claude Code mit den Zugangsdaten, die Git auf dem Rechner schon hat, und fragt nie nach einem Passwort.

Für ein einzelnes Repository kann man Marktplatz und Plugins auch in dessen .claude/settings.json vorgeben, mit extraKnownMarketplaces und enabledPlugins. Den Marktplatz fügt Claude Code dann erst hinzu, wenn man dem Ordner vertraut (Doku für Organisationen (externe Seite, code.claude.com)).

Was die Organisation festlegt

Für MCP kennt die Doku zum verwalteten MCP (externe Seite, code.claude.com) mehrere Muster, von gar keinen Servern bis zu gar keinen Regeln:

• MCP aus: Kein Server lädt, bis auf wenige Ausnahmen. Mittel: managed-mcp.json mit leerer Liste.
• feste Auswahl: Alle bekommen genau diese Server, eigene sind gesperrt. Mittel: managed-mcp.json mit den Servern.
• bereitgestellt: Alle bekommen diese Server zusätzlich zu den eigenen. Mittel: managedMcpServers.
• genehmigte Liste: Nur Server von der Liste laden. Mittel: allowedMcpServers mit allowManagedMcpServersOnly.
• nur aus Plugins: Eigene Server in .mcp.json und ~/.claude.json sperren. Mittel: strictPluginOnlyCustomization mit mcp.
• Sperrliste: Bekannte Server sperren, den Rest erlauben. Mittel: deniedMcpServers.

Die Datei managed-mcp.json liegt an einem festen Pfad des Systems und kommt per Geräteverwaltung auf die Rechner. Über die Einstellungen aus der Verwaltung von claude.ai lässt sie sich nicht verteilen. managedMcpServers gibt es seit Version 2.1.259 und nimmt nur Server im Netz mit https://. Ein Eintrag mit Befehl fällt heraus, damit verwaltete Einstellungen nie ein Programm auf dem Rechner starten. Die Sperrliste gilt immer, auch gegen die Server der Organisation, und ein Treffer dort lässt sich durch nichts aufheben.

Die Zulassungsliste allowedMcpServers prüft Server aus managed-mcp.json nur in einem Fall: wenn ihr Befehl, ihre Argumente, ihre Adresse oder ihre Header Umge­bungs­va­ria­blen wie ${VAR} nutzen. Seit Version 2.1.259 lädt deshalb ein eigener Server ohne ${VAR}, den die Liste vorher fernhielt, ohne Hinweis, seit Version 2.1.305 auch einer mit ${VAR} nur im Block env. Abhalten lässt er sich mit einem Eintrag in deniedMcpServers oder mit einer eigenen managed-mcp.json je Gruppe. Zum Eintrag in deniedMcpServers rät auch die Versionsliste (externe Seite, code.claude.com) bei Version 2.1.305 vom 20.10.2026.

Für Plugins setzt eine Organisation zwei Schlüssel zusammen: extraKnownMarketplaces meldet einen Marktplatz auf jedem Rechner an, enabledPlugins schaltet Plugins daraus ein. Ein so eingeschaltetes Plugin lädt auch dann, wenn ein Nutzer es für sich abschaltet. Mit dem Wert false sperrt derselbe Schlüssel ein Plugin in allen Bereichen. Dazu kommen:

• strictKnownMarketplaces: eine Liste erlaubter Quellen für Marktplätze. Eine leere Liste sperrt alle, auch den offiziellen.
• blockedMarketplaces: eine Liste gesperrter Quellen, geprüft vor der erlaubten.
• disableSideloadFlags: sperrt unter anderem --plugin-dir, --plugin-url und das Laden einzelner Server mit --mcp-config.
• pluginTrustMessage: hängt einen eigenen Text an die Warnung vor dem Installieren, seit Version 2.1.69.
• syncClaudeAiPlugins: auf false gesetzt, lädt Claude Code die Plugins aus dem Konto bei claude.ai nicht.

Die übliche Sperre erlaubt den offiziellen Marktplatz und den eigenen und schaltet disableSideloadFlags dazu. Container und CI können zur Laufzeit oft nichts klonen. Für sie legt man die Plugins beim Bauen des Abbilds in einen Ordner und zeigt mit CLAUDE_CODE_PLUGIN_SEED_DIR darauf; mehr dazu in Kapitel 29. Was installiert und geladen wird, melden die Ereignisse von OpenTelemetry. Wo diese Schalter enden, steht auf der dritten Ebene.

Ein Server und ein Plugin bringen Code und Text in die Sitzung, den man nicht selbst geschrieben hat. Diese Ebene zeigt zuerst, wie beides in Claude Code gewachsen ist. Danach geht es um die Frage, wem man dabei vertraut und wo die Schalter einer Organisation enden. Zum Schluss steht Claude Code neben OpenAI: was von einem Plugin dort ankommt und was Codex bei MCP anders löst.

Wie MCP und Plugins dazukamen

Die Tabelle zeigt die Schritte, mit Datum und Fassung aus der Versionsliste (externe Seite, code.claude.com). Die Versionsliste führt die Fassungen 0.2.21 bis 0.2.61 unter dem Sammeldatum 02.04.2025. Für sie steht hier das Datum der Veröffentlichung im npm-Verzeichnis, markiert mit „npm“.

Zwei Wendepunkte stehen darin. MCP war von Anfang an dabei. Schon die Doku vom Februar 2025 zeigte claude mcp add mit einem Language Server als Beispiel (Archivfassung (externe Seite, docs.anthropic.com)). Damit war die Tür nach draußen offen, bevor es Skills, Hooks oder Subagents gab. Der zweite Wendepunkt sind die Plugins im Oktober 2025. Die Ankündigung (externe Seite, anthropic.com) erklärte sie zum künftigen Standardweg, Anpassungen von Claude Code zu bündeln und zu teilen.

Seither wächst vor allem die Seite der Plugins. Neue Quellen für Marktplätze, neue Bestandteile und neue Schalter für Organisationen kamen fast monatlich. Bei MCP gingen die meisten Änderungen seit 2026 in Anmeldung, Grenzen und Verwaltung. Wie die Werkzeugsuche das Kontextfenster entlastet, steht in Kapitel 05. Server, die Ereignisse in eine laufende Sitzung schicken, beschreibt Kapitel 28.

Vier Stufen einer Grenze

Die Beschreibung eines Werkzeugs schreibt der Betreiber des Servers. Sie kann lang sein, besonders wenn ein Programm sie aus einer API-Beschreibung erzeugt. Mit Version 2.1.84 vom 26.03.2026 begann Claude Code, Beschreibungen und Anweisungen auf 2 KB zu kürzen. Die Versionsliste nennt als Grund Server, die aus OpenAPI erzeugt sind und den Kontext aufblähen.

Danach änderte sich die Regel dreimal:

• 2.1.280, 22.09.2026: Die Variable CLAUDE_CODE_MAX_MCP_DESCRIPTION_LENGTH ändert die Grenze von 2.048 Zeichen für alle Server einer Sitzung.
• 2.1.295, 08.10.2026: Beschreibungen, die erst über die Werkzeugsuche geladen werden, dürfen 16.384 Zeichen lang sein.
• 2.1.296, 09.10.2026: Vorab gesendete Beschreibungen und die Anweisungen der Server dürfen 4.096 Zeichen lang sein.

Eine Begründung für die beiden Zahlen nennt die Versionsliste nicht. Sie passen aber zu den Kosten. Eine Beschreibung über die Werkzeugsuche kommt erst ins Gespräch, wenn Claude das Werkzeug braucht. Was vorab im Fenster steht, belegt Platz von der ersten Runde an, auch wenn das Werkzeug nie läuft.

Die MCP-Doku (externe Seite, code.claude.com) führt am 15.10.2026 die neuen Zahlen und 2.048 Zeichen nur noch als frühere Grenze. Wer einen Server baut, richtet sich trotzdem nach der kleineren Zahl, denn ältere Fassungen von Claude Code kürzen weiter bei 2.048 Zeichen.

Wem man bei einem Plugin vertraut

Vertrauen bei einem Plugin hat drei Ebenen: den Marktplatz, das Plugin und seine späteren Fassungen.

Der Marktplatz. Sein Name ordnet ihn einer von drei Stufen zu: offiziell, Community oder fremd. Namen der ersten beiden Stufen nimmt Claude Code nur für Marktplätze aus Repositories unter github.com/anthropics/ an (Doku zur Sicherheit von Plugins (externe Seite, code.claude.com)). Seit Version 2.1.280 weist Claude Code auch Marktplätze ab, deren Name einen reservierten nur nachahmt. Der Marktplatz eines Kollegen oder der eigenen Organisation zählt als fremd.

Das Plugin. Ein Plugin bringt bis zu fünf Arten von Code mit:

• Hooks laufen als Befehle der Shell.
• Beobachter starten von selbst im Hintergrund.
• MCP- und Language-Server laufen als eigene Prozesse.
• Programme aus bin/ kann Claude in der Shell aufrufen.
• Die Hooks eines Mods laufen als Funktionen in Claude Code selbst (Doku zu Mods (externe Seite, code.claude.com)).

Rechteregeln und Sandbox decken die Werkzeugaufrufe ab, die Claude macht. Hooks, Beobachter, Server und die Prozesse, die ein Mod startet, laufen außerhalb der Sandbox, mit den vollen Rechten des Nutzers. Skills und Subagents eines Plugins kommen als Anweisungen ins Fenster und lenken, was Claude mit seinen Werkzeugen tut. Warum fremder Text im eigenen Fenster ein eigenes Risiko ist, erklärt Agenten und Harness, Kapitel 02 auf der dritten Ebene; welche Teile die Sandbox umschließt, Kapitel 16.

Die Detailansicht in /plugin nennt nur, dass ein Plugin Hooks hat. Die Befehle dahinter liest man in den Dateien des Plugins. Die Doku nennt dafür hooks/hooks.json, die .mcp.json und jede Datei in bin/. Die Warnung vor jeder Installation sagt dasselbe von der anderen Seite: Anthropic kontrolliert nicht, welche Server, Dateien und Programme ein Plugin enthält.

Die späteren Fassungen. Ist die Aktualisierung für einen Marktplatz an, ersetzt Claude Code die Dateien eines Plugins im Hintergrund. Was man geprüft hat, kann sich danach auf der Platte geändert haben. Für den offiziellen Marktplatz ist die Aktualisierung in der Voreinstellung an. Der Community-Katalog legt fast jedes Plugin auf einen Commit fest, und Claude Code installiert dann keinen anderen. Seit Version 2.1.275 holt Claude Code Plugins aus npm ohne deren Instal­la­ti­ons­skripte.

Wo eine Sperre aufhört

Die verwalteten Einstellungen für MCP und Plugins sind fein, und gerade deshalb lohnt der Blick auf ihre Ränder. Die Doku nennt sie selbst:

• Namen lassen sich frei wählen. Ein Eintrag mit serverName vergleicht nur den Namen, den ein Nutzer seinem Server gibt. Den kann jeder frei wählen, auch github für einen ganz anderen Server (Doku zum verwalteten MCP (externe Seite, code.claude.com)). Durchsetzen lässt sich eine Liste nur über Adresse oder Startbefehl.
• Die Liste der Marktplätze prüft die Quelle des Marktplatzes. Ein einzelnes Plugin aus einem erlaubten Marktplatz sperrt man über enabledPlugins mit dem Wert false (Doku für Organisationen (externe Seite, code.claude.com)).
• /plugin selbst lässt sich nicht abschalten. Kein Schlüssel tut das. Am nächsten kommt eine Liste mit nur dem eigenen Marktplatz, fest eingeschaltete Plugins und disableSideloadFlags.
• disableSideloadFlags deckt die Kommandozeile ab. Eine .mcp.json und claude mcp add regelt der Schalter nicht, dafür braucht es zusätzlich allowedMcpServers.
• Eine Sperre bleibt stumm. Verschwindet ein Server durch eine neue Regel, sieht der Nutzer keinen Hinweis auf den Grund. Die Doku rät, Betroffenen vorher zu sagen, was gesperrt wird.
• Eine Organisation, eine Fassung. Die Einstellungen aus der Verwaltung von claude.ai gelten für alle Mitglieder gleich. Unterschiedliche Regeln je Gruppe brauchen Einstellungen auf den Geräten oder ein Gateway mit eigener Richtlinie je Gruppe.

Ein letzter Punkt betrifft die Reihenfolge der Quellen. Liefert die Verwaltung in claude.ai auch nur einen einzigen Schlüssel, ignoriert Claude Code in der Voreinstellung die Plugin-Schlüssel aus einer Datei auf dem Gerät, bis auf wenige Ausnahmen. Wer beide Wege mischt, stellt managedSourcesBehavior auf "merge". Wie die Quellen der Einstellungen sonst zusammenwirken, erklärt Kapitel 15.

Ein Plugin außerhalb von Claude Code

Dasselbe Format installiert sich auch in claude.ai und in Cowork. Dort lädt aber nur ein Teil der Bestandteile (Plugin-Übersicht (externe Seite, code.claude.com)). Neben den Marktplätzen gibt es das Verzeichnis von Anthropic in claude.ai. Ein Plugin von dort erreicht Claude Code über das Konto, als synchronisiertes Plugin.

Wie weit das Format über Anthropic hinausreicht, zeigt eine Seite von OpenAI. Sie erklärt, wie man ein vorhandenes Plugin für Claude Code in das Plugin-Verzeichnis von ChatGPT und Codex bringt (Anleitung von OpenAI (externe Seite, developers.openai.com)). Skills übernimmt das Portal von OpenAI mitsamt Skripten und Dateien. Befehle und Subagents soll man vorher in Skills umbauen, Hooks vor der Einreichung entfernen. Einen lokalen MCP-Server stellt man vorher unter eine öffentliche HTTPS-Adresse, sonst verweist OpenAI an seine Ansprechpartner. Eintrag und Freigabe in einem Marktplatz von Claude gehen dabei nicht mit.

Für die Planung heißt das: Skills und ein MCP-Server im Netz lassen sich zwischen den Herstellern mitnehmen. Hooks gehen ins öffentliche Verzeichnis von OpenAI nicht mit. Was Beobachter, Language Server oder Ausgabestile leisten, überführt man vorher in Skills, und Einstellungen nur für Claude entfallen. Ein Plugin, das in beiden Welten laufen soll, setzt deshalb auf Skills und einen Server im Netz.

Was Codex anders löst

Codex kennt MCP und Plugins ebenfalls. Bei OpenAI bündelt ein Plugin Skills und MCP-Server, dazu Hooks und Erweiterungen für den Browser, und ChatGPT und Codex teilen ein gemeinsames Verzeichnis (Plugin-Doku von OpenAI (externe Seite, learn.chatgpt.com)). Die Erweiterung für die IDE kennt bei Codex keine Plugins. Claude Code verwaltet Plugins auch in VS Code, seit Version 2.1.16 vom 22.01.2026 (Versionsliste (externe Seite, code.claude.com)).

Bei MCP liegen die Unterschiede in der Konfiguration. Codex schreibt Server in config.toml, und die Desktop-App, die Kommandozeile und die Erweiterung für die IDE teilen sich diese Datei (MCP-Doku von OpenAI (externe Seite, learn.chatgpt.com)). Eine Datei je Projekt gilt dort nur in vertrauten Projekten.

Bei der Freigabe je Server geht Codex einen Schritt weiter. Für jeden Server und jedes seiner Werkzeuge lässt sich eine von vier Stufen der Freigabe setzen. Eine davon fragt nur bei Werkzeugen, die der Server nicht als nur lesend markiert. Dazu kommt eine Liste erlaubter und gesperrter Werkzeuge je Server. Die MCP-Doku von Claude Code beschreibt keine Stufe, die nach der Markierung für Lesen und Schreiben unterscheidet. Dort regeln Rechteregeln einzelne Werkzeuge oder alle Werkzeuge eines Servers, und der Betreiber kann ein Werkzeug so markieren, dass es jedes Mal fragt.

Bei den Anweisungen der Server rät OpenAI, die ersten 512 Zeichen für sich verständlich zu halten. Claude Code kürzt sie seit Version 2.1.296 in der Voreinstellung bei 4.096 Zeichen. Der Rat, das Wichtigste nach vorn zu stellen, steht in beiden Docs.

Was offen bleibt

• Ist das Plugin-System noch eine Beta? Die Ankündigung vom Oktober 2025 nannte eine öffentliche Beta. Die Versionsliste meldet kein Ende davon, und die heutigen Seiten der Doku zu Plugins nennen keinen Status.
• Seit wann kommen Plugins aus dem Konto? Die Versionsliste nennt Version 2.1.275, die Doku zum Installieren Version 2.1.273 als Mindestfassung.
• Wie groß ist der offizielle Marktplatz? Am 12.10.2026 führte sein Katalog 315 Plugins. Die Doku schreibt, er ändere sich oft, und nennt deshalb keine Liste.
• Wo gehören Mods hin? Die Doku führt sie unter den Plugins. In dieser Rubrik stehen sie zusammen mit den Hooks in Kapitel 18.