Agent Plugins: Skills und MCP in einem Paket

Wer einen Skill schreibt und ihn in mehreren Tools nutzen will, kennt das Problem: Claude Code erwartet ihn woanders als Cursor, Copilot woanders als Codex. Der Inhalt ist identisch, nur die Verpackung nicht. Seit dem 06.08.2026 gibt es dagegen einen Standard, Agent Plugins 1.0.0. Er ist bewusst klein gehalten, und genau daran hängt, was er taugt.

Was der Standard festlegt

Ein Agent Plugin ist ein Ordner mit drei möglichen Bestandteilen an festen Orten. Mehr definiert die Spezifikation nicht.

Beide Bausteine gab es vorher schon. Das SKILL.md-Format beschreibt, wie ein Skill aufgebaut ist, und MCP regelt, wie ein Agent an Tools und Daten kommt. Agent Plugins definiert nur, wie beides gemeinsam in einem Paket liegt, damit ein Client es findet.

Pflicht ist nur das Manifest, die beiden Komponenten sind optional. Ein Plugin, das einen einzigen Skill mitbringt, besteht also aus zwei Dateien:

hello-plugin/
├── plugin.json
└── skills/
    └── greet/
        └── SKILL.md

Und das Manifest braucht genau zwei Felder:

{
  "$schema": "https://agent-plugins.org/schemas/1.0.0/plugin.schema.json",
  "name": "hello-plugin"
}

Alles, was ein Client darüber hinaus kann, kommt in einen eigenen Ordner mit Reverse-Domain-Namen, etwa com.beispiel.client/. Andere Clients ignorieren ihn. So kann jedes Tool seine Eigenheiten behalten, ohne dass sie in den gemeinsamen Teil sickern.

flowchart TB
  A["plugin.json"] --> K
  B["skills/"] --> K
  C["mcp.json"] --> K
  D["com.beispiel.client/"] --> X
  K["Portabler Kern<br/>jeder konforme Client liest ihn"]
  X["Client-Erweiterung<br/>andere Clients ignorieren sie"]
  K --> O["Bleibt Sache des Clients:<br/>Installation, Rechte,<br/>Sandboxing, Vertrauen"]
  X --> O
  classDef success fill:#14532D,stroke:#22C55E,color:#86EFAC
  classDef decision fill:#1A3A4A,stroke:#F59E0B,color:#FDE68A
  class K success
  class X,O decision

Wer dahintersteht

Die Meldung lief unter OpenAI-Flagge, initiiert hat den Vorschlag aber Vercel. Ausgearbeitet haben die 1.0.0 dann Vertreter von AWS, Anysphere (die Firma hinter Cursor), GitHub, Microsoft, OpenAI und Vercel. Im Technical Steering Committee sitzen fünf benannte Maintainer von Amazon, Cursor, Microsoft, OpenAI und Vercel, Lead ist Jonathan Hefner von Vercel. Das Projekt ist offen lizenziert, Diskussionen laufen öffentlich auf GitHub.

Zum Start unterstützen ChatGPT und Codex, Cursor, GitHub Copilot, Kiro und VS Code das Format.

Anthropic ist nicht dabei, weder im Komitee noch in der Startliste. Das ist bemerkenswert, weil beide Bausteine des Standards von dort stammen: SKILL.md und MCP. Warum die Firma fehlt, hat bislang niemand öffentlich erklärt, und Spekulation hilft hier wenig. Praktisch relevant ist eher, was das für den Alltag bedeutet, und das lässt sich messen.

Der Praxistest: was heute wirklich portabel ist

Was heißt das konkret für ein Tool, das nicht mitgezeichnet hat? Ich habe das Beispiel-Plugin von oben gebaut und mit Claude Code 2.1.224 durchgespielt, am 10.08.2026. Drei Beobachtungen, alle auf genau dieses eine Paket und diese eine Version bezogen.

Der eingebaute Validator lehnt es ab. claude plugin validate ./hello-plugin meldet, dass ein Manifest unter .claude-plugin/plugin.json erwartet wird, nicht im Wurzelverzeichnis.

Der Skill funktioniert trotzdem. Nach claude --plugin-dir ./hello-plugin lässt er sich als /hello-plugin:greet aufrufen und antwortet. Der Grund ist allerdings nicht Kompatibilität, sondern Gleichgültigkeit: Claude Code wertet das Wurzel-Manifest nicht aus. Laut Doku ist ein Manifest optional, solange die Komponenten an den Default-Orten liegen, und skills/ ist bei beiden Seiten derselbe Ort. Nachweisen lässt sich das mit einer Umbenennung. Legt man dasselbe Paket in einen Ordner probe-a, während im plugin.json weiterhin hello-plugin steht, heißt der Skill danach /probe-a:greet. Der Namespace kommt aus dem Ordnernamen, das Manifest wird ignoriert.

