Agent Skills vs. MCP: Die richtige Schnittstelle wählen
Agent Skills und MCP erklärt: Vergleichen Sie Anweisungen, Tool-Verbindungen, Sicherheitsgrenzen, Versionierung und den sinnvollen gemeinsamen Einsatz für zuverlässige AI Agents.
Die Entscheidung Agent Skills vs. MCP wird häufig als Wettbewerb zwischen zwei Möglichkeiten dargestellt, einer AI „Tools zu geben“. Diese Darstellung greift zu kurz. Ein Skill und ein Model Context Protocol Server lösen unterschiedliche Ebenen des Problems: Der eine vermittelt einem Agent, wie er in einer Domäne arbeitet, während der andere Fähigkeiten und Kontext über eine standardisierte Verbindung bereitstellt.
Dockup verwendet eine SKILL.md, weil die primäre Schnittstelle ein vorhandenes Command-Line-Tool ist. Der Skill zeigt Claude Code und Codex, wie sie diese CLI sicher verwenden: immer JSON anfordern, sich nicht interaktiv authentifizieren, exakte Ziele auflösen, auf abschließende Deployment-Status warten und vor destruktiven Aktionen stoppen.
Was ist ein Agent Skill und warum ist SKILL.md wichtig?
Ein Agent Skill ist ein Verzeichnis mit Betriebsanweisungen und ergänzenden Referenzen, das ein Agent laden kann, wenn eine Aufgabe zum Zweck des Skills passt. SKILL.md ist der Einstiegspunkt: Das Frontmatter beschreibt die Fähigkeit, der Inhalt erklärt Workflows, Einschränkungen, Beispiele und Entscheidungsregeln.
Ein Skill ist besonders nützlich, wenn die ausführbare Schnittstelle bereits existiert. Der Agent benötigt keinen neuen Protocol Adapter, nur um eine gut konzipierte CLI auszuführen. Er benötigt präzises Wissen über:
- Welche Befehle maßgeblich sind.
- Welche Flags für den Einsatz durch Maschinen erforderlich sind.
- Wie die Authentifizierung in einer Sandbox funktioniert.
- Welche Ausgaben den Erfolg belegen.
- Welche Aktionen einen Menschen erfordern.
- Wo Secrets auftauchen können.
- Wie sich häufige Fehler diagnostizieren lassen.
Die Installation von Dockup ist bewusst einfach:
npm install -g dockup-cli
dockup skill install
dockup skill status --json
Eine kanonische Kopie wird nach ~/.agents/skills/dockup/ geschrieben und sowohl mit Claude Code als auch mit Codex verknüpft. Der Skill ist im CLI-Paket enthalten, und dockup update aktualisiert beide gemeinsam. Diese Packaging-Entscheidung verhindert einen häufigen Fehler: Anweisungen, die Befehle beschreiben, über die das installierte Binary nicht verfügt.
Der Skill ist nicht die Deployment-Engine. Die CLI führt Aktionen aus, gibt JSON aus und liefert Exit-Codes zurück. Der Skill ist das Betriebshandbuch, an dem sich der Agent orientiert.
Was ist das Model Context Protocol?
Das Model Context Protocol, kurz MCP, ist ein offenes Protocol, das eine AI-Anwendung über eine Client-Server-Architektur mit externen Tools, Ressourcen und Prompts verbindet. Ein MCP Server kann aufrufbare Tools, lesbare Ressourcen und wiederverwendbare Prompts bereitstellen. Ein MCP Client innerhalb des Agent-Hosts erkennt und ruft diese Fähigkeiten auf.
MCP ist wertvoll, wenn ein System eine dauerhafte Protocol-Grenze statt einer lokalen Shell-Ausführung benötigt. Beispiele:
- Eine entfernte SaaS-API, die sorgfältig typisierte Operationen bereitstellen soll.
- Eine Datenquelle, die durchsuchbare Ressourcen anbietet.
- Eine Desktop-Anwendung, die Tool Discovery ohne Auslieferung einer CLI benötigt.
- Ein zentraler Service, der von vielen Agent-Hosts und Betriebssystemen verwendet wird.
- Eine Integration, bei der der Server Credentials und Richtlinien vermitteln muss.
Der Server kontrolliert die Implementierung hinter jedem Tool. Der Agent-Host sieht den deklarierten Namen, die Beschreibung, das Input-Schema und die Ausgabe. Transport, Lifecycle und Autorisierung hängen vom gewählten MCP-Setup ab.
MCP liefert nicht automatisch Domänenwissen für Entscheidungen. Ein Server kann delete_service bereitstellen, aber der Agent benötigt weiterhin Richtlinien dafür, wann eine Löschung angemessen ist. Umgekehrt kann ein Skill einen Workflow erklären, aber keine Fähigkeiten erzeugen, die in der zugrunde liegenden CLI oder API nicht vorhanden sind.
Wie unterscheiden sich Agent Skills und MCP in der Praxis?
Der klarste Vergleich erfolgt nach Verantwortungsbereich:
| Dimension | Agent Skill / SKILL.md | MCP Server |
|---|---|---|
| Hauptaufgabe | Workflows und Einschränkungen vermitteln | Tools, Ressourcen und Prompts bereitstellen |
| Ausführung | Verwendet vorhandene CLIs, Dateien, APIs oder Apps | Server implementiert aufrufbare Fähigkeiten |
| Discovery | Agent lädt passende Skill-Anweisungen | Client erkennt die Fähigkeiten des Servers |
| Bereitstellung | Häufig ein mit einem Paket installiertes Verzeichnis | Lokaler oder entfernter Server-Prozess |
| Versionsrisiko | Anweisungen können vom Tool abweichen | Server-Schema kann vom Backend-Verhalten abweichen |
| Geeignet für | Vorhandene Schnittstelle benötigt fachkundige Bedienungshinweise | Fähigkeit benötigt eine standardisierte Protocol-Grenze |
| Sicherheitsfokus | Verhaltensregeln und Befehlssicherheit | Verbindung, Server-Vertrauen, Scopes und Tool-Autorisierung |
| Offline/lokal | Hervorragend mit lokalen CLIs | Mit einem lokalen MCP Server möglich |
| Wiederverwendung über mehrere Clients | Skill für jeden Host kopieren oder paketieren | Ein Server kann mehrere kompatible Clients unterstützen |
Keine der beiden Spalten ist grundsätzlich „agentischer“. Zuverlässigkeit entsteht, wenn die Schnittstelle zum System passt.
Für Dockup verfügt die CLI bereits über 135 Befehle, strukturiertes JSON, echte Exit-Codes, ein standardmäßiges Deployment-Timeout von 900 Sekunden, Secret Masking und Confirmation Gates. Jedes Kommando zusätzlich in einen weiteren lokalen Server einzubetten, würde eine Übersetzungsschicht hinzufügen, ohne die zugrunde liegende Deployment-Wahrheit zu verändern. Ein Skill passt hier direkt, weil er dem Agent zeigt, wie er den bereits vorhandenen ausführbaren Vertrag verwendet.
Eine entfernte Plattform ohne CLI könnte zum gegenteiligen Schluss kommen. Ein MCP Server kann die fehlende typisierte Tool-Schnittstelle bereitstellen und API-Credentials außerhalb der Shell-Umgebung des Agents halten.
Wann sollten Sie einen Skill, MCP oder beides verwenden?
Verwenden Sie ausschließlich einen Skill, wenn alle folgenden Punkte zutreffen:
- Eine ausgereifte CLI oder lokale Anwendung stellt die benötigte Fähigkeit bereits bereit.
- Der Agent-Host darf sie ausführen.
- Maschinenlesbare Ausgaben und Exit-Semantik sind ausreichend.
- Die zentrale Lücke liegt im Prozesswissen, nicht bei der Connectivity.
- Das Packaging kann die Übereinstimmung der Anweisungen mit der ausführbaren Datei sicherstellen.
Verwenden Sie ausschließlich MCP, wenn der Agent eine Protocol-native Verbindung benötigt und der Server selbst ausreichend Kontext für einen sicheren Betrieb bereitstellen kann. Das ist häufig bei leseintensivem Datenzugriff, entfernten Services und Anwendungen der Fall, die eine stabile Tool-Schnittstelle für mehrere Clients anbieten möchten.
Verwenden Sie beides, wenn die Protocol-Tools ein ausführlicheres Betriebshandbuch benötigen. Ein MCP Server kann sichere, typisierte Primitives bereitstellen, während ein Skill den mehrstufigen Business-Workflow, Eskalationsregeln und Validierungskriterien erklärt. Der Skill kann dem Agent sagen, wann und warum er die einzelnen MCP-Tools aufrufen soll.
Eine kombinierte Architektur kann so aussehen:
User request
↓
Skill: workflow, policy, validation rules
↓
MCP client: discovers typed capabilities
↓
MCP server: authenticates and executes
↓
External system
Eine CLI-zentrierte Architektur ist einfacher:
User request
↓
Skill: workflow, policy, validation rules
↓
CLI: JSON output + exit code + wait semantics
↓
Platform API
Komplexität sollte durch eine verbesserte Grenze gerechtfertigt sein. MCP nur hinzuzufügen, weil es gerade populär ist, kann einen weiteren Prozess schaffen, der bereitgestellt, authentifiziert, überwacht und versioniert werden muss.
Entscheidungsbeispiele
| Situation | Besserer Ausgangspunkt | Grund |
|---|---|---|
| Lokale Deployment-CLI mit JSON-Ausgabe | Skill | Connectivity ist bereits vorhanden |
| Unternehmensinterne Knowledge Base mit strukturierten Ressourcen | MCP | Resource Discovery ist zentral |
| Datenbank-Administrations-API ohne CLI | MCP | Typisierte Remote-Operationen sind nützlich |
| Komplexes Release-Runbook über vorhandene Tools hinweg | Skill | Der Tool-übergreifende Prozess ist der Hauptbedarf |
| Regulierte Remote-Operationen plus detaillierte Richtlinien | Beide | Der Server erzwingt den Scope, der Skill steuert das Verhalten |
| Einmalige persönliche Automation | Skill oder direkte CLI | Geringster operativer Aufwand |
Die richtige Antwort kann sich mit der Zeit ändern. Ein Team kann mit einem Skill rund um eine CLI beginnen und später einen MCP Server ergänzen, wenn der Zugriff von mehreren Clients oder eine zentrale Vermittlung von Credentials wichtig wird.
Wie unterscheiden sich Sicherheits- und Vertrauensgrenzen?
Skills sind Anweisungen. Ihr Vertrauensrisiko ähnelt daher dem von Code-Dokumentation mit operativem Einfluss. Ein bösartiger oder nachlässig erstellter Skill kann einen Agent anweisen, Secrets offenzulegen, Schutzmechanismen zu deaktivieren oder destruktive Befehle auszuführen. Prüfen Sie das vollständige Verzeichnis, nicht nur den Titel.
Fragen bei der Prüfung eines Skills:
- Wer hat ihn veröffentlicht?
- Führt er Befehle außerhalb seines angegebenen Zwecks aus?
- Weist er den Agent an, Tokens oder Credentials auszugeben?
- Umgeht er Confirmations?
- Leiten sich die Befehlsbeispiele aus der installierten Version ab?
- Können Updates den Skill ohne Prüfung ersetzen?
- Definiert der Skill einen klar begrenzten Prozess zur Zielermittlung?
MCP führt eine Vertrauensgrenze für den Server ein. Der Client muss wissen, mit welchem Server er sich verbindet, welche Tools dieser bereitstellt, welche Daten die Maschine verlassen und wie die Autorisierung begrenzt ist. Ein Server kann sein Verhalten hinter einem stabilen Tool-Namen ändern. Daher sind Herkunft und Server-Versionierung wichtig.
Fragen bei der Prüfung eines MCP Setups:
- Ist der Server lokal oder remote?
- Wer betreibt ihn?
- Wie werden Credentials gespeichert und rotiert?
- Welche Tool-Aufrufe können Daten ändern oder löschen?
- Werden Tool-Eingaben serverseitig validiert?
- Werden Ausgaben als nicht vertrauenswürdiger Inhalt behandelt?
- Ist jeder Aufruf auditierbar?
- Kann der Client die verfügbaren Tools einschränken?
Der Agent-Host sollte „über MCP entdeckt“ nicht mit „sicher“ gleichsetzen. Eine standardisierte Protocol verbessert die Interoperabilität, nicht automatisch die Vertrauenswürdigkeit jedes Servers.
Der Dockup Skill enthält mehrere Sicherheitsregeln: DOCKUP_TOKEN statt eines interaktiven Logins verwenden, Credentials niemals ausgeben, Ziele mit dockup services --json ermitteln, --wait verwenden und bei needs_confirm stoppen. Die CLI unterstützt diese Anweisungen, indem sie Secrets maskiert und destruktive Aktionen ohne explizite Freigabe verweigert. Dieses Defense-in-Depth-Modell wird in Production Guardrails für AI Agents beschrieben.
Wie sollten Versionierung und Fehlerbehandlung funktionieren?
Versionsdrift ist bei beiden Ansätzen möglich, tritt aber unterschiedlich in Erscheinung.
Ein Skill kann veralten, wenn sich der dokumentierte Befehl ändert. Die stärkste Gegenmaßnahme besteht darin, den Skill gemeinsam mit der ausführbaren Datei zu paketieren und beides über einen gemeinsamen Release-Prozess zu aktualisieren. Dockup folgt diesem Modell. Der Agent kann den installierten Skill prüfen:
dockup skill status --json
Ein Update aktualisiert die CLI und den enthaltenen Skill gemeinsam:
dockup update
Ein MCP Client kann die aktuellen Tool-Schemas des Servers erkennen, aber Schema-Kompatibilität garantiert keine semantische Kompatibilität. Ein Tool kann dieselben Eingaben beibehalten und dennoch Autorisierung, Seiteneffekte, Latenz oder die Interpretation der Ausgabe ändern. Der Server sollte Versionen veröffentlichen, nach Möglichkeit Abwärtskompatibilität gewährleisten und strukturierte Fehler zurückgeben.
Auch die Fehlerbehandlung unterscheidet sich. Eine CLI bietet Exit-Codes ganz natürlich als Prozesssignal. Ein MCP-Tool-Aufruf benötigt ein ebenso eindeutiges Ergebnis auf Anwendungsebene. In beiden Fällen darf der Agent Erfolg nicht aus einer Bestätigung auf Transportebene ableiten.
Eine nützliche Checkliste für Zuverlässigkeit:
| Anforderung | Implementierung mit Skill + CLI | MCP-Implementierung |
|---|---|---|
| Ermittlung von Fähigkeiten | CLI-Schema | Tool-Liste des Servers |
| Strukturierte Ausgabe | JSON/NDJSON | Typisiertes Tool-Ergebnis |
| Fehlersignal | Exit-Code ungleich null + Code | Explizites Fehlerergebnis |
| Lang andauernde Operation | --wait / dokumentierter Stream | Progress- oder Completion-Protocol |
| Schutz von Secrets | Maskierung und sorgfältiger Umgang mit stderr | Serverseitige Redaction |
| Freigabe destruktiver Aktionen | CLI Confirmation Gate | Server-Richtlinie oder Client-Bestätigung |
| Audit | Plattform-Audit-Log | Server- und Backend-Audit-Logs |
| Versionsprüfung | Skill-/Binary-Status | Server-Metadaten und Schemas |
Die Schnittstelle sollte eine fehlerhafte Erfolgsmeldung schwieriger machen als eine korrekte.
Welche Architektur sollte ein Production-Team wählen?
Benennen Sie zunächst die tatsächliche Lücke.
Wählen Sie eine Skill-first-Architektur, wenn das Team einer CLI bereits vertraut und sie betreibt. Investieren Sie in deren Machine Contract: JSON, echte Exit-Codes, stabile Fehlercodes, versionskonforme Anweisungen und Confirmations. Paketieren Sie anschließend den Skill mit dem Tool. Das ist der kürzeste Weg für Claude Code Deployment und Codex Deployment über Dockup.
Wählen Sie MCP-first, wenn die Fähigkeit von Natur aus remote, ressourcenorientiert oder für viele Clients gemeinsam nutzbar ist. Behandeln Sie den Server als Production-Software: authentifizieren Sie ihn, begrenzen Sie seine Scopes, überwachen Sie ihn und prüfen Sie jede Mutation.
Wählen Sie beides, wenn Richtlinien und Connectivity unabhängig voneinander komplex sind. Halten Sie die Verantwortlichkeiten klar. Der Skill sollte die Server-Implementierung nicht duplizieren, und die Server-Beschreibung sollte nicht zu einem umfangreichen Betriebshandbuch werden.
Ein praktischer Evaluierungs-Workshop
Führen Sie einen kleinen Proof mit einer Leseoperation, einem reversiblen Schreibvorgang, einer lang andauernden Operation und einer destruktiven Operation durch, die blockiert werden muss. Bewerten Sie jedes Design anhand folgender Kriterien:
- Wie der Agent die Operation entdeckt.
- Wie Credentials bereitgestellt werden.
- Wie der Erfolg nachgewiesen wird.
- Wie Fehler kategorisiert werden.
- Wie ein Mensch riskante Aktionen freigibt.
- Wie Logs und Audit-Nachweise abgerufen werden.
- Wie Versionen konsistent bleiben.
- Wie sich die Integration sauber entfernen lässt.
Entscheiden Sie nicht allein anhand eines Diagramms. Beobachten Sie die Fehlerpfade. Ein Design, das auf dem Happy Path elegant aussieht, kann unklar werden, wenn ein Deployment ein Timeout erreicht, ein Server die Verbindung verliert oder eine Anweisungsdatei einen Release zurückliegt.
Die Dockup CLI-Referenz liefert ein konkretes Beispiel für einen von einem Skill unterstützten CLI-Vertrag. Der umfassendere Artikel zu AI-gestützter Entwicklung erklärt, warum diese Schnittstellen wichtiger werden, während Agents zunehmend mehr Teile des Development Loops übernehmen.
Berücksichtigen Sie die betriebliche Verantwortung
Der Owner der Integration ist ebenso wichtig wie ihre Architektur. Ein Skill rund um eine CLI übernimmt in der Regel deren Installations-, Release- und Support-Prozess. Das Team, das das Binary veröffentlicht, kann die zugehörigen Anweisungen ausliefern und beides gemeinsam testen.
Ein MCP Server schafft eine separate Production-Komponente. Jemand muss Hosting, Zertifikate oder den Start des lokalen Prozesses, Authentifizierung, Monitoring, Incident Response, Schema-Kompatibilität und Dependency-Updates verantworten. Diese Investition kann sinnvoll sein, wenn der Server eine wichtige gemeinsame Grenze bildet. Sie ist unnötiger Overhead, wenn er lediglich lokale Aufrufe an eine bereits ausreichende ausführbare Datei weiterleitet.
Halten Sie während der Evaluierung fest, wer für welche Ebene verantwortlich ist:
| Ebene | Skill-first-Owner | MCP-first-Owner |
|---|---|---|
| Domänenanweisungen | Skill-Publisher | Client-Prompt oder begleitender Skill |
| Verhalten der ausführbaren Datei | CLI-Publisher | MCP-Server-Team |
| Umgang mit Credentials | CLI und Runtime-Umgebung | Server und Client-Verbindung |
| Verfügbarkeit | Lokale ausführbare Datei und Plattform-API | Server-Prozess, Transport und Backend |
| Schema-Kompatibilität | CLI-Release-Prozess | MCP-Server-Release-Prozess |
| Incident-Nachweise | CLI-Ausgabe und Plattform-Audit | Client-Logs, Server-Logs und Backend-Audit |
Diese Übersicht zur Verantwortlichkeit klärt die Agent-Skills-vs.-MCP-Debatte oft besser als eine Feature-Checkliste.
Bewerten Sie Latenz und Fehlerflächen
Ein lokaler Aufruf über Skill und CLI hat einen kurzen Pfad: Agent-Host, Prozess, Plattform-API. Ein MCP-Pfad kann Server-Start, Transport-Aushandlung, Remote-Routing und eine weitere Authentifizierungsebene hinzufügen. Das ist nicht grundsätzlich schlecht, aber jede Ergänzung schafft eine eigene Fehlerfläche.
Testen Sie Verbindungsabbrüche, abgelaufene Credentials, fehlerhafte Eingaben, teilweise abgeschlossene lang andauernde Operationen und Server-Upgrades. Der Agent muss erkennen können, ob der Fehler im Host, in der Protocol-Verbindung, im Server oder auf der externen Plattform aufgetreten ist. Ein allgemeines Ergebnis wie „Tool fehlgeschlagen“ reicht für Production-Arbeit nicht aus.
Bei langen Deployments muss die Schnittstelle die Semantik des finalen Status bewahren. Unabhängig davon, ob es sich um eine CLI-Operation mit --wait oder ein MCP-Tool mit Progress handelt: Der Agent darf eine Bestätigung nicht in einen Erfolg umdeuten. Die Entscheidung Agent Skills vs. MCP hebt diese Anforderung nicht auf.
Planen Sie Portabilität, ohne die Wahrheit zu opfern
MCP kann die Portabilität zwischen kompatiblen Clients verbessern, weil derselbe Server Tools über ein gemeinsames Protocol anbietet. Auch Skills können portabel sein, wenn mehrere Agents dasselbe Verzeichnis und dieselben SKILL.md-Konventionen unterstützen, wie Claude Code und Codex beim Installationsmodell von Dockup.
Portabilität ist nur dann nützlich, wenn die Semantik präzise bleibt. Ein Tool namens deploy muss definieren, ob es bei der Einreihung oder erst bei einem gesunden Status zurückkehrt. Eine Skill-Anweisung wie „deploy and verify“ muss auf einen Befehl verweisen, der diesen Nachweis tatsächlich liefern kann.
Das stärkste Design hält die Domänenwahrheit nah an der ausführbaren Ebene und nutzt die höhere Ebene, um die Absicht zu erklären. Im Vergleich Agent Skills vs. MCP kann weder ein standardisiertes Protocol noch eine gut geschriebene Anweisungsdatei ein mehrdeutiges Backend-Verhalten kompensieren.
Bringen Sie den Workflow in Production
Verwenden Sie die kleinste Architektur, die eine vertrauenswürdige Grenze schafft. Installieren Sie bei Dockup den paketierten Skill und lassen Sie die CLI die ausführbare Quelle der Deployment-Wahrheit bleiben.
npm install -g dockup-cli
dockup skill install
Der erste Befehl installiert die CLI. Der zweite installiert den passenden Dockup Skill für Claude Code und Codex. Starten Sie kostenlos auf app.dockup.ai.
FAQ
Sind Agent Skills und MCP dasselbe?
Nein. Ein Skill stellt in erster Linie Anweisungen und Betriebswissen bereit. MCP bietet ein Protocol, über das Tools, Ressourcen und Prompts über eine Client-Server-Verbindung bereitgestellt werden.
Führt eine SKILL.md-Datei selbst Befehle aus?
Nein. Sie erklärt dem Agent, wie er zugrunde liegende Fähigkeiten wie eine CLI, Dateien, APIs oder MCP-Tools verwendet. Die ausführbare Schnittstelle führt die Aktion aus.
Wann ist ein Skill besser als MCP?
Ein Skill ist häufig die einfachere Wahl, wenn eine ausgereifte lokale CLI bereits sichere, maschinenlesbare Operationen bereitstellt und hauptsächlich Prozesswissen fehlt.
Kann ein Agent einen Skill und MCP gemeinsam verwenden?
Ja. Ein Skill kann einen mehrstufigen Workflow und Richtlinien beschreiben, während ein MCP Server die typisierten Tools und Ressourcen bereitstellt, die dieser Workflow verwendet.
Warum liefert Dockup seinen Skill im CLI-Paket aus?
Durch die gemeinsame Paketierung kann dockup update die ausführbare Datei und ihre Anweisungen in einem Schritt aktualisieren. Dadurch sinkt das Risiko, dass der Skill eine andere Befehlsversion beschreibt.