NCA Social Media
Aktualisiert:
Autor:
Roland Golla
Grüne isometrische Versandkiste mit Aufschrift Agent Plugins verteilt Pakete an Clients

Was sind Agent Plugins?

Agent Plugins ist ein offener, herstellerneutraler Paketstandard für Erweiterungen von KI Agenten. Ein Agent Plugin ist ein Ordner mit einer plugin.json im Wurzelverzeichnis, optionalen Agent Skills unter skills/ und einer optionalen mcp.json für MCP Server.

Die Version 1.0.0 des Standards erschien am 6. August 2026. Initiiert hat den Vorschlag Vercel, ausgearbeitet wurde er mit Vertretern von Amazon Web Services, Anysphere, GitHub, Microsoft und OpenAI. Das Technical Steering Committee besteht aus Core Maintainern dieser Firmen. Keine einzelne Roadmap bestimmt die Richtung.

Der Standard erfindet nichts neu. Er regelt nur, wo bereits existierende Bausteine liegen. Skills bleiben Skills, MCP bleibt MCP. Neu ist die gemeinsame Verpackung, damit dasselbe Paket in mehreren Clients geladen werden kann.

Inhalt

Agent Plugins mit NCA: Einordnung vom Experten

Wir bauen MCP Server selbst und betreiben sie produktiv. Unser eigenes Sulu CMS hängt über MCP an unserem Content Workflow, unsere Skills laufen in OpenCode gegen lokale Ollama Modelle auf eigenen Servern in Deutschland. Wer täglich damit arbeitet, sieht schnell, was ein Paketstandard löst und was er offen lässt.

Wir helfen Teams, Erweiterungen sauber zu strukturieren: MCP Middleware für Unternehmensdaten, Agentic AI Coding Guardrails für bestehende Projekte, Security Audits für KI Code, Self Hosted KI mit DSGVO Fokus und Onboarding ins Team. Der rote Faden ist immer derselbe: erst absichern, dann automatisieren.

Agent Plugins im Team einordnen

Finde das passende Angebot für dein Projekt

Anfrage-Konfiguration

Starten Sie Ihre Anfrage

Projektart
Infos
Nachricht

Eliminierung technischer Schulden mit PHPStan, Rector PHP und PHPUnit. Über 20 Jahre Praxiserfahrung in skalierbaren Backends.

CORE EXPERTISE

Gesetzliche Konformität & Inklusion. Optimierung von Performance und Conversion durch radikal nutzerzentriertes, universelles Design.

BFSG COMPLIANT

Skalierbare KI-Systeme mit echtem Code Ownership. CI/CD, Backup-Strategien und Infrastruktur, die mit deinem Team wächst.

ENTERPRISE READY

Das Problem: ein Skill, fünf Verpackungen

Bis zum Sommer 2026 hatte fast jeder Agent Client sein eigenes Plugin Format. Der Inhalt war oft identisch. Ein SKILL.md ist überall ein SKILL.md. Ein MCP Server ist überall derselbe Prozess. Unterschiedlich waren nur Metadaten, Ordnerpfade und die Form der MCP Konfiguration.

Die Folge kennt jedes Team, das Erweiterungen verteilt: dieselbe Sache fünfmal verpacken, fünfmal pflegen, fünfmal aus dem Tritt geraten. Genau diese Doppelarbeit ist der Grund für den Standard. Er zieht einen kleinen gemeinsamen Boden ein und lässt alles darüber den Clients.

Bewusst außen vor bleiben Installation, Verteilung, Marktplätze, Berechtigungen und die gesamte Oberfläche. Jeder Client entscheidet das selbst. Portabel ist das Paket, nicht das Erlebnis.

Aufbau: So sieht ein Agent Plugin aus

Ein Agent Plugin ist ein Verzeichnis mit festen Orten für seine Bestandteile. Die Pfade sind nicht konfigurierbar. Genau das macht die Erkennung für jeden Client vorhersagbar.

Code: 
          
my-plugin/
├── plugin.json
├── skills/
│   └── summarize/
│       ├── SKILL.md
│       ├── scripts/
│       └── references/
├── mcp.json
└── com.example.client/
    └── hooks/

Die plugin.json liegt immer im Wurzelverzeichnis. Pflicht sind genau zwei Felder: das kanonische Schema und der Name. Mehr braucht ein gültiges Manifest nicht.

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

Das Schema ist geschlossen. Erlaubt sind genau zehn Felder auf oberster Ebene: $schema, name, version, description, author, homepage, repository, license, keywords und extensions. Der Name akzeptiert Kleinbuchstaben, Ziffern, Bindestriche und Punkte. Erstes und letztes Zeichen müssen alphanumerisch sein, doppelte Bindestriche und doppelte Punkte sind verboten.

