Ich bevorzuge immer noch MCP gegenüber Skills

• MCP ist eine standardisierte Schnittstelle auf Basis von API-Abstraktion, mit der ein LLM Aufgaben anfordern kann, ohne die interne Struktur eines Tools zu kennen, und unterstützt Remote-Nutzung sowie automatische Updates
• Durch eine Zero-Install-Architektur, OAuth-Authentifizierung und Sandboxing-Sicherheit werden Installationsaufwand und Berechtigungsprobleme reduziert und auf jeder Plattform dieselbe Umgebung bereitgestellt
• Skills hingegen verursachen in realen Laufzeitumgebungen viel Reibung, etwa durch Abhängigkeit von CLI-Installationen, komplexe Authentifizierung und Bereitstellung sowie plattformspezifische Kompatibilitätsprobleme
• Skills sollten als Wissensschicht und MCP als Verbindungsschicht verstanden werden: Für die Interaktion von LLMs mit externen Systemen eignet sich MCP, für die Vermittlung prozeduralen Wissens Skills
• Mit Cloud-Tunneling-Diensten wie MCP Nest lassen sich lokale MCP-Server aus der Ferne erreichen; das gilt als zentraler Baustein für den Aufbau einer standardisierten AI-Integrationsumgebung

---

Vorteile von MCP

• Das Model Context Protocol (MCP) basiert auf einer API-Abstraktionsstruktur, mit der ein LLM Aufgaben allein durch Anfragen ausführen kann, ohne die interne Funktionsweise eines Tools verstehen zu müssen
  • Beispiel: Wenn ein LLM mit DEVONthink interagiert und devonthink.do_x() aufruft, übernimmt der MCP-Server die gesamte Verarbeitung
• Zero-Install-Remote-Nutzung ist möglich: Der Client muss nur die URL des MCP-Servers angeben, und alles funktioniert sofort ohne zusätzliche Installation
• Automatische Updates werden unterstützt: Wenn ein entfernter MCP-Server mit neuen Tools oder Ressourcen aktualisiert wird, können alle Clients sofort die neueste Version nutzen
• OAuth-basierte Authentifizierung erhöht die Sicherheit, ohne dass Nutzer Tokens selbst verwalten müssen
• Die Portabilität ist hoch: Über denselben MCP-Server ist der Zugriff in jeder Umgebung möglich, etwa auf Mac, mobil oder im Web
• Durch eine Sandboxing-Struktur werden direkte Ausführungsrechte in der lokalen Umgebung eingeschränkt und nur kontrollierte Schnittstellen offengelegt
• Mit intelligenter Suche und automatischen Updates werden nur die benötigten Tools geladen; auch bei lokaler Installation ist eine automatische Aktualisierung beim Ausführen möglich

Grenzen und Reibung bei Skills

• Skills sind nützlich, um einem LLM bestimmtes Wissen oder Anwendungsweisen beizubringen, doch bei der tatsächlichen Ausführung wird die CLI-Abhängigkeit zum Problem
• Die meisten Skills verlangen die Installation einer separaten CLI, aber Web-Versionen wie ChatGPT, Perplexity oder Claude können keine CLI ausführen
• Daraus ergeben sich unter anderem folgende Probleme
  • Komplexität bei der Bereitstellung: CLIs müssen als Binary, über NPM, uv usw. verteilt und verwaltet werden
  • Probleme beim Secret-Management: Authentifizierungs-Tokens werden im Klartext in .env-Dateien gespeichert oder gehen verloren, wenn eine Sitzung zurückgesetzt wird
  • Unterbrochenes Ökosystem: Installations- und Update-Methoden für Skills unterscheiden sich je nach Plattform, was Kompatibilitätsprobleme und YAML-Parsing-Fehler verursacht
  • Verschwendung von Kontext: Selbst wenn ein LLM nur einen einzelnen Funktionsaufruf benötigt, muss die gesamte SKILL.md geladen werden
• Ein Skill, der die Anweisung enthält, „zuerst die CLI zu installieren“, fügt unnötige Komplexität hinzu; ein Remote-MCP ist hier die effizientere Alternative

