Tools: Code allein reicht – Code Is All You Need

• Es wird zwar behauptet, die MCP-Art der Tool-Anbindung sei die „Zukunft“, tatsächlich ist direktes Schreiben von Code weiterhin effizienter, weil es an Kompositionsfähigkeit mangelt und übermäßig viel Kontext verbraucht
• Auch im Zeitalter der LLMs ist das Erzeugen/Nutzen von Code bei Automatisierung und wiederkehrenden Aufgaben im Hinblick auf Zuverlässigkeit und Verifizierbarkeit im Vorteil
• LLMs sind stärker bei Codegenerierung und wiederholter Ausführung als bei inferenzbasierter Automatisierung; codebasierte Prozesse sind bei Problemanalyse, Verifikation und Skalierbarkeit überlegen
• Bei einigen Tools wie Playwright (MCP-Ansatz) nehmen Unsicherheit und Debugging-Schwierigkeit mit jedem „inferenzbasierten“ Schritt zu, während das direkte Erzeugen/Anpassen von Skripten in Code Wiederholbarkeit, Geschwindigkeit und Zuverlässigkeit verbessert
• Der „Code-Prüfen-Wiederholen“-Loop, in dem ein LLM Code erzeugt und ein anderes LLM diesen Code überprüft und erklärt, ist in der Praxis der stärkste Automatisierungs-Workflow

---

Code allein reicht

• Wer mir auf Twitter folgt, weiß vermutlich, dass ich zuletzt nicht besonders positiv über das Model Context Protocol (MCP) gesprochen habe
• Der Grund ist keine grundsätzliche Ablehnung der Idee, sondern dass MCP in der Praxis nicht so gut funktioniert, wie es beworben wird
• MCP hat zwei zentrale Schwächen
  • Es bietet keine echte Kompositionsfähigkeit (composable)
  • Durch den Bedarf an übermäßig viel Kontext verbraucht es mehr Kontext, als wenn man Code direkt schreibt und ausführt
• Das lässt sich mit einem einfachen Experiment zeigen
  • Wenn man zum Beispiel mit dem GitHub-MCP eine Aufgabe erledigt und danach dieselbe Aufgabe mit dem gh-CLI-Tool ausführt, nutzt Letzteres den Kontext deutlich effektiver und führt schneller zum gewünschten Ergebnis

But MCP is the Future! : Aber MCP ist doch die Zukunft?

• Ich möchte auf das Feedback eingehen, das ich zu dieser Position bekommen habe, also zu der Behauptung, dass Code der bessere Weg ist
• Ich habe MCP intensiv im Kontext von agentic coding erprobt und es genau dort bewertet, wo seine Grenzen am deutlichsten sichtbar werden
• Ein Feedback war: „Für allgemeine Codegenerierung braucht man MCP gar nicht unbedingt, weil Modelle darin ohnehin schon sehr gut sind.“ Gleichzeitig bekam ich auch die Meinung, dass MCP bei endnutzerorientierten Anwendungen in bestimmten Domänen sinnvoll sein könnte, etwa bei Automatisierungsaufgaben in Finanzunternehmen
• Eine weitere Ansicht lautet, dass man auf die Zukunft schauen müsse: Modelle würden Zugang zu mehr Tools bekommen und auch komplexere Aufgaben bewältigen können

• Mein aktuelles Fazit ist aber: Nach den Daten aus meinen Experimenten und meiner praktischen Erfahrung ist das heutige MCP immer schwieriger zu benutzen als direkt geschriebener Code
  • Der wichtigste Grund ist, dass MCP auf Inferenz angewiesen ist
  • Wenn man sich alle aktuellen Versuche ansieht, „mehr Tools an LLMs anzuschließen“, landet man am Ende immer bei einer Schicht, in der das LLM sämtliche Tools entgegennimmt und für die jeweilige Aufgabe filtert
  • Bislang wurde keine bessere Struktur oder Herangehensweise als diese vorgeschlagen

• Deshalb komme ich zu dem Schluss: Selbst in Sonderfällen wie domänenspezifischer Automatisierung für Nicht-Entwickler ist Codegenerierung am Ende immer die bessere Wahl in Bezug auf Kompositionsfähigkeit und Wiederverwendbarkeit

Replace Yourself With A Shellscript

