Agent Plugins: Warum Paketierung der nächste Schritt nach MCP ist

Fragen Sie in Ihrer IT einmal nach, wie viele MCP-Server im Unternehmen aktuell laufen. Die ehrliche Antwort lautet in den meisten Häusern: unbekannt. Das Model Context Protocol hat in kurzer Zeit gelöst, was jahrelang als ungelöst galt – ein Assistent kann auf Ticketsystem, Fileshare und Fachverfahren zugreifen, ohne dass für jedes Modell ein eigener Konnektor gebaut wird. Was MCP nie geregelt hat: wie dieser Zugriff als Ganzes verteilt, versioniert und wieder eingesammelt wird.

Genau an dieser Stelle setzt ein neuer Standard an. Am 6. August 2026 wurde die Agent Plugins Specification 1.0.0 veröffentlicht – ein herstellerneutrales Format, das Agent Skills und MCP-Server zu einem einzigen, verteilbaren Paket bündelt. Getragen wird die Initiative von einem Technical Steering Committee, in dem unter anderem Amazon, Cursor, Microsoft, OpenAI und Vercel als Core Maintainer vertreten sind; Google ist am Tag der Veröffentlichung ebenfalls beigetreten.

Für IT-Entscheider im Mittelstand ist das keine Randnotiz aus der Entwicklerwelt. Es ist die erste Antwort auf eine Frage, die in Ihrer Organisation längst auf dem Tisch liegt: Wie verteilen Sie eine geprüfte KI-Fähigkeit an 300 Mitarbeitende, ohne sie 300-mal von Hand zu konfigurieren?

Was der Standard tatsächlich definiert

Agent Plugins erfindet weder MCP noch Agent Skills neu. Die Spezifikation beschreibt ausdrücklich nur, wie ein Client beide Bestandteile gemeinsam in einem Paket findet. Das klingt bescheiden – und ist genau der Punkt.

Ein Plugin ist ein Verzeichnis, kein Archiv und kein Installer. Es enthält:

• plugin.json – das Manifest im Wurzelverzeichnis. Pflichtfelder sind lediglich $schema (die kanonische Kennung der Spezifikationsversion) und name. Optional kommen version, description, author, homepage, repository, license, keywords und extensions hinzu. Das Schema ist geschlossen: Andere Top-Level-Felder muss ein Client melden und ignorieren.
• skills/ – jedes unmittelbare Unterverzeichnis mit einer SKILL.md gilt als ein Skill. Format und Frontmatter richten sich nach der Agent-Skills-Spezifikation; tiefer verschachtelte Verzeichnisse werden bewusst nicht durchsucht.
• mcp.json – die Beschreibung der MCP-Server unter dem Schlüssel mcpServers, mit explizitem Transport: stdio, streamable-http oder das veraltete sse. Für stdio-Server sind command, args, env und cwd definiert, für die HTTP-Varianten url und headers.
• Reverse-Domain-Verzeichnisse wie com.example.client/ – hier legt jeder Client seine eigenen Erweiterungen ab, ohne den portablen Kern anzufassen.

Interessanter als die Feldliste sind die Sicherheitsregeln, die der Standard bereits mitbringt. Jeder Pfad, den ein Client aus dem Paket liest oder ausführt, muss nach der Auflösung innerhalb des Plugin-Wurzelverzeichnisses liegen – Symlinks, die nach außen zeigen, sind abzulehnen. command muss ein einzelnes Executable-Token sein, ausdrücklich kein Shell-String. Remote-Endpunkte müssen HTTPS verwenden, außer sie zeigen auf Loopback. Und die Spezifikation stellt zweimal unmissverständlich fest: In env und headers gehören keine Zugangsdaten. Diese Werte sind sichtbare Paketdaten, kein Secret-Mechanismus.

Für Laufzeitpfade stehen genau zwei Platzhalter zur Verfügung: ${PLUGIN_ROOT} zeigt auf das ausgelieferte Paket, ${PLUGIN_DATA} auf ein vom Client verwaltetes, über Updates hinweg persistentes Datenverzeichnis. Installierte Abhängigkeiten und Caches gehören nach PLUGIN_DATA, mitgelieferte Skripte und Binaries nach PLUGIN_ROOT. Wer schon einmal ein Update ausgerollt hat, das den Zustand eines Werkzeugs mitgelöscht hat, weiß, warum diese Trennung normativ festgeschrieben wurde.