Kriterien für die passende Werkzeugwahl

• Wann MCP verwendet werden sollte: Wenn ein LLM mit externen Systemen wie Websites, Diensten oder Anwendungen verbunden wird, dient MCP als standardisierte Schnittstelle
  • Beispiel: Google Calendar sollte Authentifizierung und Ausführung über ein OAuth-basiertes Remote-MCP abwickeln und keine CLI-Installation voraussetzen
  • Auch Chrome, Hopper, Xcode und Notion sollten idealerweise eingebaute MCP-Endpunkte zur Steuerung ihrer jeweiligen Funktionen bereitstellen
• Wann Skills verwendet werden sollten: Wenn der Fokus auf reiner Wissensvermittlung und Kontextbereitstellung liegt
  • Zur Vermittlung der Nutzung bereits installierter Tools (curl, git, gh, gcloud)
  • Zur Vereinheitlichung von Begriffen, Arbeitsabläufen und Schreibstil innerhalb einer Organisation
  • Zum Teilen prozeduralen Wissens wie PDF-Verarbeitung oder Secret-Management (z. B. die Nutzung von fnox)
• Skills sollten als Wissensschicht, MCP als Verbindungsschicht getrennt werden

Connectoren und Handbücher

• Um die Rollen von Skills und MCP klar zu trennen, wird vorgeschlagen, Skills als LLM-Handbuch (LLM_MANUAL.md) und MCP als Connector zu bezeichnen
• Beispiele aus dem realen Betrieb
  • mcp-server-devonthink: ein lokaler MCP-Server, mit dem ein LLM DEVONthink direkt steuern kann
  • microfn: bietet Remote-MCP unter mcp.microfn.dev an
  • Kikuyo: bietet Remote-MCP unter mcp.kikuyo.dev an
  • MCP Nest: ein Dienst, der lokale MCP-Server per Cloud-Tunneling für den Fernzugriff verfügbar macht (mcp.mcpnest.dev/mcp)
• Manche Projekte liefern zusätzlich Skills für CLIs mit, doch ein Skill, der die Nutzung von MCP erklärt, ist nützlicher
  • Der Skill fungiert als Wissensschicht, die Funktionen von MCP, Beziehungen zwischen Tools und passende Einsatzzeitpunkte erklärt
  • MCP übernimmt die tatsächliche Verbindung und Ausführung
• Durch diese Kombination kann ein LLM MCP effizient nutzen, ohne wiederholt durch Versuch und Irrtum gehen zu müssen

Paralleler Einsatz von MCP und Skills

• Nicht intuitive Muster, die bei der Nutzung von MCP entdeckt werden, etwa Datumsformatfehler oder Einschränkungen bei der Suche, lassen sich in einem Skill festhalten und wiederverwenden
• Ein so erstellter Skill übernimmt die Rolle eines Cheat Sheets für MCP und hilft dem LLM, korrekt zu arbeiten, ohne unnötig Tokens zu verschwenden
• Über den Ordner .claude/skills lassen sich projektspezifische Anweisungen für das Verhalten von AI beibehalten und häufig genutzte Abläufe in Form von dotfiles verwalten
• Die Zukunft der AI-Integration hängt von standardisierten Schnittstellen (MCP) ab; fragmentierte CLI-basierte Ansätze sollten vermieden werden
• Es wird erwartet, dass große Dienste wie Skyscanner, Booking.com, Trip.com und Agoda.com offizielle MCP-Angebote bereitstellen werden

Vorstellung von MCP Nest

• MCP Nest ist ein Dienst, der lokal verfügbare MCP-Server (Fastmail, Gmail usw.) per Cloud-Tunneling remote zugänglich macht
• Er kann in gleicher Weise mit MCP-fähigen Clients wie Claude, ChatGPT und Perplexity verwendet werden
• So lässt sich auf allen Geräten dieselbe MCP-Umgebung beibehalten, ohne den lokalen Rechner direkt offenzulegen

