MCP oder Skills: David Mohl plädiert für klare Rollenverteilung

Anthropic pusht derzeit Skills als neue Form der Erweiterung für Claude Code. Gleichzeitig hat sich MCP (Model Context Protocol) in den letzten Monaten als Cross-Plattform-Standard für Agent-Integrationen etabliert. David Mohl hat in einem vielbeachteten Blogpost beide Mechanismen gegeneinander gestellt und kommt zu einem deutlichen Ergebnis: Für die Anbindung echter Services bleibt MCP die bessere Wahl. Skills lösen ein anderes Problem -- und wer beides verwechselt, baut sich unnötige Komplexität in den Agent-Stack.

Was MCP strukturell besser macht

Mohls Hauptargument ist nicht ideologisch, sondern operativ. Remote-MCP-Server sind zero-install: Es gibt keine lokale Binärdatei, kein NPM-Paket, keinen Pfad, der auf drei Rechnern gepflegt werden will. Der Server läuft zentral beim Anbieter und aktualisiert sich für alle Clients gleichzeitig. Neue Tools, gefixte Bugs, veränderte API-Semantik -- der Nutzer merkt davon idealerweise nichts.

Damit verbunden ist die Authentifizierung. Moderne Remote-MCP-Server setzen auf OAuth. Der Nutzer klickt einmal durch den Consent-Flow, der Token landet sicher beim MCP-Client, und das Thema ist erledigt. Kein manuelles Token-Management, keine .env-Datei, kein Rotieren per Hand. Gerade für Services wie Google Calendar, GitHub oder Notion ist das der praktische Unterschied zwischen "funktioniert" und "funktioniert eine Woche lang, dann wieder nicht".

Der dritte Punkt ist Portabilität. Ein Remote-MCP-Server läuft überall, wo ein MCP-Client existiert: auf dem Mac, im Web-Claude, auf dem Phone, in fremden Agent-Frameworks. Skills, die auf CLI-Tools aufsetzen, sind an die Umgebung gebunden, in der diese CLIs installiert sind -- in der Praxis also an lokale Entwickler-Setups. Im Web-Claude, in ChatGPT oder in Perplexity ist davon nichts zu sehen.

Schließlich zwei Aspekte, die im Tagesgeschäft unterschätzt werden: Sandboxing und Tool Discovery. Ein MCP-Server exponiert ein kontrolliertes Interface statt roher Execution-Power -- der Agent kann nur die Tools aufrufen, die der Server anbietet, und nichts darüber hinaus. Und Clients können dynamisch nur die Tools laden, die gerade gebraucht werden. Das schont das Context Window, während Skills oft ihre komplette Dokumentation in den Kontext schieben müssen.

Wo Skills strukturell schwächeln

Mohls Kritik an Skills ist konkret und lässt sich in vier Punkten zusammenfassen:

• CLI-Abhängigkeit. Die meisten real existierenden Skills setzen auf dedizierte CLI-Tools auf. Das funktioniert im Terminal, aber nicht im Browser und nicht auf dem Phone. Wer Skills als plattformübergreifenden Erweiterungsmechanismus denkt, kollidiert sofort mit dieser Realität.
• Deployment-Komplexität. Binaries, NPM-Pakete, Installationsskripte. Jede Umgebung ist anders, jede Maschine ein eigener kleiner Wartungsfall. Was bei einem einzelnen Entwickler noch überschaubar wirkt, wird im Team oder über mehrere Geräte hinweg schnell fragil.
• Secret-Management-Chaos. API-Tokens landen in plaintext .env-Dateien und gehen in ephemeren Umgebungen verloren. Es gibt keinen einheitlichen, sicheren Mechanismus -- nur Konventionen, die jeder anders auslegt.
• Fragmentiertes Ökosystem. Skill-Verwaltung unterscheidet sich zwischen Plattformen, YAML-Parser verhalten sich zwischen Tools inkonsistent, und Portabilität ist eher Wunschdenken als Eigenschaft. Dazu kommt der Context-Bloat: Statt sauberer Function Signatures landet die ganze Skill-Doku im Prompt.

Drei konkrete Beispiele

Mohl macht seine Argumentation an Services fest, bei denen die Unterscheidung praktisch spürbar ist:

• Google Calendar. Ein OAuth-backed Remote-MCP schlägt die Kombination aus gcal-CLI und manuellem Auth-Management deutlich. Einmal autorisieren, überall nutzen.
• GitHub. Ein dediziertes MCP für Issues und Pull Requests schlägt ein LLM, das gh auf der Kommandozeile bedient. Der Agent sieht klar typisierte Tools statt CLI-Output, den er jedes Mal neu parsen müsste.
• Notion. Der native Remote-MCP ist laut Mohl "exactly the right call" gegenüber einem lokalen notion-cli. Keine lokale Installation, zentrale Updates, sauberes Auth-Modell.

In allen drei Fällen gilt dieselbe Logik: Echte Services wollen echte Verträge, keine CLI-Umwege.

Das vorgeschlagene Framework

Der eigentliche Wert des Posts liegt nicht in der Kritik, sondern in der Rollenverteilung, die Mohl daraus ableitet. Beide Mechanismen haben ihren Platz, aber unterschiedliche Aufgaben:

• MCPs für Connectors. Service-Integration, tatsächliche Tool-Execution, API-Abstraktion. Immer dann, wenn der Agent etwas draußen in der Welt bewegen soll -- einen Kalendereintrag anlegen, ein Issue öffnen, eine Notion-Seite schreiben.
• Skills für Knowledge. Bestehende Tools erklären, Workflows dokumentieren, Gotchas festhalten, Business-Jargon standardisieren. Skills sind dann stark, wenn sie Kontext liefern -- nicht, wenn sie Ausführung übernehmen.

Die Vision ist ein Hybrid: Skills liegen wie Cheat Sheets über MCPs. Das MCP übernimmt Verbindung und Ausführung, der Skill liefert Patterns, Konventionen und domänenspezifisches Wissen, das der Agent sonst nicht hätte. Beide Ebenen konkurrieren nicht, sie ergänzen sich.

Einordnung

Die Debatte ist nicht akademisch. Wer heute ein Agent-System baut, muss sich zwischen Skill-basierten und MCP-basierten Erweiterungen entscheiden -- und die Marketingbotschaften auf beiden Seiten verwischen den Unterschied eher, als ihn zu klären. Mohls Unterscheidung liefert einen brauchbaren Entscheidungstest: Brauche ich einen echten Connector zu einem Service, oder will ich bestehendem Werkzeug Kontext mitgeben? Für Ersteres ist MCP die bessere Wahl, für Letzteres Skills.

Der Beitrag zeigt nebenbei, warum Standards in diesem Feld so wichtig sind. MCP ist nicht deshalb stark, weil es technisch elegant ist, sondern weil es portabel ist. Jeder Versuch, Skills als Ersatz für MCP zu positionieren, kollidiert mit genau dieser Eigenschaft -- und wer sie ignoriert, baut sich Lock-in in einen einzelnen Client. Dass Anthropic Skills aktiv pusht, ändert daran wenig. Die richtige Frage ist nicht, welches Konzept hipper ist, sondern welches Problem man gerade löst.

Quellen

• I Still Prefer MCP Over Skills -- David Mohl