Agent Plugins 1.0.0: Das gemeinsame Verpackungsformat für Skills und MCP-Server

Google, Microsoft, OpenAI, Cursor, Vercel und AWS haben sich hinter Agent Plugins 1.0.0 gestellt, einer Spezifikation dafür, wie Plugins für KI-Agenten verpackt werden. Sie regelt die Verzeichnisstruktur, das Format der Konfigurationsdateien sowie die Entdeckungsregeln für zwei Arten von Komponenten: Skills und MCP-Server. Das gesteckte Ziel ist einfach: Einmal einen Plugin schreiben und es in jedem kompatiblen Client ausführen.

Bislang gab es zwei übliche Wege, einem Programmier-Agenten neue Fähigkeiten zu verleihen. Ein Skill ist eine Sammlung von Markdown-Anweisungen, die der Agent liest, wenn er sie benötigt. Ein MCP-Server ist ein separates Verfahren, das den Agenten mit externen Tools, APIs oder Datenbanken verbindet. Der Inhalt beider war bereits zwischen Tools portabel, doch jedes Tool hatte seine eigenen Gepflogenheiten hinsichtlich der Verzeichnisstruktur, der Namen der Konfigurationsdateien und der Orte, an denen die Dateien gespeichert werden sollten.

Die Version 1.0.0 befasst sich nur mit dem äußeren Wrapper. Der Inhalt einer Fähigkeit sowie das MCP-Protokoll selbst bleiben unberührt.

Warum das wichtig ist

Der Vorteil zeigt sich für drei Gruppen:

• Plugin-Entwickler erhalten eine einheitliche Verzeichnisstruktur, die in allen unterstützten Clients funktioniert. Es ist nicht mehr notwendig, separate Kopien für Cursor, Copilot, Codex und andere Tools zu halten.
• Tool-Anbieter erhalten feste Orte für skills/ und mcp.json, sodass sie keine eigene Entdeckungslogik oder Konfigurationsverarbeitung entwickeln müssen. Ein Anbieter kann weiterhin eigene Erweiterungen in einem namensgebundenen Verzeichnis hinzufügen, ohne andere Implementierungen zu stören.

Das umfassendere Ökosystem profitiert von drei Gestaltungsentscheidungen: Entdeckung über Verzeichnisse, keine zusätzliche Einrichtung außer dem Platzieren der Dateien sowie Fehler, die eingegrenzt bleiben. Die Verteilung wird einfacher, und Entwickler können sich darauf konzentrieren, was sie entwickeln wollen, anstatt darüber nachzudenken, welche Tools sie nutzen sollen.

Die Grenzen sind genauso klar. Die Spezifikation standardisiert die Paketverpackung, sagt aber nichts über die Sicherheit des Inhalts aus. Es gibt keine Signaturen, kein Berechtigungsmodell und keine Handhabung von Geheimnissen. Derzeit liegt der Vorteil in der Effizienz für Entwickler, es werden jedoch weder Sicherheits- noch Vertrauensgarantien geboten.

Verzeichnisstruktur

Ein konformes Plugin ist lediglich ein Ordner. Für ein Beispiel namens reports-plugin sieht der vollständige Baum so aus:

reports-plugin/
├── plugin.json                  # Required: The only entry point for the plugin
├── skills/                      # Optional: Collection of skills
│   ├── summarize/               # One individual skill
│   │   ├── SKILL.md             #   Required: Skill definition file
│   │   ├── scripts/             #   Optional: Scripts used by the skill
│   │   │   └── analyze.sh
│   │   └── references/          #   Optional: Reference documentation for the skill
│   │       └── checklist.md
│   ├── deploy/                  # A second skill
│   │   ├── SKILL.md
│   │   ├── scripts/
│   │   │   └── rollback.sh
│   │   └── references/
│   │       └── runbook.md
│   └── code-review/             # A third skill
│       └── SKILL.md
├── mcp.json                     # Optional: MCP server configuration
├── com.cursor.tools/            # Optional: Cursor-specific extensions, other clients skip automatically
│   └── hooks/
│       └── hooks.json
├── LICENSE
└── CHANGELOG.md