Skills und MCP Server werden nicht im Manifest aufgelistet. Der Client findet sie über die festen Orte: die direkten Unterordner von skills/ und die Datei mcp.json. Wer schon Skills pflegt, verschiebt sie einfach unter skills/ und ist fertig.

Was portabel ist und was beim Client bleibt

Bestandteil Ort im Paket Portabel in Version 1
Manifest plugin.json im Wurzelverzeichnis Ja, Pflicht
Agent Skills skills/[name]/SKILL.md Ja, optional
MCP Server mcp.json im Wurzelverzeichnis Ja, optional
Commands, Hooks, Subagents com.beispiel.client/ Nein, clientspezifisch

Welche Clients Agent Plugins laden

Zum Start nannte Vercel fünf Einträge: ChatGPT und Codex als gemeinsamen Eintrag, dazu Cursor, GitHub Copilot, Kiro und VS Code. Die offizielle Liste steht auf der Seite der Compatible Clients und wird laufend erweitert. Wer eine Packungsentscheidung trifft, schaut dort nach, statt einem Blogstand zu vertrauen.

Wichtig ist die Kleingedruckte im Konformitätsmodell: Clients dürfen portable Bestandteile schrittweise übernehmen. Ein Client muss mindestens einen Standardbestandteil unterstützen, nicht beide. Bei den Transporten reicht stdio oder Streamable HTTP. Der alte HTTP mit SSE Transport ist optional und gilt als veraltet.

Kompatibel heißt also nicht identisch. Ein Paket, das nur über SSE spricht, kann in einem konformen Client komplett leer ankommen. Wer veröffentlicht, testet in einem zweiten Client und dokumentiert, was tatsächlich geladen wurde.

Fehler im Paket schalten nicht alles ab. Nach der Prüfung des Manifests validiert der Client jeden Bestandteil einzeln. Ein kaputter Skill nimmt einen funktionierenden MCP Server nicht mit.

Agent Plugins und Claude Code Plugins: zwei Formate, ein Wort

Anthropic steht weder im Steering Committee noch auf der Liste der kompatiblen Clients. Claude Code Plugins bringen ihr eigenes Format mit: das Manifest liegt unter .claude-plugin/plugin.json, daneben stehen commands/, agents/, skills/, hooks/ und .mcp.json. Gleiches Wort, andere Struktur.

Die Naht ist schmaler, als sie klingt. Der teure Teil ist geteilt: die SKILL.md Dateien und der MCP Server selbst ändern sich nicht. Unterschiedlich ist nur der Umschlag. Wer heute Skills pflegt, schreibt bereits die portable Schicht.

Praktisch heißt das: Wer Claude Code und die Startclients gleichzeitig erreichen will, pflegt zwei Manifeste über einem gemeinsamen Inhalt. Der Claude Code Plugin Marketplace bleibt davon unberührt.

Die Lücke: Version 1 regelt keine Sicherheit

Das ist der Punkt, an dem Management aufhorchen sollte. Version 1.0.0 definiert kein Berechtigungsmodell, kein Sandboxing, keine Signaturprüfung und kein Konzept für Secrets. Alles davon steht als künftige Arbeit auf der Liste.

Der Standard sagt immerhin klar, was nicht ins Paket gehört: konfigurierte Header sind sichtbare Paketdaten und dürfen keine Zugangsdaten enthalten. Anmeldung, Tokenspeicherung und Autorisierung sind Sache des Clients. Dateien müssen innerhalb des Paketverzeichnisses aufgelöst werden, Symlinks nach draußen sind verboten.

Damit ist das Format portabel, das Vertrauen aber nicht. Ein Plugin, das ein Team installiert, bringt Anweisungen und Werkzeuge mit, die der Agent ausführt. Wer das ohne Review ausrollt, hat eine Lieferkette ohne Kontrolle. Genau hier setzen Guardrails an.

Unsere Empfehlung für Teams: interne Freigabe vor der Verteilung, Quelle und Skripte prüfen, Versionsstände im Git dokumentieren, Rollback vorbereiten. Das kostet wenig und verhindert viel.

Wann sich ein Plugin lohnt und wann nicht

Nicht jede Erweiterung braucht ein Paket. Die Faustregel ist einfach und spart viel Overhead:

  • Ein Skill ohne Werkzeuge bleibt ein Skill. Eine Datei, fertig.
  • Ein Server für einen Client bleibt eine schlichte MCP Konfiguration.
  • Ein Plugin lohnt sich, wenn Anweisungen und Werkzeuge zusammen ankommen müssen, und das an mehr als einer Stelle.