• So kann man auf das Problem schauen: Ohne AI ist Code für Entwickler das Werkzeug, mit dem sie Probleme lösen
• Für Nicht-Entwickler ist Code schwierig, und viele Aufgaben, die Menschen manuell erledigen, lassen sich in Wirklichkeit mit Software automatisieren
• Das praktische Problem ist: Wer schreibt diesen Code? Wenn man in einer speziellen Umgebung arbeitet und selbst nicht programmieren kann, ist es schwer, Programmieren neu zu lernen oder darauf zu hoffen, dass jemand maßgeschneiderten Code dafür schreibt
• Natürlich gibt es Aufgaben, für die Inferenz (menschliches Urteilsvermögen/Flexibilität) wirklich nötig ist, aber die meisten wiederkehrenden und klar definierten Aufgaben lassen sich in der Praxis mit Code automatisieren

• Es gibt das alte Entwickler-Sprichwort, man solle „sich selbst durch ein Shellscript ersetzen“, und genau solche Automatisierung gibt es schon seit Langem
• Im Zeitalter von LLMs und Programmierung versucht man nun, sich statt durch ein Shellscript durch ein LLM zu ersetzen, doch dabei tauchen drei Probleme auf: Kosten, Geschwindigkeit und Zuverlässigkeit
• Bevor diese drei Probleme nicht gelöst sind, stellt sich die Frage nach Tools wie MCP noch gar nicht
• Entscheidend ist also zuerst sicherzustellen, dass Automatisierung tatsächlich korrekt und skalierbar funktioniert

Automation at Scale : Das Wesen großskaliger Automatisierung

• Der Kern von Automatisierung ist, wiederkehrende und wiederverwendbare Aufgaben als Code abzubilden
• Aufgaben, die man nur einmal erledigt und nie wieder, muss man nicht automatisieren. Automatisierung beginnt bei Dingen, die sich oft wiederholen und bei denen Maschinen echten Produktivitätsgewinn bringen
• In der Praxis macht man etwas ein- oder zweimal manuell, strukturiert dann den Ablauf und lässt die Maschine ihn tausendfach wiederholen

• Für solche wiederkehrende Automatisierung ist Code immer die beste Wahl
  • Wenn man ein LLM jedes Mal per „Inferenz“ arbeiten lässt, funktioniert das bei kleinen Aufgaben halbwegs, aber der Zeit- und Arbeitsaufwand für die Verifikation frisst den Automatisierungsvorteil am Ende wieder auf
  • Beispiel: Statt ein LLM direkt rechnen zu lassen, ist es viel sinnvoller, das LLM Python-Code schreiben zu lassen und die Berechnung dann durch diesen Code ausführen zu lassen; das erhöht sowohl Zuverlässigkeit als auch Skalierbarkeit
    • Mit Code kann man Formeln und Logik selbst prüfen, bei Bedarf direkt anpassen oder auch das LLM beurteilen lassen, ob dieser Ansatz korrekt ist
    • Da man sich keine Sorgen machen muss, dass Python falsch rechnet, wird klar, dass codebasierte Generierung bei Verifikation und Vertrauen überlegen ist

• Diese Logik geht über einfache Berechnungen hinaus und gilt auch für echte Entwicklungsarbeit
  • Beispiel: Vor Kurzem habe ich das komplette Format dieses Blogs von reStructuredText nach Markdown konvertiert
  • Ich hatte das lange aufgeschoben, teils aus Bequemlichkeit, vor allem aber, weil ich es einem LLM nicht direkt zur Konvertierung überlassen wollte: Ich hatte Sorge vor subtilen Auslassungen, Fehlern oder Verzerrungen des Kontexts
  • Am Ende habe ich das LLM daher nicht für die direkte Ausführung der Konvertierung verwendet, sondern es den Konvertierungscode erzeugen lassen und die Aufgabe dann durch Code gelöst

LLM → Code → LLM: Automatisierte Verifikation durch Iteration in der Praxis

• Im ersten Schritt bat ich das LLM, die Kernlogik für die Umwandlung von reStructuredText nach Markdown zu erzeugen
  • Nicht als bloße Konvertierung, sondern unter direkter Nutzung eines AST (Abstract Syntax Tree)
    • reStructuredText in einen AST parsen → in einen Markdown-AST umwandeln → als HTML rendern
    • So erhält man eine Zwischenstufe der Transformation, was den direkten Vergleich und die Verifikation des Ergebnisses erleichtert