Kunden schauen sich genau an drei Orten um. plugin.json kennzeichnet den Ordner als gültigen Plugin. Jeder Unterordner erster Ebene in skills/, der ein SKILL.md enthält, zählt als eine Fähigkeit. mcp.json wird als Konfiguration des MCP-Servers gelesen. Ordner, die im umgekehrten Domain-Stil benannt sind, wie zum Beispiel com.cursor.tools/, werden nur vom Client gelesen, zu dem sie gehören, also von Cursor. Andere Clients, darunter ChatGPT und Codex, überspringen sie einfach.

Das plugin.json-Manifest

plugin.json ist die einzige obligatorische Datei, und eine minimale Version ist sehr klein:

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

Das Schema ist geschlossen und enthält zehn erlaubte Oberfelder: $schema, name, version, description, author, homepage, repository, license, keywords sowie extensions. Ein unbekanntes Feld wird gemeldet und ignoriert, wodurch der Plugin dennoch geladen wird. Ein fehlerhafter name ist hingegen ein anderes Problem: Fehlt er, hat er die falsche Typologie oder enthält er ungültige Zeichen (Großbuchstaben, doppelte Bindestriche, leere Zeichenketten), wird das gesamte Plugin abgelehnt.

Die Regeln für name: 1 bis 64 Zeichen lang, bestehend aus Kleinbuchstaben, Ziffern, Bindestrichen und Punkten. Er muss mit einem Buchstaben oder einer Ziffer beginnen und enden, und es sind aufeinanderfolgende zwei Bindestriche oder zwei Punkte nicht zulässig.

Wie Komponenten gefunden werden

Die Entdeckung basiert ausschließlich auf Verzeichnissen. plugin.json kann Komponenten nicht an einen anderen Ort verschieben oder ihre Konfiguration direkt einbetten. Es existieren nur drei Arten von Standorten:

• skills/: Jedes Unterverzeichnis erster Ebene, das eine SKILL.md-Datei enthält, gilt als Fähigkeit. Tiefere Verzeichnisse werden nicht durchsucht.
• mcp.json: Die Konfiguration des MCP-Servers.
• Verzeichnisse für Client-Erweiterungen: Sie tragen eine umgekehrte Domain-Bezeichnung wie com.example.client/ und werden von allen anderen Clients ignoriert.

Fehlende Komponenten stellen keinen Fehler dar. Wenn skills kein Verzeichnis ist oder mcp.json keine reguläre Datei, wird diese Komponentenart als ungültig markiert, während die anderen wie gewohnt geladen werden.

MCP-Konfiguration

mcp.json benötigt zwei Felder auf höchster Ebene, $schema und mcpServers. Die $schema-Version muss der in plugin.json deklarierten Version entsprechen, andernfalls wird die gesamte MCP-Konfiguration abgelehnt.

Drei Transportmethoden sind definiert:

• stdio führt einen lokalen Unterprozess aus. command ist ein ausführbares Token – entweder ein einfacher Name, der über den System-PATH aufgelöst wird, oder ein relativ zum Plugin liegender Pfad, der mit ./ beginnt. Optionale Felder sind args, env und cwd; cwd hat standardmäßig den Wurzelpfad des Plugins als Wert.
• streamable-http ist der aktuelle MCP-Standard für Streamable HTTP.
• sse ist der ältere HTTP+SSE-Transport aus der MCP-Spezifikation vom 2024-11-05 und wird aus Kompatibilitätsgründen beibehalten.

Die Clients müssen mindestens stdio oder streamable-http implementieren, wobei die Kombination beider besser ist. sse ist optional.

Umgebungsvariablen und persistente Daten

Jedes Mal, wenn ein Client einen stdio-Prozess startet, muss er zwei Variablen setzen. PLUGIN_ROOT enthält den absoluten Pfad zum Wurzelverzeichnis des Plugins. PLUGIN_DATA verweist auf ein vom Client bereitgestelltes Verzeichnis mit persistenten Daten, das auch nach Updates des Plugins erhalten bleibt und bei Deinstallation entfernt wird.

Sowohl ${PLUGIN_ROOT} als auch ${PLUGIN_DATA} können in args, in den env-Werten sowie in cwd vorkommen. Die Ersetzung erfolgt in einem einzigen Schritt im reinen Textformat. Weitere Platzhalter sowie eine Erweiterung von Variablen im Shell-Stil werden nicht unterstützt.

Fehler bleiben lokal

