Claude Skills sind beeindruckend – vielleicht eine noch größere Innovation als MCP

 (simonwillison.net)
52 Punkte von GN⁺ 2025-10-18 | 12 Kommentare | Auf WhatsApp teilen
  • Die von Anthropic vorgestellten Claude Skills sind ein neues Muster, bei dem Anweisungen, Skripte und Ressourcen, die ein Modell für bestimmte Aufgaben benötigt, in Form von Ordnern bereitgestellt werden. So wird aufgabenspezifische Expertise dynamisch geladen
  • Skills bestehen aus Markdown-Dateien und optionalen Skripten. Zu Beginn einer Sitzung werden aus jedem Skill nur die Metadaten mit einigen Dutzend Tokens geladen, und erst bei tatsächlichem Bedarf wird der vollständige Inhalt nachgeladen – mit sehr hoher Token-Effizienz
  • Mit Claude Code erweitern Skills das System über ein simples Coding-Tool hinaus zu einem universellen Automatisierungsagenten; überall dort, wo ein Dateisystem und eine Umgebung zur Befehlsausführung vorhanden sind, lassen sich verschiedenste Aufgaben automatisieren
  • Anders als MCP sind Skills kein Protokoll, sondern eine einfache Struktur auf Basis von Markdown und YAML, die sich auch mit anderen Modellen oder Tools sofort nutzen lässt und sich leicht teilen und verbreiten kann
  • Dank dieser Einfachheit und Effizienz wird erwartet, dass das Ökosystem rund um Skills viel schneller wächst als bei MCP; von Datenjournalismus bis zu Brand-Guidelines lassen sich spezialisierte Agenten für viele Bereiche bauen, ohne die Token-Kosten und die komplexe Spezifikation von MCP in Kauf nehmen zu müssen

Konzept und Struktur von Skills

  • Anthropic hat am 16. Oktober 2025 offiziell Claude Skills angekündigt
    • ein System zur Erweiterung von Fähigkeiten auf Ordnerebene, das die Anweisungen, Skripte und Ressourcen enthält, die ein Modell für bestimmte Aufgaben braucht, etwa für Excel-Arbeiten oder die Einhaltung von Brand-Guidelines in einer Organisation
    • Claude greift nur dann auf den jeweiligen Skill zu, wenn er für die Aufgabe relevant ist, und verbessert so die Fähigkeit zur Ausführung spezialisierter Arbeiten
  • Im GitHub-Repository anthropic/skills werden offizielle Skill-Beispiele bereitgestellt
  • Skills sind konzeptionell extrem einfach
    • Im Kern steht eine Markdown-Datei, die dem Modell erklärt, wie eine Aufgabe auszuführen ist
    • Optional können zusätzliche Dokumente und vorbereitete Skripte enthalten sein, um die Erledigung der Aufgabe zu unterstützen
  • Die im September angekündigte Funktion zur Dokumenterstellung von Claude war tatsächlich vollständig mit Skills umgesetzt

Token-Effizienz: der zentrale Vorteil von Skills

  • Zu Beginn einer Sitzung scannt Claude alle verfügbaren Skill-Dateien und liest aus dem Frontmatter-YAML jedes Skills nur eine kurze Beschreibung
  • Die anfängliche Token-Zahl pro Skill beträgt nur einige Dutzend, was extrem effizient ist
  • Erst wenn der Nutzer eine Aufgabe anfragt, bei der ein Skill hilfreich sein könnte, werden die vollständigen Details geladen
  • Genau das ist der entscheidende Unterschied, der aus bloß auf der Festplatte gespeicherten Dateien eine echte Funktionalität macht