• Im zweiten Schritt ließ ich das LLM auch ein Skript zum Vergleich des alten HTML mit dem neuen HTML schreiben
  • Es sollte die Diffs nach der Konvertierung analysieren und vor dem Vergleich kleine Unterschiede automatisch bereinigen, etwa Leerraum oder die Behandlung von Fußnoten
  • Außerdem sollte das LLM die Typen von Fehlern, die im Konvertierungsprozess tolerierbar sind, selbst mit berücksichtigen
  • Beispiel: Selbst wenn sich die HTML-Ausgabe von Markdown-/reStructuredText-Bibliotheken leicht unterscheidet, sollte das Skript nur echte Verluste oder inhaltliche Fehler herausfiltern

• Im dritten Schritt bat ich das LLM zusätzlich um ein Batch-Skript zur Analyse der Ergebnisse von Hunderten Dateien
  • Mit diesem Skript ließ ich den gesamten Dateibestand durchlaufen und führte iterative Verbesserungen (agentic loop) durch, bis die Unterschiede weiter zurückgingen

• Der Gesamtprozess sah so aus:
  • Zuerst lief alles nur auf etwa zehn Beispieldateien, wiederholt, bis die Differenzen deutlich reduziert waren
  • Sobald das Ergebnis zufriedenstellend war, wurde es auf alle Beiträge angewendet und in ungefähr 30 Minuten automatisch verarbeitet
  • Der entscheidende Punkt war nicht, dass das LLM die Konvertierung selbst „erfolgreich“ erledigt hätte, sondern dass ich den gesamten Ablauf als „Code“ verifizieren und reviewen konnte, weshalb er vertrauenswürdig war

• Zusätzlich gewann ich noch mehr Vertrauen, indem ich ein anderes LLM den erzeugten Code und die Änderungen prüfen und erklären ließ
  • Ich war sicher, dass die Umwandlung ohne Datenverlust mechanisch korrekt erfolgte, und Stichproben sowie Korrekturen waren jederzeit einfach möglich
  • Selbst im schlimmsten Fall wären nur kleinere syntaktische Fehler im Markdown entstanden, nicht aber eine Beschädigung des eigentlichen Inhalts

• Ein weiterer wichtiger Punkt ist, dass die Inferenzkosten bei diesem Ansatz konstant bleiben, sodass der Aufwand kaum davon abhängt, ob es 15 oder 150 Dateien sind
  • In der finalen Analysephase werden kleine Unterschiede bereits automatisch übersprungen, weshalb auch bei Massenkonvertierungen die Last der wiederholten Verifikation gering bleibt

MCP Cannot Do That

• Der Kern dieser langen Erklärung ist, dass die gesamte Konvertierungs- und Automatisierungs-Pipeline als „Code“ läuft
  • Menschliche Eingabe → Codegenerierung → LLM-Review → iterative Verbesserung: Diese Struktur lässt sich genauso auf allgemeine Aufgaben übertragen
• Ein typisches Beispiel für den MCP-Ansatz ist Playwright
  • Als Tool zur Fernsteuerung des Browsers liest es Seiten, interpretiert sie und klickt Buttons an; dabei wird in jedem einzelnen Schritt wiederholt Inferenz benötigt
  • Solche Aufgaben lassen sich tatsächlich nicht immer vollständig durch einen „Code-Ansatz“ ersetzen

• Aber wenn man die Seitenstruktur bereits kennt – etwa beim Testen einer eigenen App in Entwicklung –
  • ist es viel schneller und zuverlässiger, das LLM einfach ein Playwright-Python-Skript erzeugen zu lassen und dieses dann auszuführen
  • Hat man das Skript einmal erstellt, kann man es dutzend- oder hundertfach wiederholt ausführen, ohne weitere Inferenz
  • Man muss dann nicht jedes Mal den Bildschirm live interpretieren oder die Position von Buttons suchen, sondern kann den gesamten Automatisierungsablauf in einem Rutsch ausführen

• Der MCP-Ansatz erfordert bei jedem Schritt abstrakte Tool-Aufrufe und Inferenz, wodurch es sehr schwierig wird, das LLM dauerhaft korrekt arbeiten zu lassen, und auch das Debugging schwerfällt
  • Selbst wenn man etwa einen MCP-Client in ein Shellscript einbetten wollte, um Remote-Services effizient aufzurufen, merkt man schnell, dass dieser Ansatz in der Praxis sehr ineffizient und schwer umzusetzen ist