Die Spezifikation wendet eine Regel von „ein teilweiser Fehler darf sich nicht kaskadieren“ auf mehreren Ebenen an:

• Wenn ein MCP-Server nicht starten kann, beeinflusst das die anderen Server oder Fähigkeiten nicht.
• Eine Fähigkeit mit fehlerhafter Formatierung wird übersprungen, während der Rest normal geladen wird.
• Ein MCP-Eintrag, der ein Transportprotokoll verwendet, das der Client nicht unterstützt, wird übersprungen.
• Falls mcp.json völlig ungültig ist, werden nur die MCP-Komponenten deaktiviert, während die Fähigkeiten weiterhin geladen werden.

Was die Spezifikation weglässt

In Version 1 fehlen Informationen darüber, wie Plugins installiert werden, wie die Laufzeitberechtigungen gesteuert werden, wie Autoren authentifiziert werden sowie wie Geheimnisse oder API-Schlüssel sicher gespeichert werden. Im Text heißt es ausdrücklich, dass Header-Werte und Umgebungsvariablen sichtbare Paketdaten sind und keine zuverlässige Methode zur Aufrechterhaltung der Vertraulichkeit darstellen. Es gibt außerdem keine OAuth-Konfiguration sowie kein portables Feld zur Referenzierung von Zugangsdaten, wodurch die Autorisierung von jedem Client auf eigene Weise handhabt werden muss.

Wer ist dabei und wer nicht?

Die Startunterstützung umfasst sechs Clients: Kiro, VS Code, Cursor, GitHub Copilot, Codex und ChatGPT. Google trat am selben Tag als Betreiber bei, und seine Agents CLI gehört zu den ersten Produkten, die dieses Format übernehmen. Auch AWS unterstützt das Projekt.

Anthropic hat sowohl das Skills-Format als auch MCP entwickelt, und Claude Code verwendet seit 2025 ein nahezu identisches Plugin-Paketierungsverfahren. Dennoch gehörte Anthropic nicht zur Arbeitsgruppe, und Claude Code steht nicht auf der ursprünglichen Support-Liste.

Ein End-to-End-Beispiel mit Google’s Agents CLI

Agents CLI gehört zu den frühen Adoptern. Nach der Installation stellt es einem Programmieragenten sieben Fähigkeiten zur Verfügung, die ADK-Muster, Projekt-Strukturen, Bewertung, Bereitstellung und Überwachung abdecken.

Betrachten wir den Aufbau eines RAG-Wissensassistenten. Ein Entwickler beschreibt das Ziel in einfachen Worten, und der Agent arbeitet anschließend selbstständig weiter:

1. Er erstellt die Projektstruktur anhand des ADK-Templates agentic_rag, wobei Vector Search als Datenspeicher verwendet wird.
2. Es stellt fest, dass das Template keine Zitierfunktionen bietet, schreibt die Anweisungen für den Agenten um, um inline-Zitate zu verlangen, und wechselt den Abrufmechanismus so, dass Quellen-IDs zurückgegeben werden.
3. Es richtet den Datenspeicher ein, lädt 12 Python-Referenzdokumente als Korpus und führt einen Funktionscheck durch.

Vor der Bereitstellung wird eine Bewertung durchgeführt: 20 Testfälle in vier Gruppen – 6 zur Überprüfung der Abrufgenauigkeit, 5 zur Prüfung der Ablehnung bei fehlendem Kontext, 5 zur Überprüfung des mehrstufigen Schlussfolgerungsvermögens und 4 zur Überprüfung der Zitiergenauigkeit.

Durch die Bewertung wurde ein Randfall aufgedeckt, der Halluzinationen verursachte. Bei Fragen, die außerhalb des Korpus lagen, antwortete der Agent manchmal aus allgemeinem Wissen, anstatt zuzugeben, dass er es nicht wusste. Der Grund war ein einziger Satz im Systemprompt, der besagte, dass einfache Fragen mit bekannter Antwort direkt ohne Tools beantwortet werden können. Der Entfernung dieses Satzes behebte das Problem vollständig.

Die Bereitstellung in Google Cloud dauert zwei bis drei Minuten, wobei Cloud Trace standardmäßig aktiviert ist. Nach der Registrierung bei Gemini Enterprise können alle Personen in der Organisation den Agenten finden und verwenden.