Praxisbeispiel: der Slack-GIF-Erstellungs-Skill

  • Beschreibung der Metadaten des Skills slack-gif-creator
    • ein Toolkit zur Erstellung animierter GIFs, optimiert für Slack
    • enthält einen Prüfer für Größenbeschränkungen und kombinierbare Animationsbausteine
    • wird bei Anfragen wie „Erstelle mir ein GIF für Slack, in dem X Y macht“ angewendet
  • Tatsächlicher Testablauf
    • Im mobilen Web-App-Client von Claude wurde mit dem Modell Sonnet 4.5 der Skill slack-gif-creator aktiviert
    • Der Prompt „Make me a gif for slack about how Skills are way cooler than MCPs“ wurde eingegeben
    • Claude erzeugte automatisch ein GIF; die Qualität braucht noch Verbesserungen, aber iterative Verbesserungen des Skills sind leicht möglich
  • Bemerkenswerte Punkte am erzeugten Python-Skript
    • Hinzufügen des Skill-Verzeichnisses zum Python-Pfad: sys.path.insert(0, '/mnt/skills/examples/slack-gif-creator')
    • Nutzung der Klasse GIFBuilder aus dem core/-Verzeichnis des Skills
    • Speichern der Datei unter /mnt/user-data/outputs/
    • Prüfung der Einhaltung der Slack-Größenbeschränkung (2 MB) über die Funktion check_slack_size()
    • Wenn die Datei zu groß ist, kann das Modell automatisch versuchen, eine kleinere Version neu zu erzeugen

Umgebungsabhängigkeiten von Skills

  • Der Skill-Mechanismus funktioniert nur dann vollständig, wenn das Modell Zugriff auf Folgendes hat
    • ein Dateisystem
    • ein Werkzeug zur Navigation im Dateisystem
    • die Fähigkeit, in der Umgebung Befehle auszuführen
  • Das ist ein typisches Muster im LLM-Tooling
    • ChatGPT Code Interpreter war Anfang 2023 das erste große Beispiel
    • später wurde dieses Muster mit Coding-Agent-Tools wie Cursor, Claude Code, Codex CLI und Gemini CLI bis auf lokale Rechner ausgeweitet
  • Diese Anforderung ist der größte Unterschied zu früheren Versuchen, LLM-Fähigkeiten wie mit MCP oder ChatGPT Plugins zu erweitern
  • Es ist eine wichtige Abhängigkeit, aber das Ausmaß der neu freigeschalteten Fähigkeiten ist erstaunlich groß
  • Sicherheitsfragen bleiben weiterhin wichtig
    • Es braucht eine sichere Coding-Umgebung
    • Außerdem werden Wege benötigt, eine Sandbox-Umgebung aufzubauen, damit Angriffe wie Prompt Injection nur Schaden in akzeptablem Umfang anrichten können

Claude Code: Entwicklung zum universellen Agenten

  • Der Autor sagte im Januar 2025 voraus, dass „Agenten“ scheitern würden, lag damit aber komplett daneben
    • 2025 wurde tatsächlich zum Jahr der „Agenten“ – bei allen unterschiedlichen Definitionen, hier verstanden als tools in a loop
  • Claude Code ist eigentlich falsch benannt
    • Es ist kein reines Coding-Tool, sondern ein universelles Werkzeug zur Computer-Automatisierung
    • Jede Aufgabe, die sich durch Eingaben von Befehlen an einem Computer erledigen lässt, kann automatisiert werden
    • Am treffendsten ist die Beschreibung als General Agent
  • Skills machen dieses Potenzial viel klarer und expliziter sichtbar
  • Die möglichen Anwendungen sind schwindelerregend breit
    • Beispiel Datenjournalismus: Es lässt sich ein Skill-Ordner zusammenstellen, der folgende Aufgaben abdeckt
      • Quellen und Struktur von US-Volkszählungsdaten verstehen
      • Daten in unterschiedlichen Formaten mit Python-Bibliotheken in SQLite oder DuckDB laden
      • Daten online veröffentlichen, etwa als Parquet-Dateien auf S3 oder als Tabelle in Datasette Cloud
      • Interessante Geschichten in neuen Datensätzen finden, anhand von Anleitungen erfahrener Datenreporter
      • saubere und gut lesbare Datenvisualisierungen mit D3 erstellen
    • Ergebnis: Mit nur Markdown-Dateien und einigen Python-Skriptbeispielen lässt sich ein „Datenjournalismus-Agent“ bauen, der Geschichten in US-Volkszählungsdaten findet und veröffentlicht