Ein gutes Beispiel ist ein Deployment Paket: Der Skill beschreibt, wie euer Release läuft, wie ihr die Systemgesundheit prüft und wie ihr sicher zurückrollt. Der MCP Server verbindet den Agenten mit eurer Deployment Plattform. Anweisung und Werkzeug gehören zusammen, also in ein Paket.

Was immer gelten soll, gehört weiterhin in die Projektanweisung. Was nur für eine Aufgabe zählt, wird ein Skill. Und erst wenn mehrere zusammengehörige Erweiterungen verteilt werden sollen, bündelt sie ein Plugin. Diese Reihenfolge hält Kontext klein und Tokenkosten im Rahmen.

A reusable component should not need to be repackaged for every client.

Jonathan Hefner, Autor der Agent Plugins Ankündigung bei Vercel – via Vercel Blog

Drei Muster aus der Praxis mit Agent Erweiterungen

Erstens: Inhalt vom Umschlag trennen. Wer SKILL.md Dateien sauber schreibt, hat den portablen Teil schon fertig. Die Verpackung ist danach eine kleine Datei, kein Projekt. Wie ein ganzes Skill Ökosystem aussieht, zeigt der Eintrag zu Everything Claude Code.

Zweitens: MCP Antworten schlank halten. Ein Paket kann noch so sauber gebaut sein, wenn der Server riesige JSON Blöcke zurückgibt, verbrennt der Agent Kontext. Wer eigene Server baut, denkt über Antwortformate nach, bevor er über Distribution nachdenkt. Der GitHub MCP Server, glab als MCP Server und der Symfony AI Mate sind gute Referenzen für sauberen Zuschnitt.

Drittens: erst absichern, dann automatisieren. Bevor Agenten Werkzeuge bekommen, brauchen sie Netz und doppelten Boden. Bei uns heißt das PHPUnit und statische Analyse im Backend, dazu Cypress für die Oberfläche. Wer diese Reihenfolge dreht, räumt später teuer auf.

Verwandte Einträge im Glossar: Agent Looping, OpenSpec, Mistral Connectors, OKF Open Knowledge Format und Web MCP.

CYPRESS.IO Ambassador und IT Consultant für QA Engenieering und Qualität in PHP Projekten.

NCA Vibe Coding Consulting

Roland Golla ist Entwickler aus Leidenschaft – seit über 20 Jahren. Er hat hunderte Projekte begleitet, von Legacy-Refactoring bis KI-Integration. Bei Vibe Coding verbindet er das Beste aus beiden Welten: Die Geschwindigkeit von KI-generiertem Code mit der Qualität professioneller Softwareentwicklung. Kein Bullshit, keine Agentur-Floskeln – direkte Hilfe von jemandem, der selbst täglich im Code steckt.

E-Mail Kontakt

Häufige Fragen zu Agent Plugins

Die wichtigsten Fragen zum Paketstandard, zum Aufbau, zur Kompatibilität und zur Abgrenzung gegen bestehende Formate.

Was sind Agent Plugins 2026?

Agent Plugins ist ein offener, herstellerneutraler Paketstandard für Erweiterungen von KI Agenten. Version 1.0.0 erschien am 6. August 2026. Ein Plugin ist ein Ordner mit einer plugin.json im Wurzelverzeichnis, optionalen Agent Skills unter skills und einer optionalen mcp.json für MCP Server. Kompatible Clients finden und laden diese Bestandteile nach denselben Regeln.

Wer steht 2026 hinter dem Standard?

Vercel hat den Vorschlag initiiert. Ausgearbeitet wurde Version 1.0.0 gemeinsam mit Vertretern von Amazon Web Services, Anysphere, GitHub, Microsoft und OpenAI. Das initiale Technical Steering Committee besteht aus Core Maintainern von AWS, Cursor, Microsoft, OpenAI und Vercel. Das Projekt ist offen lizenziert, Vorschläge und technische Entscheidungen laufen öffentlich.

Welche Clients unterstützen Agent Plugins 2026?

Zum Start nannte Vercel fünf Einträge: ChatGPT und Codex gemeinsam, dazu Cursor, GitHub Copilot, Kiro und VS Code. Die Liste wächst und steht auf der offiziellen Seite der Compatible Clients. Weil Clients Bestandteile schrittweise übernehmen dürfen, lohnt vor jeder Packungsentscheidung ein Blick auf den aktuellen Stand statt auf einen Blogeintrag.

Ersetzen Agent Plugins 2026 das Model Context Protocol?