• Letztlich gilt: Ich bin ein Mensch und kein MCP-Client.
  • Code lässt sich leicht ausführen und debuggen, MCP-Aufrufe dagegen sind jedes Mal unsicher und wenig vertrauenswürdig
  • In der Praxis nutze ich eher die kleinen Tools, die das LLM während der Codegenerierung erstellt, etwa Snippets in Claude Code, als langfristige Werkzeuge meines Entwicklungsprozesses

Wohin führt dieses Fazit?

• Ehrlich gesagt weiß ich selbst nicht genau, wohin diese Entwicklung führt. Aber jetzt ist ein guter Zeitpunkt, darüber nachzudenken, wie sich codebasierte Generierung für „intentional agentic coding“ weiter verbessern lässt
• Das mag seltsam klingen, aber MCP funktioniert gelegentlich tatsächlich sehr gut. Trotzdem wirkt die aktuelle Struktur zu stark von „Inferenz“ abhängig und eher wie eine Sackgasse für skalierbare großflächige Automatisierung

• Deshalb muss man vermutlich klarer trennen und abstrahieren, in welchen Bereichen MCP seine Stärken hat und welche Rolle codebasierte Generierung spielen sollte
  • Dafür braucht es auch Versuche, bessere Sandboxes (sichere Ausführungsumgebungen) zu bauen und API-Designs so zu verändern, dass Agenten frei per fan out/fan in inferieren können
  • Ich halte eine Struktur für sinnvoll, bei der alles, was sich in Code abbilden lässt, so weit wie möglich als Code ausgeführt wird, und das LLM nach der Massenverarbeitung die Gesamtergebnisse bewertet und reviewt

• Und wenn man im Codegenerierungsprozess genügend Kontextinformationen ergänzt, sodass das LLM einem Nicht-Entwickler in natürlicher Sprache erklären kann, was das erzeugte Skript eigentlich tut, könnten auch Nicht-Entwickler diesen Automatisierungs-Workflow künftig leicht nutzen

• Zusammengefasst empfehle ich, statt auf MCP stärker und mutiger die Codegenerierungsfähigkeit von LLMs zu nutzen und neue Möglichkeiten auszuprobieren
• Wenn man LLMs Code direkt schreiben lässt, kann man viel mehr automatisieren, als wir uns derzeit vorstellen

Referenzmaterial

• Mein Agentic Coding Talk (Video)
• Drew Breunigs How to fix your context (Artikel)
• Manuel Odendahls MCPs are Boring (Video)

[bluems]

Ich stimme zu, aber ich denke, es geht eher um die Optimierung der Entwicklungs- bzw. Designrichtung als um ein MCP-Problem. Selbst bei derselben Funktion werden je nach MCP intern Code und Befehle erzeugt, wodurch unnötige Arbeit reduziert wird. Wenn man statt des GitHub-MCP ein gh cli-MCP oder ein Terminal-MCP verwendet, werden zwar Tokens verbraucht, aber deutlich weniger, und man kann denselben Effekt erzielen. Dieser Punkt scheint übersehen worden zu sein.

[GN⁺]

Hacker-News-Kommentare