Vergleich: Skills vs. MCP

  • Das Model Context Protocol (MCP) hat seit seiner Einführung im November 2024 enorme Aufmerksamkeit auf sich gezogen
    • Jedes Unternehmen brauchte eine „AI-Strategie“, und die Ankündigung einer MCP-Implementierung war ein einfacher Weg, dieses Bedürfnis zu bedienen
  • Nach und nach wurden die Grenzen von MCP sichtbar
    • Das wichtigste Problem ist der Token-Verbrauch
    • Das offizielle MCP von GitHub verbraucht allein bereits Zehntausende Kontext-Tokens
    • Fügt man noch einige weitere hinzu, bleibt dem LLM kaum noch Platz für tatsächlich nützliche Arbeit
  • Seit der Autor begonnen hat, sich ernsthaft mit Coding-Agenten zu beschäftigen, ist sein Interesse an MCP gesunken
    • Fast alles, was sich mit MCP erreichen lässt, kann durch CLI-Tools ersetzt werden
    • Das LLM weiß bereits, wie man cli-tool --help aufruft, und muss daher nicht viele Tokens für Nutzungsanweisungen verbrauchen
    • Das Modell kann sich die nötigen Informationen bei Bedarf selbst erschließen
  • Skills bieten exakt dieselben Vorteile, und mehr noch: Man muss nicht einmal neue CLI-Tools implementieren
    • Es genügt, eine Markdown-Datei mit der Beschreibung der Ausführung einer Aufgabe abzulegen
    • Zusätzliche Skripte werden nur dann ergänzt, wenn sie Stabilität oder Effizienz verbessern

Ausblick auf ein explosionsartiges Wachstum des Skill-Ökosystems

  • Einer der spannendsten Aspekte von Skills ist die leichte Teilbarkeit
    • Viele Skills werden voraussichtlich aus nur einer einzelnen Datei bestehen
    • Aufwendigere Skills werden die Form eines Ordners mit einigen wenigen Dateien haben
  • Von Anthropic bereitgestellte Materialien
  • Auch der Autor denkt bereits über Skill-Ideen nach, etwa wie man Datasette-Plugins baut
  • Auch mit anderen Modellen nutzbar: ein weiterer Vorteil des Skill-Designs
    • Wenn man einen Skill-Ordner an Codex CLI oder Gemini CLI anschließt und sagt: „Lies pdf/SKILL.md und erstelle mir ein PDF, das dieses Projekt erklärt“, funktioniert das
    • Das geht sogar dann, wenn das jeweilige Tool oder Modell kein eingebautes Wissen über das Skill-System hat
  • Erwartung: eine kambrische Explosion von Skills, die den diesjährigen MCP-Boom geradezu blass aussehen lässt

Einfachheit als zentrale Stärke

  • Manche wenden ein, Skills seien so simpel, dass man sie kaum als Feature bezeichnen könne
    • Viele haben bereits mit dem Trick experimentiert, zusätzliche Anweisungen in Markdown-Dateien zu schreiben und diese von Coding-Agenten lesen zu lassen
    • AGENTS.md ist ein gut etabliertes Muster und kann etwa die Anweisung enthalten, vor der PDF-Erstellung zuerst PDF.md zu lesen
  • Gerade diese grundlegende Einfachheit des Skill-Designs ist der Grund, warum der Autor so begeistert ist
  • MCP ist eine vollständige Protokollspezifikation
    • mit Host, Client, Server, Ressourcen, Prompts, Tools, Sampling, Roots und Elicitation
    • einschließlich dreier Übertragungswege (stdio, streamable HTTP und ursprünglich SSE)
  • Skills bestehen aus Markdown + etwas YAML-Metadaten + optionalen ausführbaren Skripten
    • Das liegt dem Wesen von LLMs viel näher: Man gibt Text hinein und das Modell erledigt den Rest
  • Skills lagern die schwierigen Teile an das LLM-Harness und die zugehörige Computerumgebung aus
    • Wenn man alles berücksichtigt, was in den letzten Jahren über die Fähigkeit von LLMs zur Werkzeugausführung gelernt wurde, ist das eine sehr kluge Strategie

Verwandte Beiträge

12 Kommentare

 
shakespeares 2025-10-19