[jujumilk3]

Es sind einfach zwei völlig unterschiedliche Dinge – warum kommt diese Diskussion immer wieder auf?

[xguru]

Ich muss am Ende des Artikels noch für MCP Nest werben … hehe. Anscheinend gewinnen solche vergleichenden Behauptungen ziemlich stark an Zugkraft.

[jjw9512151]

Skills sind Fechtkunst und MCP ist das Schwert … Der Einsatzzweck ist unterschiedlich, und man braucht beides.

[ide127]

Skills und MCP erfüllen unterschiedliche Rollen, aber ich glaube, durch solche Beiträge kommt es immer wieder zu Verwirrung.

[ide127]

Dabei wimmelt es in der ohnehin schon stürmischen KI-Branche von pseudoreligiösen Predigern.

[GN⁺]

Hacker-News-Kommentare

• Ich möchte betonen, dass wir uns weniger auf persönliche Präferenzen konzentrieren sollten als auf das Tool-Design, das LLMs brauchen, um optimal zu arbeiten
  MCP fügt eher Reibung hinzu. Wenn man zum Beispiel mit eingebetteten Systemen arbeitet, kann man dem LLM stattdessen eine CLI-basierte Monitoring-Schnittstelle bauen, mit der es direkt debuggen, zurücksetzen, Emulatoren starten usw. kann, und die Nutzung in einer Skill-Datei dokumentieren
  Für einfache Aufgaben ist MCP unnötig. Dinge wie Git oder AWS-Kostenberechnung beherrscht ein LLM ohnehin schon gut. Effizienter ist es, nur für komplexe Systeme eigene Tools zu bauen und zu dokumentieren

  • Bei der MCP-Diskussion werden gefühlt zu viele Konzepte vermischt. Der Kernpunkt ist Sitzungspersistenz
    Für Einmalaufgaben reichen CLI oder API, aber wenn dauerhafter Zugriff nötig ist, ist ein MCP-Server nützlich
    Ein gut aufgebautes MCP zeigt dem Agenten ohne Prompt-Verschwendung, wie es zu benutzen ist. Dauerhaften Zugriff über Skill-Dateien nachzuahmen ist ineffizient. MCP ist die effektivste Art, externe Tools in eine Agenten-Sitzung zu integrieren
  • MCP und Skill stehen in einer ergänzenden Beziehung. Sie gegeneinanderzustellen ist ein Missverständnis
  • Die aktuelle LLM-Toolchain wirkt noch wie eine Übergangsphase ohne Standardisierung. Statt Informationen an verschiedenen Stellen wie .md oder Skill abzulegen, braucht es einen Standard, der sie über automatisierte Selbstreflexionsschleifen an der optimalen Stelle organisiert
  • Ich verfolge einen ähnlichen Ansatz. Die meisten CLI-Tools hat Claude direkt erstellt, und ich nutze fast nie eine IDE
    Sogar die Refactoring-Funktionen von JetBrains habe ich durch Skripte ersetzt, wodurch sich die Sitzungsdauer von 5 Minuten auf 10 Sekunden reduziert hat
    MCP nutze ich bislang überhaupt nicht. Die Kombination REST + Swagger + codegen + Claude + Skill reicht völlig aus
  • Der Vorteil von MCP ist Berechtigungskontrolle. Wenn man zum Beispiel nicht will, dass eine KI Schreibzugriff auf Git hat, kann man den freigegebenen Umfang über MCP begrenzen. Ein bloßes READ_ONLY_SKILL reicht dafür nicht