Nein. MCP bleibt das Protokoll, über das Agenten Werkzeuge und Daten ansprechen. Agent Plugins legt nur fest, wo die Konfiguration dieser Server liegt, nämlich in einer mcp.json im Wurzelverzeichnis des Pakets. Der Servercode selbst ändert sich nicht. Verpackt wird die Konfiguration, nicht das Protokoll.

Was kostet der Einstieg 2026 für ein Team?

Der Standard selbst ist offen und kostenfrei. Der Aufwand liegt im Team: bestehende Skills sortieren, Manifest schreiben, in einem zweiten Client testen, Review und Freigabe klären. Wer schon saubere SKILL.md Dateien pflegt, hat den größten Teil erledigt. NCA schätzt den Aufwand im kostenlosen Kennenlernen und rechnet minutengenau ab.

Welche Felder sind in der plugin.json erlaubt?

Das Schema ist geschlossen und kennt genau zehn Felder auf oberster Ebene: schema, name, version, description, author, homepage, repository, license, keywords und extensions. Pflicht sind nur die ersten beiden. Unbekannte Felder muss ein Client melden und ignorieren, das Plugin wird trotzdem geladen, wenn das Manifest sonst gültig ist.

Welche Regeln gelten für den Namen eines Plugins?

Der Name ist ein bis 64 Zeichen lang und erlaubt Kleinbuchstaben, Ziffern, Bindestriche und Punkte. Erstes und letztes Zeichen müssen alphanumerisch sein. Doppelte Bindestriche und doppelte Punkte sind verboten. Ungültig sind also Namen mit Großbuchstaben, führendem Bindestrich oder aufeinanderfolgenden Sonderzeichen.

Sind Commands, Hooks und Subagents portabel?

Nein. Version 1 kennt nur zwei portable Bestandteile: Agent Skills und MCP Server. Commands, Hooks und Subagents leben in einem clientspezifischen Namensraum nach dem Muster einer umgekehrten Domain. Fremde Clients ignorieren diesen Ordner vollständig. Das Plugin installiert sich dort trotzdem, kommt aber mit weniger Einstiegspunkten an.

Funktioniert ein Agent Plugin in Claude Code?

Nicht ohne Anpassung. Claude Code bringt ein eigenes Format mit, dessen Manifest unter .claude-plugin/plugin.json liegt. Anthropic steht weder im Steering Committee noch auf der Liste der kompatiblen Clients. Der Inhalt ist aber geteilt: SKILL.md Dateien und der MCP Server bleiben gleich. Wer beide Welten erreichen will, pflegt zwei Manifeste.

Wie sicher sind Agent Plugins?

Version 1.0.0 definiert kein Berechtigungsmodell, kein Sandboxing, keine Signaturprüfung und kein Konzept für Secrets. Das steht als künftige Arbeit auf der Liste. Der Standard verbietet immerhin Zugangsdaten in konfigurierten Headern und verlangt, dass alle Pfade innerhalb des Pakets aufgelöst werden. Vertrauen bleibt Aufgabe des Teams und des Clients.

Welche MCP Transporte unterstützt der Standard?

Die mcp.json beschreibt lokale Server über stdio, entfernte Server über Streamable HTTP und den alten HTTP mit SSE Transport. Ein konformer Client muss mindestens stdio oder Streamable HTTP unterstützen und sollte beide können. SSE ist optional und gilt als veraltet. Wer nur SSE anbietet, riskiert ein Paket, das nirgends lädt.

Wann lohnt sich ein Plugin statt eines einzelnen Skills?

Ein Skill ohne Werkzeuge bleibt ein Skill. Ein Server für einen einzigen Client bleibt eine schlichte MCP Konfiguration. Ein Plugin lohnt sich erst, wenn Anweisungen und Werkzeuge zusammen ankommen müssen, und das an mehr als einer Stelle. Typisches Beispiel ist ein Deployment Paket aus Ablaufbeschreibung und Anbindung an die Plattform.

Was passiert, wenn ein Bestandteil fehlerhaft ist?

Der Client prüft zuerst das Manifest und validiert danach jeden Bestandteil einzeln. Ein ungültiger Skill schaltet einen funktionierenden MCP Server nicht ab. Diese Fehlerisolation ist bewusst so gebaut. Ein häufiger stiller Fehler bleibt trotzdem: ein zu tief verschachtelter Ordner wird nie gefunden, und der Client meldet nichts.

Muss ich bestehende Skills umschreiben?

In der Regel nicht. Wer Skills nach der Agent Skills Spezifikation pflegt, legt sie einfach unter skills und dem jeweiligen Namen als SKILL.md ab. Auch der Code eines MCP Servers bleibt unverändert. Anpassen muss man höchstens die clientspezifische Konfiguration, weil Agent Plugins ein eigenes geschlossenes Schema für die mcp.json nutzt.