Ich frage mich, ob sich das auch beim Einsatz von Claude Code fürs Programmieren anwenden lässt.
Derzeit hinterlege ich die Anleitungen bereits in Claude.md und arbeite mit getrennten Detailanleitungen für die einzelnen Bereiche.
 
labeldock 2025-10-19

Wenn man mit wenigen Tokens viele Aufgaben erledigen will, scheint sich das meiner Meinung nach einfacher durch den Einsatz von Multi-Agenten und Zusammenfassungen lösen zu lassen als durch Prompt-Optimierung. Dem Problem stimme ich zu, aber der Lösungsansatz wirkt auf mich in seinen Möglichkeiten begrenzt.
 
savvykang 2025-10-18

Verbrauchen Skills nicht auch Tokens? Falls ja, scheint das Problem des Token-Verbrauchs erneut aufzutreten, aber ich bin mir nicht sicher, wie man dann damit umgehen würde.
 
dnjstmxhs 2025-10-19

Es sieht so aus, als würde im Kontext nicht immer die gesamte SKILLS.md enthalten sein, sondern zunächst immer nur der obere Teil mit Name und Beschreibung wie unten.

name: skill-creator
description: Leitfaden zum Erstellen effektiver Skills. Dieser Skill sollte verwendet werden, wenn Nutzer einen neuen Skill erstellen (oder einen bestehenden Skill aktualisieren) möchten, der Claudes Fähigkeiten mit spezialisiertem Wissen, Workflows oder Tool-Integrationen erweitert.
license: Vollständige Bedingungen in LICENSE.txt
 
ds2ilz 2025-10-18

Wenn man mit Claude Code arbeitet, füttert man den Kontext ständig mit Anweisungen oder Regeln, und am Ende überlegt man zwangsläufig zwischen Token-Verbrauch und Kontextumfang hin und her. Daher kam ich auf die Idee, einen Ordner anzulegen, die Details dort je nach Funktion ausführlich in Markdown-Dateien zu dokumentieren und in claude.md nur jede Menge Verweise zu hinterlegen, was man wofür nachschlagen soll — und das hat erstaunlich gut und ziemlich kostengünstig funktioniert. Skills werden letztlich wohl genau so etwas bündeln, also scheint das ziemlich nützlich zu sein.
 
laeyoung 2025-10-19

Und wenn wie angekündigt auch noch ein Skills-Marktplatz kommt, könnte das ziemlich gut sein, weil man dann nur die benötigten Skills holt und sie bei Bedarf aktiviert.
 
shakespeares 2025-10-19

Oh, danke für die prägnante Erklärung.
 
2025-10-18
[Dieser Kommentar wurde ausgeblendet.]
 
dnjstmxhs 2025-10-19

Wie hängt das mit Context Handling und Claude Skills zusammen? Ich dachte zuerst: Worin unterscheidet sich das eigentlich von den früheren benutzerdefinierten Befehlen in Claude Code? Aber beim Lesen der Dokumentation hatte ich den Eindruck, dass der größte Unterschied wohl darin besteht, dass man innerhalb eines einzelnen Skills Skriptcode wie Python oder JavaScript einbinden und ausführen kann.
 
2025-10-18
[Dieser Kommentar wurde ausgeblendet.]
 