• Ich stimme im Großen und Ganzen zu, dass die Richtung stimmt. Der Einsatz großer LLMs dient meist dazu, die Lücke zwischen zwei robusten Schnittstellen zu füllen. Der Kern der Zuverlässigkeit kommt nicht vom Ergebnis des LLM, sondern tatsächlich daher, dass diese Schnittstellen selbst nur bestimmte Konfigurationen zulassen.
  Die Ausgabe des LLM wird oft zwangsweise in stärker deterministische Werte umgewandelt, etwa Typen oder Primary Keys einer DB. Der Wert eines LLM hängt stark davon ab, wie gut bestehender Code und Tools die Daten, Logik und das Verhalten meiner Domäne modellieren.
  Persönlich empfinde ich LLMs inzwischen als ähnlich wie 3D-Drucker. Beide verbinden bei schnellem Prototyping Teile sehr schnell miteinander, aber wenn man Skalierbarkeit und Robustheit will, müssen letztlich Ingenieure oder das LLM selbst diese provisorischen Verbindungen durch deterministische Stützen aus Metall/Code ersetzen.
  Wie bei den früheren überzogenen Erwartungen an 3D-Drucker wirken auch LLMs so, als könnten sie alle betrieblichen Realitäten ersetzen, aber wirklich nützlich sind sie nur dann, wenn bestehende digitale Modellierung ein robustes Fundament bildet

  • Der überzogene Hype Cycle bei Drohnen oder VR war ähnlich. Alle sagten, wir würden Pakete mit Drohnen liefern und den Tag in VR verbringen, aber die tatsächlichen Einsatzfälle waren deutlich enger
  • Interessante Meinung, aber sie wirkt gegenüber LLMs zu konservativ. Tatsächlich werden LLMs bereits in großem Maßstab in Bereichen wie Deep Research oder Übersetzung eingesetzt und sind viel universeller verbreitet als 3D-Drucker
  • Ich stimme der Formulierung „die Richtung stimmt“ zu. In unserem Unternehmen verwenden wir oft den Begriff „directionally accurate“, auch wenn etwas nicht vollständig korrekt ist. Gemeint ist damit, dass es grob in die richtige Richtung geht