Bemerkenswert ist auch das Fehlerverhalten: Ein ungültiger Skill lässt die anderen Skills weiterlaufen. Ein defekter MCP-Server-Eintrag deaktiviert nur diesen Eintrag, nicht das Paket. Nur ein ungültiges Manifest führt zur Ablehnung des gesamten Plugins. Diese abgestuften Fehlergrenzen sind der Unterschied zwischen einem Standard, der im Betrieb überlebt, und einem, der beim ersten Tippfehler die halbe Abteilung lahmlegt.

Was der Standard bewusst offenlässt

Hier wird es für Sie als Entscheider relevant. Version 1.0.0 definiert kein Trust-Modell, kein Berechtigungssystem und keine Sandbox-Anforderungen. Sie regelt weder Distribution noch Installation. Es gibt keine Signaturprüfung, keine Herkunftsverifikation, keinen portablen Secret-Mechanismus und keine Organisationsrichtlinien.

Das ist keine Nachlässigkeit, sondern eine dokumentierte Designentscheidung – und das Projekt benennt sie selbst als Feld für kommende Versionen: Berechtigungsdeklarationen im Manifest, abgestufte Vertrauensstufen, kryptografische Signaturen und Attestation-Ketten, clientvermittelte Secret-Injektion, Allow- und Blocklisten für Organisationen sowie ein standardisiertes Audit-Event-Schema stehen ausdrücklich auf der Liste möglicher Erweiterungen. Verbindlich zugesagt ist davon nichts; Version 1.1.0 liegt derzeit als Working Draft vor.

Was sich einzig an Berechtigungen im Paket findet, ist das Feld allowed-tools in der SKILL.md – und das ist in der Agent-Skills-Spezifikation selbst als experimentell gekennzeichnet.

Die Konsequenz ist klar: Der Standard verpackt die Bestandteile, die Vertrauensentscheidung bleibt bei Ihnen. Wer Agent Plugins als “geprüft, weil standardkonform” liest, hat die Spezifikation missverstanden. Ein konformes Plugin kann einen stdio-Prozess auf Ihrem Anwendungsserver starten. Standardkonformität sagt darüber nichts aus.

Warum Paketierung der nächste Schritt nach MCP ist

MCP hat den Zugriff standardisiert. Agent Plugins standardisiert den Baustein.

Der Unterschied ist derselbe wie zwischen einem Netzwerkprotokoll und einem Paketformat. HTTP hat den Datenaustausch geregelt, aber erst Container-Images haben Software wirklich verteilbar gemacht – weil sie Anwendung, Konfiguration und Abhängigkeiten zu einer Einheit mit Namen und Version zusammengefasst haben. Genau diese Einheit hat der KI-Landschaft bisher gefehlt.

Denken Sie an einen konkreten Fall: Ihre Rechtsabteilung hat eine Vorgehensweise zur Vertragsprüfung erarbeitet – Prüfschritte, Formulierungsbausteine, eine Checkliste, dazu den Zugriff auf das Dokumentenmanagement. Heute existiert das als Prompt-Sammlung in einem Wiki, als Server-Eintrag in einer YAML-Datei und als Wissen in zwei Köpfen. Als Agent Plugin ist es ein Verzeichnis mit Namen, Version, Lizenz und Repository-Angabe – das Sie ausrollen, aktualisieren und zurückziehen können.

Damit verschiebt sich die Diskussion von “Welche Tools darf die KI aufrufen?” zu “Welche Fähigkeiten stellen wir bereit, wer verantwortet sie, und in welcher Version läuft sie wo?” Das ist eine Lifecycle-Frage – und damit endlich eine Frage, für die Ihre IT bereits Prozesse hat.

Der Marketplace-Gedanke – und warum er intern beginnt

In der öffentlichen Diskussion wird der Standard schnell mit einem App-Store gleichgesetzt. Zum Start unterstützen ihn nach Angaben der Initiative unter anderem ChatGPT, Codex, Cursor, GitHub Copilot, Kiro und VS Code; Google liefert eigene Pakete über die Agents CLI und das Data Agent Kit aus.

Für den DACH-Mittelstand liegt der Wert aber nicht primär im Konsum öffentlicher Plugins – der bringt genau die Lieferketten- und Provenance-Risiken mit, die Version 1.0.0 offenlässt. Der Wert liegt im internen Katalog: geprüfte, von Ihren Fachbereichen verantwortete Pakete, die zentral freigegeben und über Ihre bestehende Versionsverwaltung ausgeliefert werden. Ein internes Register mit Freigabeworkflow statt eines offenen Bezugs aus dem Netz. Der Standard macht das erstmals mit vertretbarem Aufwand möglich, weil das Format klein und leicht zu implementieren ist – und weil die Beschreibung eines Pakets ein lesbares JSON-Manifest ist, kein proprietäres Bündel.