GN⁺ 2025-10-18
Hacker-News-Kommentare

  • Für mich sind Claude Skills ein Beleg dafür, dass RAG aus Sicht der User Experience unnötig schwer gemacht wird. Technisch ist das nicht komplex, das Problem ist die UX. Wenn man nur diesen Teil gut löst, könnte Claude Skills selbst überflüssig werden. Der Vorteil von Claude Skills gegenüber MCP ist, dass sie leicht zu erstellen sind. Man kann sie einfach durch Schreiben anlegen, also kann sie jeder nutzen. Allerdings sind sie stark von der Umgebung abhängig. Wenn man zum Beispiel ein bestimmtes Tool braucht, damit etwas funktioniert, wie automatisiert man dann das Sandbox-Setup? Es ist sogar schwer, sicher zu sein, ob überhaupt die richtige Version vorhanden ist.

  • Wir probieren intern in unserem Unternehmen etwas Ähnliches aus. Die Kontextdatei unseres Monorepos war zu groß, also haben wir einen Fragmentbaum aufgebaut, der je nach Aufgabe schrittweise geladen wird. Solche Kontextdokumente sehen existierender Entwicklerdokumentation sehr ähnlich, sind in der Praxis aber viel nützlicher und stärker auf Aufgaben ausgerichtet. Ich frage mich, warum wir solche Dokumente früher nie erstellt haben.

    1. Die Feedback-Schleife war viel zu lang. Man konnte ein Dokument schreiben und möglicherweise sein ganzes Leben lang nicht erfahren, ob es effektiv war; selbst wenn doch, dann vielleicht erst Jahre später. Selbst bei Änderungen war so etwas wie A/B-Testing unmöglich. Heute kann man einfach Kontext-Markdown schreiben, Claude damit arbeiten lassen und sofort iterativ verbessern.
    2. Die Tools machen schon das Schreiben von Dokumentation selbst leichter. Gute Dokumentation zu erstellen war früher immer schwierig, und Beispiele, Links oder nützliche Zusatzinfos einzubauen kostete enorm viel Zeit. Jetzt senken die Tools diese Kosten.
    3. Unter Entwicklern gibt es viele egoistische Menschen. Für andere geschriebene Dokumentation motiviert oft nicht besonders, aber wenn eine Dokumentation dabei hilft, KI besser einzusetzen, entsteht von selbst Motivation. Mich würde interessieren, ob andere noch weitere Theorien haben.

    • Das ist im Grunde ein Principal-Agent-Problem mit einer Art Marshmallow-Test-Komponente. Wenn ein Entwickler Dokumentation für andere Menschen und nicht für eine KI schreibt, weiß er nicht, wer diese Person ist, was sie braucht oder ob sie es überhaupt ansehen wird. Natürlich kann es ihm später selbst helfen, aber das zu verinnerlichen oder die nötige Zeit und Disziplin dafür aufzubringen ist schwer. Wenn jedoch eine KI die Dokumentation direkt nutzt, um mir zu helfen, entsteht ein enormer unmittelbarer Anreiz, die nötigen Informationen festzuhalten. Außerdem ist die Feedback-Schleife kurz. Nebenbei: Weil Code-Kommentare aufgrund der Eigenschaften von LLMs oft verschwinden, hinterlasse ich inzwischen deutlich mehr Dokumentation und viel weniger Kommentare.

    • Neue Entwickler beschweren sich selten über schlechte Dokumentation, weil sie nicht dumm wirken wollen. Der Autor hat das Modell bereits im Kopf und merkt das Problem daher oft nicht, und gute Dokumentation zu schreiben galt als etwas, das den eigenen Arbeitsplatz gefährdet. Gibt man einem dummen Roboter hingegen schlechte Dokumentation, muss man sich selbst die Schuld geben, wenn es nicht funktioniert. Ich denke also, es ist #2 + #3. Die große Veränderung ist, dass „Ersetzbarkeit“ von etwas Negativem zu etwas Positivem geworden ist (man ersetzt sich lieber selbst durch einen Agenten, bevor ein billiger Agent den eigenen Platz übernimmt).

    • Ähnlich wie es technische Schulden gibt: geschäftlicher Druck, schlechtes Design, fehlende Ressourcen. Es war früher wirklich teuer, gute Dokumentation kontinuierlich aktuell zu halten, jedes Mal wenn sich Code änderte.

  • Als ich mir die Situation mit mehreren Skills in einem Ordner vorgestellt habe, musste ich an Aufgaben denken wie das Auffinden von US-Volkszählungsdaten oder das Verstehen ihrer Struktur. Das erinnerte mich sofort an das erste Mal, als ich Wolfram Alpha benutzt habe. Anders als eine allgemeine Suchmaschine war ich überwältigt davon, dass ein wirklich strukturiertes Tool Probleme löst. Ich habe es jetzt noch einmal benutzt, und es ist immer noch beeindruckend: US-Bevölkerungsabfrage mit Wolfram Alpha. In meinem Kopf ähnelt das Skills-Modell einem Wolfram Alpha mit benutzerdefinierten Erweiterungen.

    • Als ich auf deinen Link geklickt habe, wurde die Abfrage in Wolfram Alpha als what%27s the total population of the United States%3F geöffnet. Das Ergebnis ist lustig: Es zeigt 6.1% mod 3 °F (2015-2019 American Community Survey 5-year estimates). Ich frage mich, wie das berechnet wurde.

    • Ehrlich gesagt war das damalige Wolfram Alpha wirklich eine verrückte Leistung. Ich finde es bis heute erstaunlich, wie man damals ohne KI ein System bauen konnte, das sogar komplexe Mathematikprobleme behandelt.

  • Mir ist der Unterschied zwischen Skills und bestehenden Tools etwas unklar. Viele Skills könnte man auch einfach als Tools sehen, oder als Bündel mehrerer Tools mit zusätzlicher Beschreibung. Aber liegen die Tool-Definition und die Skill-Definition nicht an verschiedenen Stellen? Ich frage mich, wie man die Abhängigkeit zwischen beiden ausdrücken soll. Wenn ein Skill angibt „nutzt die Kommandozeile, Python, Tool A und Tool B“, bedeutet das dann, dass diese Tools beim Laden des Skills mit aktiviert werden?

  • Der eigentliche Punkt, den man beachten sollte, ist, dass alle auf MCP fixiert waren und pfadabhängig gehandelt haben. Das wirklich Interessante ist eigentlich schlicht der „tool call“ selbst. Tool Calls sind wirklich nützlich und faszinierend. MCP ist nur eines von mehreren Mitteln dafür. Und nicht einmal ein besonders gutes.

    • Ich denke, dass MCP vor allem wegen des Timings so groß geworden ist. Tool Calling gab es schon vor MCP, aber die Modelle konnten damit nicht gut umgehen. MCP tauchte genau in dem Moment auf, in dem Modelle anfingen, Tool Calls gut auszuführen. Im Kern des MCP-Hypes steckt also, dass den Leuten bewusst wurde, dass LLMs Tool Calls nutzen können, um mit anderen Systemen zu interagieren.

    • Ein MCP-Server ist im Grunde ein Register zur Registrierung von Tool Calls. Was genau ist dann schlechter daran als ein normaler Tool Call?

    • MCP ist insofern bedeutend, als es LLMs das Konzept von OAuth beibringt. Dadurch werden serverbasierte Tool Calls möglich. Früher musste man für jede CLI separat installieren und darin die Authentifizierung separat behandeln. Dass Tool Calling die größte Stärke von LLMs ist, stimmt, aber ich finde auch die Botschaft „Man muss sich um Tool-Authentifizierung kümmern“ ziemlich wertvoll.

    • Nebenbei gesagt zeigt das auch, dass MCP ebenfalls eine von Anthropic vorangetriebene Innovation war.

    • Auch wenn man Skills außen vor lässt: Mich würde interessieren, welche besseren Ansätze es als MCP gibt.

  • Die Wirkung von MCP reicht weit über das Terminal hinaus. Man kann es auch in ChatGPT, Claude Web, n8n und LibreChat verwenden, und es berücksichtigt Authentifizierung, Ressourcen und sogar UI (apps-sdk usw.). Für Coding-Workflows oder CLI-basierte Agenten (wie Claude Code) haben CLI-Tools zwar enormen Wert, aber in Bereichen wie CRM, Vertrieb, Support, Betrieb oder Finanzen sind MCP-basierte Tools die passendere Form. Skills und MCP stehen nicht in Konkurrenz, sondern verfolgen komplementäre Ziele. Der echte Sprung kommt insbesondere dann, wenn der Python-Code eines Skills MCP direkt über den Interpreter aufrufen kann (wir haben das auch ausprobiert, und es funktioniert sehr gut).

    • Einer der großen Vorteile von MCP gegenüber terminalbasierten Tools ist, dass es auch ohne eine Sandbox wie eine vollständig isolierte Linux-Umgebung funktionieren kann. Außerdem kann man es schon mit deutlich einfacheren Modellen nutzen. Selbst Modelle, die auf einem Notebook oder sogar auf einem Smartphone laufen, können zwei oder drei MCPs gut handhaben. Ehrlich gesagt ist es bei solchen Modellen unrealistisch, von ihnen zu erwarten, dass sie Dateien lesen und sogar curl zuverlässig benutzen.

    • Es fühlt sich im Moment wirklich großartig an, LLMs mit externer Software oder der physischen Welt zu integrieren. All das geschieht in natürlicher Sprache. LLMs können sogar den Code für MCP-Server erzeugen, sodass sich völlig neue Funktionen leicht erstellen lassen.

  • Ehrlich gesagt halte ich MCP für überschätzt, und die Grenzen sind klar. 95 % der derzeitigen MCP-Server sind nutzlos und könnten einfach durch einen simplen Tool Call ersetzt werden.

    • Natürlich: Ein gut gebauter MCP-Server ist wirklich gut. Ein schlecht gemachter MCP-Server verursacht dagegen noch größere Probleme. Meist stehen alle Produktteams unter Druck, unbedingt einen MCP-Server bauen zu müssen, nur weil „MCP gerade heiß ist“. Kunden verlangen so etwas ebenfalls, weil KI-Nutzung bei ihnen zwangsläufig als Ziel gesetzt ist. Aber eigentlich wissen sie nicht, was sie wollen, solange sie nur sagen können: „Da ist KI drin.“ Produktteams können deshalb dank MCP schnell damit werben, „wir sind ein KI-Produkt“, obwohl der konkrete Nutzen unklar ist. Das ist ein Phänomen, das mit dem eigentlichen Wesen von KI nicht viel zu tun hat.

    • MCP kann man nur nutzen, wenn man dem Serveranbieter vertraut. Man ist faktisch von der Ehrlichkeit des Servers abhängig. Firmen wie Uber werden LLMs in Wirklichkeit mit allerlei Prompt Engineering ständig dazu lenken, ihren eigenen Service für die beste Option zu halten. Zwischen MCP-Publisher und Consumer besteht also am Ende ein vollständig falscher Anreiz.

    • Ich stimme zu, dass Tool Calls der Kern sind. Aber MCP hat gegenüber CLI mindestens zwei Vorteile. Erstens ist MCP leichter als CLI, wenn Tool-Call-LLMs strukturierte Ausgaben verlangen und komplexe Interaktionen umsetzen sollen. Zweitens kann man auf einem MCP-Server ganz natürlich State zwischen Tool Calls erhalten. Anfangs dachte ich auch, ich sei vielleicht nur leicht dem Hype erlegen, aber eine kleine Demo, die ich kürzlich zum Lernen von MCP gebaut habe (https://github.com/cournape/text2synth), war einfacher umzusetzen als dieselbe Idee per CLI, und ich finde, solche Beispiele zeigen gut die faszinierenden Einsatzmöglichkeiten von MCP.

    • MCP-Server scheinen bei Hackern extrem beliebt zu sein. Es gibt viel zu viele schlecht konfigurierte und schlampig bereitgestellte Instanzen. Unternehmen haben praktisch all ihre bisherigen Schutzmechanismen für Deployments entfernt.

    • Unser Frontend-Team zieht enormen Nutzen aus dem figma-MCP. Eine Aufgabe, die drei Wochen gedauert hätte, war an einem Tag erledigt.

  • Ich habe selbst etwas gebaut, das mit ein paar Markdown-Dateien mit Skills mithalten kann. Es reicht, den Agenten etwa einmal pro Sitzung an den Skill zu erinnern. Ich sehe nicht ganz, was an Claudes Umsetzung daran besonders sein soll.

    • Ein wichtiger Teil ist, einem Muster einen Namen zu geben. Es war bereits ein nützliches Muster, das viele Menschen ganz natürlich entdeckt und verwendet hatten, aber mit einem Namen kann man auf einem höheren Niveau darüber sprechen. Anthropic hat außerdem erkannt, dass dieses Muster beim Lösen des chronischen Problems der „Kontext-Verschmutzung“ von Coding-Agenten hilft. Frühere AGENTS.md oder MCP waren unpraktisch, weil zu viele Informationen in den Kontext gelangten, während das Skills-Muster viel effizienter ist.

    • Es wirkt wie eine offizielle Strukturierung eines bereits gelösten Problems mit etwas mehr Automatisierung. Viele der MCPs, die ich früher genutzt habe, waren letztlich nur eine schicke Dokumentensuche, und ich erwarte, dass solche Skills sie ersetzen werden.

    • Ich habe dieselbe Frage. Ich nutze das seit über einem Jahr mit Aider oder CC.

  • Das mag etwas negativ klingen, aber ich wollte sehen, ob andere das ähnlich empfinden. Wenn man durchschnittlichen Nutzern sagt, sie sollen solche Services selbst einrichten, ist ihre Reaktion zu Recht: „Seid ihr verrückt?“ Die meisten wollen sich einfach einloggen, etwas anfordern und dann soll das System den Rest erledigen. MCP, Apps, Skills, Gems usw. greifen das Problem alle falsch an. Das erinnert an YouTube-Kanäle, die alle sechs Monate verkünden, „diese neue Programmiersprache oder dieses neue Framework ist das Beste“, dann eine Todo-App bauen und am Ende höchstens sechsmal dasselbe Video wiederholen. Es gibt nur wiederholte oberflächliche Verbesserungen, aber das grundlegende Problem wird nicht gelöst. Irgendwo im Tech-Bereich läuft etwas schief, und sobald Geld hineinströmt, kommen nur noch solche Ankündigungen, dann der nächste Release, Beförderung, Jobwechsel, und am Ende bleibt kein substanzieller Wert.

    • Zur Behauptung, dass das grundlegende Problem nicht gelöst wird: In letzter Zeit liefern Lösungen gleich neue Probleme im Paket mit. Man öffnet die Schachtel, und Problem und Lösung springen gleichzeitig heraus, jagen einander und rennen voneinander weg. Und man hat das Gefühl, technisch ein weiterentwickelter Mensch geworden zu sein.

    • Zu der Aussage, dass MCP, Apps, Skills, Gems usw. alle am falschen Problem arbeiten: Aus meiner pessimistischen Sicht erstellen wir jetzt mehr Dokumentation und APIs für KI, obwohl das Ergebnis wahrscheinlich ähnlich gewesen wäre, wenn wir dieselbe Dokumentation für Menschen geschrieben hätten. Die Hälfte meiner Zeit ging dafür drauf, komplexe Systeme ohne Dokumentation zu debuggen.

    • Was ist eigentlich das „grundlegende Problem“, und in welchem Rhythmus wurde versucht, dieses „grundlegende Problem“ vor der Popularisierung von ChatGPT im Jahr 2023 zu lösen?

    • Wenn man das Beispiel nimmt, dass man „dieselbe Todo-App sechsmal baut und dann wieder vergisst“, sehe ich ehrlich gesagt nicht, was daran das Problem sein soll. Technologie entwickelt sich nun einmal schrittweise und iterativ weiter. Morgen wird wieder jemand ein Video über das beste Frontend-Framework veröffentlichen, und früher war es genauso mit Nextjs, davor React, Angular, JQuery, PHP und HTML. Wäre nicht so viel Kapital in KI geflossen, würden wir vielleicht immer noch bei GPT-3 und Claude 2 stehen. Bei den Tools kommt manchmal Schrott heraus (ich finde Skills eigentlich ziemlich gut), aber deshalb würde ich nicht sagen, dass die ganze Branche verdorben ist.

    • Nun ja, wir stehen noch ganz am Anfang, und niemand weiß wirklich, was tatsächlich funktioniert. Es wirkt oberflächlich, ist aber in Wirklichkeit Stand der Technik.

  • Das ist ein völlig anderes Konzept. MCP dient der Anbindung externer Services und umfasst auch Authentifizierung wie OAuth. Skills sind im Grunde eine Kombination aus CLI-Tools und Prompts. Die Einsatzbereiche sind unterschiedlich, daher lassen sie sich nicht leicht vergleichen. Übrigens hatten wir schon vor MCP ein System namens Skillset gebaut; rückblickend denke ich, dass es ein hervorragender Hybrid war, der die Vorteile von MCP und Skills kombiniert hat.
 
github88 2025-10-18

Das ist wirklich übertrieben.