• Diese Debatte ist letztlich eine Frage von Einzelentwickler vs. Zusammenarbeit auf Organisationsebene
  Wer allein schnelle Feedback-Loops will, fährt mit CLI besser, und wenn auf Organisationsebene Kontrolle und Konsistenz nötig sind, passt MCP besser
  Aktuell verbraucht MCP viel Kontext, aber das soll künftig durch schrittweise Offenlegung verbessert werden

  • In Organisationen ist die Zugriffskontrolle bei MCP problematisch. Ein Mensch löscht vielleicht versehentlich nur zwei Dinge, aber ein Agent kann in Sekunden Tausende löschen. Mit CLI lässt sich der Zugriffsbereich einschränken, was sicherer ist
  • Kontextverschwendung ist ein Problem der Client-Implementierung. Inkrementelles Laden ist auch ohne Änderung der Spezifikation möglich
  • MCP und CLI sind Werkzeuge für unterschiedliche Zwecke und am stärksten, wenn man sie zusammen nutzt

• Ich möchte einen Agenten, der bestehende CLI-Tools direkt nutzt, statt APIs
  Wenn ich lokal CLI nutze, gibt es keinen Grund, zusätzlich MCP einzuführen. Remote-Modelle will ich auch nicht
  Wenn API-Aufrufe nötig sind, reicht eine Skill-Datei

  • Ich rufe ebenfalls benutzerdefinierte APIs auf, indem ich curl-Befehle direkt in Skill-Dateien einfüge. LLMs kommen damit gut zurecht
  • Für das Geheimnismanagement ist MCP aber sicherer. Wenn der MCP-Server zuerst gestartet wird, werden Schlüssel nicht an die Agenten-Umgebung preisgegeben
  • MCP dient als Sicherheitsgrenzschicht zwischen Agent und Außenwelt. Nicht immer nötig, aber nützlich
  • In manchen Umgebungen hat ein LLM möglicherweise keinen CLI-Zugriff. Dann sind skill-basierte CLI-Aufrufe nutzlos
  • Es gibt auch Fragen zu Authentifizierung (authn) und Autorisierung (authz). MCP kann das als Middleware steuern

• MCP und Skill sind keine Nullsummenbeziehung
  MCP übernimmt die standardisierte Schnittstelle der Infrastrukturebene, Skill den projektspezifischen Handlungskontext
  In Kombination bekommt man sowohl Stabilität als auch Flexibilität

  • MCP ist letztlich nur eine Verpackung um CLI. Im Gegenteil verursacht MCP sogar mehr Kontext-Overhead
  • Einige kostenpflichtige MCPs haben tatsächlich Wert. Ein MCP für Websuche ist zum Beispiel bequemer, als selbst einen Crawler zu betreiben
  • Bei Cloud-gehosteten Agenten ist die Kombination aus Skill + MCP die Kernarchitektur. Authentifizierung und Abhängigkeitsmanagement werden einfacher
  • Auch der Autor des Beitrags unterstützt diese Kombination. MCP ist hoch portabel und lässt sich identisch in ChatGPT, Claude, Perplexity usw. verwenden
  • Skill kann vom LLM ignoriert werden, aber MCP-Richtlinien haben serverseitig Durchsetzungskraft

• Die meisten Diskussionen drehen sich um Leute, die lokal Coding-Agenten betreiben
  In solchen Umgebungen ist Skill bequemer, aber normale Nutzer verwenden cloudbasierte Angebote wie ChatGPT
  In diesem Fall wird MCP zur Standardwahl. Seine Stärke sind Authentifizierung und Remote-Zugriff

  • Manche sehen MCP allerdings nur als lauten API-Wrapper
    Man muss einen Server starten, und für das LLM ist es eher zusätzliche Last. Skill kodiert API-Dokumentation LLM-freundlich und ist daher einfacher
  • Auf die Behauptung „Die meisten Nutzer verwenden keine lokalen Agenten“ kam auch der Einwand, dass dafür Belege nötig seien
  • Es gab auch einen Scherz, der den Tippfehler „agronomic“ zu „ergonomic“ korrigierte

• Ich bevorzuge Skill, weil man damit CLI-Tools für Menschen unverändert wiederverwenden kann
  Skill ist eine für Menschen les- und schreibbare Dokumentation, sodass LLM und Mensch dieselben Werkzeuge teilen
  Bei MCP muss man dagegen neue APIs speziell für LLMs bauen und die Dokumentation separat pflegen
  Skill wird nur bei Bedarf geladen und hält den Kontext sauber