Der MCP-Teil kommt nicht mit. Ich habe je einen Probe-Server in mcp.json und in .mcp.json eingetragen, der beim Start eine Datei anlegt. Angelegt wird nur die Datei des Servers aus .mcp.json, dem Claude-Code-eigenen Pfad. Der Server aus der standardkonformen mcp.json startet nicht.

Die Lücke ist damit kleiner, als die fehlende Beteiligung vermuten lässt, aber sie ist da. Wer ein bestehendes Claude-Code-Plugin standardkonform machen will, kopiert das Manifest von .claude-plugin/plugin.json nach plugin.json und ergänzt dort $schema. Für MCP kommt die Konfiguration zusätzlich als mcp.json ins Wurzelverzeichnis, ebenfalls mit $schema, und die Pfadvariablen müssen dabei von ${CLAUDE_PLUGIN_ROOT} auf ${PLUGIN_ROOT} umgeschrieben werden. Der Rest ist identisch. Beide Dateipaare nebeneinander sind unschön, funktionieren aber in beiden Welten, weil jede Seite ignoriert, was sie nicht kennt.

Was der Standard bewusst offenlässt

Hier wird es für alle interessant, die Plugins nicht nur bauen, sondern auch verantworten müssen. Die Spezifikation regelt Verpackung und Auffinden, sonst nichts. Installation, Marktplätze, Rechtevergabe, Sandboxing und die Frage, ob ein Plugin überhaupt vertrauenswürdig ist, bleiben komplett beim Client.

Das ist keine Interpretation, das Projekt schreibt es selbst so. Im Dokument Future Considerations steht ausdrücklich, dass 1.0.0 kein Vertrauensmodell, kein Rechtesystem und keine Sandboxing-Anforderungen definiert. Ebenfalls offen: Signaturen und Herkunftsnachweise, der Umgang mit Zugangsdaten, Allowlists für Unternehmen und ein einheitliches Audit-Log.

Bei Secrets wird der Standard sogar explizit: Werte in der env-Konfiguration eines MCP-Servers gelten als sichtbare Paketdaten, Plugins dürfen dort keine Zugangsdaten hinterlegen. Einen portablen Ersatz dafür gibt es aber noch nicht. Wer API-Keys braucht, löst das weiter clientspezifisch.

Diese Lücke ist nicht theoretisch. Im Juli sind gefälschte Agent Skills an Sicherheitsscannern vorbeigekommen, und jeder zusätzliche MCP-Server vergrößert die Angriffsfläche eures Agenten. Ein gemeinsames Format macht Verteilung leichter, für gute wie für schlechte Pakete. Die Prüfung bleibt an euch und an eurem Tool hängen.

Genau daran setzt auch die Kritik an. The Next Web zitiert den SST-Entwickler Dax Raad, der den Standard für zu dünn hält: die wirklich nützlichen Teile landeten am Ende doch wieder in clientspezifischen Erweiterungen. Die Gegenposition ist genauso nachvollziehbar. Ein schmaler Standard wird eher übernommen als ein breiter, und die Alternative war kein besserer Standard, sondern gar keiner.

Was ihr jetzt damit macht

Für die meisten Teams ist heute noch nichts zu tun. Wer Skills nur intern nutzt, gewinnt durch das Umpacken nichts.

Anders sieht es aus, sobald ihr Skills weitergebt. Wer sie öffentlich oder firmenweit verteilt, sollte jetzt auf die Standardstruktur wechseln. Der Aufwand liegt bei zehn Minuten, und das Paket funktioniert danach in mehr Tools. Dasselbe gilt für gemischte Teams, in denen der eine Cursor nutzt und die andere Claude Code: für den Skills-Teil reicht dann eine Ablage statt zwei.

Beim Einsatz fremder Plugins ändert der Standard dagegen nichts an eurer Sorgfaltspflicht. Er macht die Herkunftsfrage eher dringlicher, weil dasselbe Paket künftig durch mehr Kanäle läuft.

Was wirklich zählt, entscheidet sich erst in Version 2. Ob Signaturen, Rechte und ein Vertrauensmodell dazukommen, oder ob jeder Anbieter das weiter allein löst. Bis dahin ist Agent Plugins genau das, was draufsteht: eine Einigung darüber, wie der Ordner aussieht. Das ist wenig, und es ist mehr als vorher.

Wenn ihr noch keine eigenen Skills schreibt, fangt besser dort an. Das Verpackungsformat ist der einfachere Teil.