Was das für CompanyGPT und das AI Gateway bedeutet

CompanyGPT, unser DSGVO-konformer KI-Assistent für Unternehmen, baut auf LibreChat auf. Dort ist das Paketformat bereits angekommen: Seit Version 0.8.8-rc1 gibt es experimentelle Agent Plugins, die das 1.0.0-Format implementieren und beim Start jedes unmittelbare Unterverzeichnis eines konfigurierten Plugin-Ordners als ein Plugin laden. Zusätzlich nutzt LibreChat den vorgesehenen Extension-Namespace für optionale Command-Hooks – die standardmäßig deaktiviert sind und vom Betreiber bewusst eingeschaltet werden müssen.

Für uns heißt das: CompanyGPT unterstützt Agent Plugins in der zugrundeliegenden Plattform bereits experimentell, und wir werden das Format in unseren betreuten Umgebungen unterstützen, sobald es aus der Experimentierphase heraus ist. Ein Datum nennen wir bewusst nicht – wer eine experimentelle Funktion mit Prozessausführung auf dem Anwendungsserver ohne Reifegradprüfung in Produktion bringt, handelt gegen die eigene Empfehlung. Die vorhandene Integrationsbibliothek mit ihren MCP-Anbindungen ist dabei die natürliche Grundlage: Was heute als einzelne Integration konfiguriert wird, lässt sich künftig als paketierter Baustein bündeln und verteilen.

Beim AI Gateway sehen wir die Rollenverteilung so: Ein Plugin beschreibt, welche Werkzeuge ein Agent erreichen darf – das Gateway kontrolliert, über welche Modelle, mit welchem Budget und unter welcher Kostenstelle er das tut. Beides greift ineinander, ohne sich zu ersetzen. Wir planen, die Paketierung in unsere Governance-Ebene aufzunehmen, wenn der Standard die dafür nötigen Bausteine – Signaturen, Berechtigungen, Audit-Events – aus dem Bereich der Zukunftsüberlegungen in normativen Text überführt.

Was Sie jetzt tun sollten

Sie müssen heute nichts migrieren. Sie sollten aber vier Dinge vorbereiten:

1. Inventarisieren Sie Ihre MCP-Server. Welche Server laufen wo, wer hat sie eingerichtet, welche Systeme erreichen sie? Ohne diese Liste können Sie kein Paket schnüren – und ohne sie wissen Sie auch heute nicht, wie groß Ihre Angriffsfläche ist.
2. Definieren Sie Ownership pro Fähigkeit. Ein Plugin braucht einen fachlichen Verantwortlichen, nicht nur einen technischen Administrator. Klären Sie diese Zuordnung jetzt, solange es um zehn Bausteine geht und nicht um hundert.
3. Legen Sie Ihre Freigabekriterien fest, bevor der Standard sie liefert. Herkunft, Prüfung, Secret-Handhabung, Update-Pfad, Rückzugsweg. Die Spezifikation überlässt Ihnen diese Punkte ausdrücklich – nutzen Sie die Zeit, statt später eine offene Flanke zu schließen.
4. Behandeln Sie Command-Hooks als das, was sie sind. Ausführung fremden Codes auf Ihrem Server. Standardmäßig aus, im Einzelfall und nur für Pakete aus eigener Hand ein.

Fazit

Agent Plugins ist ein bewusst kleiner Standard mit großer Wirkung: Er macht aus verstreuten Konfigurationen einen benennbaren, versionierbaren, verteilbaren Baustein. Für Unternehmen, die KI über Einzelfälle hinaus einsetzen, ist das der Übergang von Bastelbetrieb zu Lifecycle-Management.

Gleichzeitig ist die Lücke ehrlich benannt: Vertrauen, Berechtigungen und Provenance regelt Version 1.0.0 nicht. Wer jetzt eine interne Governance für KI-Bausteine aufsetzt, wird vom Standard eingeholt statt überrollt – und kann öffentliche Pakete später kontrolliert zulassen, statt sie ungeprüft zu erben.

Unsere Empfehlung: Starten Sie mit dem MCP-Inventar und einer Handvoll intern verantworteter Pakete. Die technischen Details finden Sie in der Spezifikation unter agent-plugins.org. Wenn Sie die Governance dahinter mit uns durchdenken möchten – sprechen Sie uns an.