• Beim Einsatz von LLM-Tools habe ich etwas erkannt. Wenn man ein Problem in einer Sandbox so weit reduziert, dass das LLM darin iterativ Tools einsetzen kann, lässt sich dieses Problem per Brute Force lösen. Entscheidend ist dabei, solche Probleme zu identifizieren und die passende Sandbox, die zu verwendenden Tools und die Erfolgskriterien festzulegen.
  Auch dieser Prozess erfordert erhebliche Fähigkeiten und Erfahrung, ist aber deutlich höherwertig, als alles von Hand per Trial-and-Error auszuprobieren.
  Mir wurde das bei meinem „Assembly-Mandelbrot-Experiment“ klar.
  (Link zum Experiment: https://simonwillison.net/2025/Jul/…)

  • Das Definieren von Erfolgskriterien ist am Ende unverzichtbar. Wenn man nichts von Fraktalmathematik oder x86-Assembly versteht, bleibt zur Verifikation nur die visuelle Prüfung: „Sieht das Bild wie Mandelbrot aus?“
    Ideal wäre ein Bewertungskriterium in Form einer stetigen Funktion, mindestens aber eine quantitative Menge unterschiedlicher Eingaben mit erwarteten Ausgaben, damit echte Automatisierung möglich wird
  • Dieses Experiment ist wirklich interessant. Ich habe auch darüber nachgedacht, Probleme mit LLMs per Brute Force zu lösen.
    Zum Beispiel sind LLMs schwach bei TypeScript-Generics, aber wenn man den echten TSC laufen lässt, kann man immer wieder per Test validieren und so lange weiterprobieren, bis es passt. Die Wartbarkeit des Codes könnte leiden, aber theoretisch ist das eine sehr faszinierende Struktur.
    Außerdem kann Cursor TypeScript-Fehler sehen, sodass Cursor, wenn man nur Utility-Type-Tests erstellt, die Tests selbst schreiben und das Problem per einfacher iterativer Brute Force lösen könnte
  • Meiner Erfahrung nach ist es immer noch eine große Herausforderung, das LLM die für die Aufgabe passenden Tools verwenden zu lassen. Es ist ein bisschen so, als würde man einem Kind das Wäschewaschen beibringen – oft hat man einfach Lust, es selbst zu machen
  • Es ist wichtig, dem LLM den richtigen Kontext bereitzustellen. Wenn man zum Beispiel vordefinierte „kognitive Werkzeuge“ nutzt, um den Kontext anzureichern, verbessert sich die Leistung deutlich.
    Empfehlenswertes Repo: https://github.com/davidkimai/Context-Engineering/…
    Ich habe noch nicht alles gelesen, aber es ist ziemlich beeindruckend
  • Ich frage mich, ob dieser Tool-Loop in der Sandbox erfordert, Cloud-APIs mit hohem Tokenverbrauch zu nutzen.
    Ich überlege, ob das auch mit lokalen Modellen möglich ist oder ob man dafür ein Abo wie Claude Code Pro braucht.
    Das Mandelbrot-Experiment war zwar interessant, aber der Schwierigkeitsgrad unterscheidet sich doch etwas von einer realen komplexen kommerziellen Codebasis

• Ich glaube nicht, dass das ein Problem von MCP selbst ist. Auf dem aktuellen Niveau der KI ist eine Struktur mit einem Menschen in der Schleife deutlich überlegen.
  LLMs sind bei bestimmten Aufgaben stark, bleiben aber oft in lokalen Minima stecken. Wenn man daher im Webinterface zwischen „Schreib mir ein Programm → prüfen & Hinweise geben → testen“ hin- und herwechselt, wird die Qualität spürbar besser.
  Man kann 10.000 Zeilen chaotischen Code in 400 Zeilen klaren Code verwandeln. Im Moment ist das die Realität.
  Natürlich wollen viele Unternehmen oder Entwickler „den Programmierer selbst durch ein LLM ersetzen“, aber in der Praxis ist das noch nicht möglich.
  Der wirkliche Effekt liegt darin, die Arbeitsgeschwindigkeit von Programmierern um ein Mehrfaches zu steigern oder Einsteigern zu ermöglichen, über LLMs schnell produktiv zu arbeiten. Aber „agentic coding“ funktioniert noch nicht gut.
  Der richtige Einsatz von LLMs ist derzeit der als Kollege oder Assistent. In Wahrheit sind sie im Moment keine „KI-Agenten“ ohne autonomes Feedback

  • Ich bin selbst Produktentwickler und verantworte den gesamten Code allein; dabei nutze ich claude-code als Werkzeug. Ich hoffe, dass Claude irgendwann das gesamte Coding ersetzt, aber so weit sind wir noch nicht.
    Ich arbeite mit typsicheren, funktionalen und kompilierten Sprachen, daher muss ich die Ergebnisse ohnehin immer selbst lesen; bei weniger strengen Sprachen wäre ich noch besorgter.
    Trotzdem ist die Zeitersparnis groß. Besonders zufrieden bin ich damit, dass sich Aufgaben aufteilen lassen und große Ziele dadurch leichter handhabbar werden

• Ich habe tatsächlich Aufgaben mit GitHub MCP ausprobiert, und wenn ich dieselbe Arbeit mit der gh CLI mache, nutzt die gh CLI den Kontext viel effizienter und ist deutlich schneller.
  Ich habe im Ordner „devops“ eine Datei CLAUDE.md mit einer Sammlung gemeinsamer bash-Befehle.
  Wenn eine neue Aufgabe erledigt ist, lasse ich Claude ein Beispiel ergänzen, und bei ähnlichen Anfragen löst Claude sie danach in einem Durchgang.
  Inhalt der anfänglichen CLAUDE.md:

  • Diese Datei gibt Claude Code Anweisungen für die Code-Arbeit
  • Insbesondere dokumentiert sie GCP-bezogene DevOps-Befehle (Cloud Composer, Logging, Kubernetes, Cloud Run)
  • Wichtige Befehlsbeispiele: Umgebungsdetails anzeigen, DAGs verwalten, Airflow-Logs prüfen usw.
    (Konkrete Befehle zusammengefasst)
  • Manchmal verwirrt mich das. Wenn es schon eine Datei mit den nötigen Befehlen gibt, wirkt es ineffizient, nur darauf zu warten, dass die KI sie ausführt
  • Zur Information: Wenn man diesen Befehlsabschnitt zu einem einfachen stdio-MCP-Server macht und an Claude Code anschließt, kann man jede Aufgabe als Tool kapseln und auch ein Eingabeschema für Parameter definieren. Dafür gibt es bereits Open-Source-MCPServer-Projekte (zum Beispiel: https://github.com/inercia/MCPShell)
  • Ich nutze selbst eine ähnliche Befehlsdatei direkt im Emacs org-mode. Dort lässt sie sich leicht ein- und ausklappen und ist sehr effizient; außerdem kann man Code-Snippets (Shell, Elisp usw.) sofort ausführen
  • Ich frage mich, ob man dem LLM einfach Berechtigungen für privilegierte API-Aufrufe in Produktions-/Testumgebungen übergibt oder ob es nur Beispielbefehle erhält, die per Sanity Check geprüft werden können. Mich interessieren konkrete Anwendungsfälle
  • Ich bin mit einer ähnlichen Struktur gestartet, aber die claude.md wurde mit der Zeit immer größer und unhandlicher. Deshalb habe ich Custom Prompts als App umgesetzt und die Situation so verbessert, aber Apps sind deterministisch und können mit unbekannten Situationen schlecht umgehen. CC ist dagegen langsam, kann aber auch mit unbekannten Situationen umgehen.
    Daher wurde es zu einer Art selbstheilender Software, bei der ich bei Problemen dem Kommando noch Test-&-Fix-Anweisungen für die App hinzufüge

• Das bisher beeindruckendste MCP-Beispiel, das ich gesehen habe, ist tatsächlich Bruce Haumans clojure-mcp.
  Es gibt dem LLM (a) bash, (b) eine persistente Clojure-REPL und (c) strukturierte Editierwerkzeuge.
  Dadurch arbeitet es beim Bearbeiten von Clojure-Code viel effizienter als ein rein zeichenbasiertes Diff-Verfahren.
  Mit einer ordentlichen Test-Suite war es erstaunlich, wie nah Datei-Editieren, Reload und Test-Wiederholung an menschliches Arbeiten herankamen

  • Ich finde auch, dass clojure-mcp der coolste Einsatz von MCP ist, den ich bisher gesehen habe.
    Es unterstützt wichtige Funktionen wie Code-Debugging, das Auswerten einzelner Formen und die Dokumentation von Funktions-Rückgabetypen.
    Ich hatte ohnehin das Gefühl, dass Sprachen mit starker REPL bei solchen Funktionen deutlich überlegen sind, und als ich gesehen habe, was mit clojure-mcp möglich ist, hat sich mein Eindruck von KI stark verändert
  • Zur Referenz der offizielle Repo-Link: https://github.com/bhauman/clojure-mcp

• Das GitHub-CLI-Beispiel zeigt nicht alle Stärken von MCP.
  Tools wie gh CLI mit guter Dokumentationszugänglichkeit kann ein LLM leicht im Code nachbilden, daher ist es klar, dass es sie besser nutzt.
  Aber der eigentliche Vorteil von MCP zeigt sich bei internen Tools oder Nischen-APIs, zu denen es kaum Online-Dokumentation gibt.
  Man kann zwar auch alle Dokumente in den Kontext laden, aber in solchen Fällen ist MCP oft effizienter.
  Wenn man ein gut designtes MCP-Tool mit den richtigen Inputs nutzt, sinkt die Last für das LLM beim Verstehen der API, bei Authentifizierung und beim Umgang mit Edge Cases erheblich.
  Für GitHub braucht man MCP vielleicht nicht unbedingt, aber in Umgebungen mit internen oder unvollständigen APIs sind vorab gebaute MCP-Tools deutlich wirkungsvoller

  • Auch MCP ist letztlich ein Ansatz, Dokumentation in den Eingabekontext des LLM zu injizieren. In Umgebungen, die das LLM gut kennt (Python, JavaScript, bash usw.), ist es besser, seine bekannten Vorgehensweisen zu nutzen, statt MCP-Tools aufzurufen; im Gegenteil verbrauchen Tool-Definitionen nur zusätzlichen Kontext.
    Zum Beispiel liegt bei sonnet4 die Grenze schon bei mehr als 15 Tools. Selbst das offizielle Playwright-MCP verbraucht bereits Tool-Kapazität
  • Zwar vereinfacht ein MCP-Server Dinge wie Authentifizierung, aber man kann entgegenhalten, dass man die interne API von Anfang an genauso hätte entwerfen können.
    Am Ende könnte der einzige Vorteil von MCP darin bestehen, noch einmal zu bestätigen, dass die API einfach unnötig kompliziert war

• Zum Playwright-Beispiel:
  Auch ich habe diese Woche einen Agenten auf Basis des Playwright-MCP-Servers gebaut und dann festgestellt, dass er langsam, token-ineffizient und unzuverlässig ist, woraufhin ich wieder zu direkten Playwright-Aufrufen zurückgekehrt bin.
  Der MCP-Server eignet sich gut zum Testen dessen, was möglich ist, aber in der Praxis sind API-Aufrufe effizienter und stabiler.
  Hier mein Beispiel für einen persönlichen LinkedIn-Agenten sowie die Demo:

  • Projekt: https://github.com/pamelafox/personal-linkedin-agent
  • Demo: https://www.youtube.com/live/ue8D7Hi4nGs
  • Auch für mich war die Playwright-MCP-Implementierung eine übertriebene Lösung. Ich sehe sie eher als Referenzimplementierung, die einen Teil der Playwright-API nur eingeschränkt nachbildet.
    LinkedIn ist als Plattform bekannt, die Automatisierung extrem schwer macht; daher würde mich interessieren, ob es beim Bau eines persönlichen LinkedIn-Agenten Schwierigkeiten oder Einschränkungen gab

• Eigentlich habe ich das Gefühl, dass ein Terminal völlig ausreicht.
  Ich habe monatelang täglich MCP genutzt, verwende jetzt aber nur noch einen einzigen iTerm2-basierten MCP-Server (Terminal).
  Bei Bedarf gibt es zwar eine OpenAPI-Spec, aber in der Praxis kann man mit Shell-Befehlen und curl fast alles erledigen

  • Ich habe ebenfalls zum ersten Mal verstanden, wie weit die Grenzen dessen reichen, was mit bash möglich ist, als ich gesehen habe, wie ein LLM die eingebauten Tools der bash shell nutzt

• Der Einwand „zu viel Kontext nötig“ lässt sich in Wahrheit meist schon durch gute Standardwerte im Initial Prompt lösen.
  Große Tools einschließlich Claude Code und Gemini CLI unterstützen das alle
  Es ist zwar nicht der beste Ansatz, dem LLM einfach die komplette Tool-Liste zu geben und es selbst auswählen zu lassen,
  aber moderne LLMs werden ständig besser, und ich hatte tatsächlich nie große Schwierigkeiten damit, die passende MCP-Funktion auswählen zu lassen.
  Auch Probleme bei Kosten, Geschwindigkeit und Zuverlässigkeit sind

  • Kosten: In letzter Zeit wird es immer günstiger. Das Preis-Leistungs-Verhältnis ist tatsächlich erstaunlich.
  • Geschwindigkeit: Man kann mehrere Aufgaben gleichzeitig ausführen lassen, daher ist es nicht ineffizient.
    Man muss seine Zeit nicht direkt in die Unterhaltung investieren
  • Zuverlässigkeit: Hängt stark von der Qualität des Prompts ab.
    Als aktuelles Beispiel hat ein LLM für mich große Mengen externer Tools wie Notion, Linear, git und GitHub-PR-/CI-Logs automatisch verarbeitet,
    und ich musste nur ein einziges Mal das PR-Review machen.
    Die Kosten lagen unter 1 Dollar
  • Je mehr MCP-Tools es gibt, desto größer wird der Kontextverbrauch im Initial Prompt.
    Im Gegenteil kann das Hinzufügen weiterer Tools zu ernsthaften Einschränkungen führen, weil am Anfang immer mehr Informationen nötig werden
  • Beim Kostenproblem sinken die tatsächlichen Kosten nicht unbedingt immer weiter,
    sondern sind nur noch verborgen; kostenlose oder günstige Promotionsmodelle halten nicht lange.
    Zum Beispiel führt Cursor nun einen Tarif von 200 Dollar pro Monat ein, und die Servicequalität günstiger Tarife verschlechtert sich.
    Sobald die Gratis-Promotions enden, kehrt alles auf das ursprüngliche Niveau zurück

• Ich arbeite mit Julia und profitiere von einer Umgebung mit langlebigen Sessions.
  Da Funktionen beim ersten Ausführen kompiliert werden, habe ich ein MCP gebaut, damit Claude Code Code an einen persistenten Julia-Kernel (Jupyter) senden kann.
  Dadurch laufen Testcodes deutlich schneller, und CC nutzt statt eigens gebautem bash besser die bereits vorhandenen Funktionen der Codebasis.
  Laut CCUsage ist der Tokenverbrauch fast um 50 % gesunken.
  Es musste nicht zwingend MCP sein, aber der Punkt ist, dass es einfacher ist, Claude eine „bestimmte Fähigkeit“ an die Codebasis anzuhängen, als eigens dafür laufend Custom Code zu schreiben

  • Ich frage mich, ob Claude sich nur deshalb dafür entscheidet, direkt Code an den Kernel zu senden statt eigens gebautes bash zu verwenden, weil es möglich ist, direkt Code an den Kernel zu schicken