• Leute, die nur „Skill“ fordern, sind oft Nichttechniker, und die Fraktion „nur CLI“ findet man häufig bei Einzelentwicklern
  MCP passt gut zu Enterprise-Umgebungen. Es standardisiert Authentifizierung und Schnittstellen

  • Viele stehen MCP wegen der Instabilität von JIRA MCP negativ gegenüber. Ein auf acli basierender Skill war stabiler
  • Ich habe selbst ein internes MCP für mein Unternehmen gebaut. Es nutzt Google-Workspace-Authentifizierung und sorgt dafür, dass Claude interne Datenabfragen oder App-Deployments sicher ausführen kann
    MCP lässt sich leicht aktualisieren und bereitstellen und ist deshalb auch für Nichttechniker gut zugänglich
  • Es gab auch die Meinung, dass CLI besser sei, weil Unternehmen bereits interne Authentifizierungssysteme haben
    MCP sei letztlich nur eine strukturierte Teilmenge einer API
  • MCP lässt sich schnell hochziehen. Eine Kette von Codex → LiteLLM → VLLM → MCP steht in wenigen Minuten
  • Ich betrachte bestehende SaaS-Systeme als Legacy. Eine lokale SQL-Datenbank ist effizienter als APIs, bei denen Datenzugriff schwierig ist
    MCP ist nur ein weiteres RPC-Protokoll, und auch das Authentifizierungsproblem ist weiterhin ungelöst

• Ich halte MCP wegen der Irrationalität von Menschen für notwendig
  Viele Organisationen bieten noch immer weder API noch CLI an. MCP überbrückt solche digitalen Brüche
  Berichtslinien und politische Strukturen in Unternehmen blockieren Automatisierung, und MCP kann das umgehen

  • Dem stimme ich zu. Wenn Agenten von Kollegen stellvertretend zusammenarbeiten könnten, wäre die Digitalisierung von Organisationen viel einfacher. MCP ist gut darin, diese Komplexität der Verkabelung zu verbergen

• Skill hat das Problem des context bloat, weil das gesamte Dokument in den Kontext gelegt werden muss
  Bei MCP ist es ähnlich, aber durch Tool-Erkennung ist schrittweises Laden möglich
  Das größere Problem ist, dass MCP-Ausgaben direkt in den Agentenkontext gelangen. Wenn man MCP-Dienste über CLI aufruft, sind Filterung oder Caching möglich

  • Darauf kam auch die Reaktion: „Warum dann nicht einfach HTTP-Requests verwenden?“
  • Der Autor erklärte, dass aktuelles MCP das bereits mit verzögertem Laden auf Basis von Tool-Erkennung löst. Claude Code nutzt Subagenten, um Log-Fluten zu verhindern
  • Ich löse das, indem ich lokales MCP mit einem Memory-Cache umhülle. Jede Tool-Ausgabe bekommt eine ID, und mit dieser ID werden andere Tools aufgerufen. Das spart Tokens und erhöht die Geschwindigkeit

• Skill eignet sich gut für intuitives Wissen, MCP dagegen für wiederholbare Automatisierung
  Wenn ein LLM dasselbe Skript mehrfach schreibt, ist es effizienter, es als Tool zu fixieren

  • Die meisten Prozesse sollten per Skript vorverarbeitet werden, und das LLM sollte nur noch an Planung und Verifikation beteiligt sein
    Der Schlüssel ist also, möglichst viel per Skript vorzuverarbeiten
  • Man kann Skripte auch direkt in eine Skill-Datei einbetten. Skill kann ebenfalls Code enthalten
  • Der ursprüngliche Autor stellte klar, dass der Text von einem echten Menschen während eines Flugs geschrieben wurde, nicht von einer KI
  • Jemand sagte, er nutze Skill auch für wiederkehrende Aufgaben, woraufhin eine Erklärung aus Sicht des API-Vertrags von MCP folgte
    Bei kleinen Skripten reicht es, sie einfach in den Kontext zu legen und zu sagen: „Benutze das“