Ok, der Reihe nach: Im September habe ich geschrieben, MCP sei langsam, und das sei kein Bug, sondern der Bauplan. Im Oktober haben wir dann gebaut, aus 33 Werkzeugen sind 48 geworden, und dabei haben wir etwas gelernt, das ich damals noch nicht wusste: Die Dosis wird kleiner, nicht grösser. Aufgeschrieben hätte ich das vermutlich erst irgendwann. Dann hat Dirk Rottmar, Software-Architekt für KI-Systeme, unter dem Artikel einen Kommentar hinterlassen, der genau das in zwei Zeilen sagt: „MCP ist ein Tooling, das sehr bewusst und sparsam eingesetzt werden sollte. Es ist Magic! Wie mit allem im Leben: Die grossartigen Dinge in kleiner Dosis geniessen. Der Rest ist deterministisch, absolut konsequent, auch wenn es weh tut." Der Satz hat mich bewegt, den aktuellen Stand bei uns zu dokumentieren. Hier ist er.
Der Satz, der den Oktober zusammenfasst
Was mir an dem Satz gefällt, ist das „auch wenn es weh tut". Denn genau da hat es im Oktober gehakt, bei jedem einzelnen Umbau. Wer einmal erlebt hat, wie ein Modell aus einer vagen Anfrage den richtigen Werkzeugaufruf macht, will das überall. Es fühlt sich an wie Fortschritt. Und jedes Mal, wenn man eine solche Stelle wieder in einen festen Funktionsaufruf zurückbaut, fühlt es sich an wie ein Rückschritt. Ist es nicht. Es ist die Stelle, an der man aufhört, das Modell für Dinge zu bezahlen, die es nicht entscheiden muss.
Was ich im September versprochen habe
Im September standen sechs Punkte am Ende des Artikels: Werkzeuge erst laden, wenn sie gebraucht werden. Das Modell schreibt ein Script statt dreissig Runden. Kein Zustand im Server. Kleine, klare Werkzeuge. Daten filtern, bevor das Modell sie sieht. Timeouts und ein Script, das aufräumt. Ich habe damals geschrieben, so bauen wir es gerade um. Ehrlich gesagt war das ein Plan, kein Zustand. Jetzt, sechs Wochen und fünfzehn Werkzeuge später, kann ich sagen, was davon gehalten hat.
Inzwischen hat es jemand gemessen
Das Beste, was seither passiert ist: Jemand hat die Debatte gemessen, statt sie zu führen. Arize hat im Frühjahr 500 Läufe gemacht, gleiches Modell, gleicher Agent, gleiche 25 GitHub-Aufgaben in vier Schwierigkeitsstufen, nur das Tooling anders: der offizielle GitHub-MCP-Server gegen die Kommandozeile mit einem Skill, in zwei Varianten, und als vierter Arm die blanke Shell ohne alles.
| Ergebnis | MCP | Shell + Skill |
|---|---|---|
| Korrektheit, alle Stufen | 0,83 | 0,83 |
| Kosten, schwerste Stufe | rund sechsmal höher | Basis |
| Dauer, schwerste Stufe | rund fünfmal länger | Basis |
| Aufrufe pro schwerer Aufgabe | etwa 12 | etwa 5 |
| Blieb bei den erlaubten Werkzeugen | 33 % | über 99 % |
Die Korrektheit ist gleich. Jeder kommt ans Ziel. Aber bei den komplexen Aufgaben, „für jeden Meilenstein den Fertigstellungsgrad, dann die häufigste Label-Kombination", kostet MCP das Sechsfache und braucht das Fünffache an Zeit. Nicht weil der Server schlecht ist. Weil ein Server mit festen Endpunkten nicht komponieren kann. Es gibt keinen Endpunkt für diese Frage, also zerlegt das Modell sie in zwölf Aufrufe, jeder kommt als ausführliches JSON zurück, jeder nimmt den ganzen bisherigen Kontext wieder mit. Die Shell kann komponieren, mit Pipes, grep, sort. Und der schönste Befund: Der MCP-Agent war angewiesen, nur MCP zu benutzen. In zwei Dritteln der schweren Fälle hat er es ignoriert, hat das JSON auf die Platte geschrieben und in der Bash weitergemacht. Das Modell selber hat gemerkt, dass das Protokoll nicht reicht.
Aber, und das ist der Teil, den die „MCP ist tot"-Fraktion weglässt: Bei „Branch anlegen und Pull Request öffnen" gewinnt MCP klar, acht Aufrufe statt 22, ein Drittel der Kosten. Weil es dafür genau die passenden Endpunkte gibt. Die Form der Aufgabe entscheidet, nicht das Protokoll. Und der vierte Arm, die blanke Shell ohne Skill, war bei der Korrektheit sogar am besten, weil das Modell die GitHub-Kommandozeile aus dem Trainingsmaterial kennt. Für die eigene Firmenschnittstelle gilt das nicht. Die kennt kein Modell. Da braucht es entweder einen Skill oder MCP, oder man gibt auf.
Die eine Frage pro Funktion
Was wir aus dem September und aus diesen Zahlen gemacht haben, ist eine einzige Frage, die wir jetzt bei jedem der 48 Werkzeuge stellen, bevor sie einen Kanal bekommt: Muss das Modell hier etwas entscheiden, oder tippt es nur den Aufruf?
Bei den meisten Funktionen ist die Antwort unbequem klar. „Ticket lesen", „Status setzen", „Tests laufen lassen", „Commit prüfen": Da entscheidet das Modell nichts. Es weiss, was es will, und formuliert den Aufruf. Jedes Mal, wenn es das über ein Protokoll tut, zahlen wir Kontext für die Beschreibung, eine Runde für den Aufruf, und Kontext für die Antwort. Dreimal bezahlt für eine Entscheidung, die keine war. Diese Funktionen gehören in den Prozess, als normaler Aufruf, deterministisch. Das ist das „auch wenn es weh tut".
Drei Kanäle statt eines Protokolls
Aus der Frage folgen drei Kanäle. So würde ich es heute jedem raten, der mehr als zwanzig Werkzeuge hat, und so halten wir es:
Deterministisch, ohne Modell. Alles, bei dem die Entscheidung schon gefallen ist, wenn die Funktion gerufen wird. Lesen, setzen, prüfen, protokollieren. Ein Funktionsaufruf im Prozess, Regel vor Modell. Kostet keinen Kontext, hat keine Latenz, kann nicht halluzinieren. Das ist der grösste Kanal, und er wächst am schnellsten, weil jede neue Funktion zuerst hier landet und erst wegzieht, wenn sie beweist, dass sie ein Modell braucht.
Script statt Runden. Alles, was komponiert werden muss: holen, filtern, verknüpfen, zusammenfassen. Das Modell schreibt einmal zehn Zeilen gegen eine typisierte Bibliothek, das Script läuft ohne Modell, und zurück kommen die drei Zeilen, die zählen, nicht die zehntausend. Das ist genau die Stelle, an der MCP bei Arize eingebrochen ist, und genau die, an der das Modell sich selber in die Bash geflüchtet hat. Wir geben ihm die Bash gleich, aber mit Geländer: eigene Bibliothek, fester Ordner, Timeout, kein Netz nach draussen.
MCP, klein dosiert. Das, was wirklich ein Werkzeug ist: remote, mit eigener Anmeldung, mit Zustand über mehrere Schritte, nicht im Trainingsmaterial. Und das, bei dem das Modell wirklich wählen muss, welches von mehreren Werkzeugen passt. Hier ist das Protokoll gut, weil es Auth, Entdeckung und Berechtigungen mitbringt, die eine Kommandozeile nicht hat. Das sind die paar Fälle, wo die Magie den Preis wert ist.
Was wir im Oktober gelernt haben
Vier Dinge, die nicht im September-Artikel standen, weil ich sie noch nicht wusste.
Erstens: Die Dosis sinkt, während die Zahl steigt. Von 33 auf 48 Werkzeuge, und der Anteil, der über das Protokoll läuft, ist kleiner geworden, nicht grösser. Das war nicht geplant. Es ist passiert, weil jede neue Funktion die Frage von oben beantworten musste, und die meisten mit Nein. Ich hatte im September erwartet, dass wir das Protokoll besser nutzen lernen. Stattdessen haben wir gelernt, es seltener zu nutzen.
Zweitens: Werkzeugauswahl ist eine Aufgabe für ein kleines Modell, nicht für das grosse. Im September habe ich geschrieben, ein kleines Modell soll aus der Anfrage die zwei bis vier passenden Werkzeuge auswählen, bevor das grosse liest. Das Prinzip hält, und es hat einen Nebeneffekt, den ich nicht erwartet habe: Sobald die Auswahl vor dem grossen Modell passiert, ist es fast egal, wie die Werkzeuge dahinter angebunden sind. Das grosse Modell sieht zwei Beschreibungen statt 48, und ob die zwei über MCP oder als Funktion kommen, merkt es nicht. Der Kontextfresser war nie das Protokoll. Es war die Liste.
Drittens: Das Script ist das bessere Protokoll, aber nur mit Geländer. Ein Modell, das Code gegen unsere Bibliothek schreibt, ist schneller und billiger als jede Folge von Aufrufen. Es ist auch gefährlicher, wenn der Ordner, in dem das Script läuft, nicht sauber abgegrenzt ist. Nach dem Cursor-Vorfall vor einer Woche gilt bei uns: fester Ordner, keine Netzverbindung nach draussen, Timeout, und das Script wird protokolliert, bevor es läuft, nicht danach. Das Geländer kostet einen Nachmittag. Ohne Geländer ist Kanal 2 kein Kanal, sondern ein Loch.
Viertens: Das Modell weiss selber, wann das Protokoll nicht reicht. Der Arize-Befund, dass der Agent in zwei Dritteln der schweren Fälle die Anweisung ignoriert und in die Bash gegangen ist, deckt sich mit dem, was wir im Log sehen. Wenn ein Modell anfängt, Umwege zu bauen, um ein Werkzeug herum, ist das kein Disziplinproblem des Modells. Es ist ein Hinweis, dass das Werkzeug die falsche Form hat. Wir lesen diese Umwege jetzt als Befund, nicht als Fehler, und bauen die Funktion um.
Was die Spec inzwischen kann
Fairerweise: Das Protokoll hat sich bewegt. Die Revision vom 28. Juli ist inzwischen stabil, und sie räumt genau dort auf, wo ich im September Problem drei beschrieben habe. Keine Sitzungen mehr auf Protokollebene, kein Session-Header, jede Anfrage kann von jeder Serverinstanz beantwortet werden. Lange Aufgaben sind eine Erweiterung mit Abfragen statt blockierender Aufrufe. Roots, Sampling und Logging sind abgekündigt. Volle JSON-Schema-Unterstützung für die Eingaben. Das ist das Protokoll, das für den Server gebaut ist, nicht mehr für den Laptop.
Es ändert nichts an der Dosis. Ein zustandsloses MCP ist immer noch ein Aufruf pro Runde mit einer Beschreibung im Kontext. Es ist jetzt ein besseres Werkzeug für Kanal 3. Es ist kein Argument, Kanal 1 und 2 wieder hineinzuziehen.
Was bleibt
Der September-Artikel hatte recht in der Diagnose und war zu früh in der Therapie. MCP ist langsam, weil es für wenige Werkzeuge mit Zuschauer gebaut wurde; das stimmt noch. Aber die Antwort darauf war nicht, das Protokoll besser zu nutzen. Die Antwort war, es seltener zu nutzen und die Frage zu stellen, die Dirk in einem Satz hatte und ich in zwölf Minuten: Muss das Modell hier entscheiden? Meistens nicht. Dann deterministisch. Konsequent. Auch wenn es weh tut.
48 Werkzeuge, drei Kanäle, eine Frage. Der grösste Kanal braucht kein Modell. Der zweite braucht es einmal, für zehn Zeilen Script. Der dritte ist MCP, und er ist klein, und das ist gut so. Die Magie in kleiner Dosis. Der Rest deterministisch. Dirk hat es in einem Satz gesagt, der Oktober hat es uns beigebracht, und 500 Läufe haben es nachgemessen.
Quellen
Arize, Mai 2026 (aktualisiert Oktober). MCP vs. CLI Skills for agents: what our eval found. 500 Läufe, Claude Opus 4.6, Claude Agent SDK, 25 GitHub-Aufgaben in vier Stufen, vier Arme. Korrektheit 0,826 bis 0,845; schwerste Stufe MCP über sechsmal teurer, fünfmal langsamer, etwa zwölf Aufrufe gegen fünf; Werkzeugtreue MCP 0,33 gegen über 0,99; Gegenbeispiel Branch und PR. Daten offen auf GitHub.
MCP-Spezifikation, Revision 2026-07-28. blog.modelcontextprotocol.io. Zustandsloser Transport ohne Session-ID, Tasks als Erweiterung mit Abfrage, Roots/Sampling/Logging abgekündigt, JSON Schema 2020-12.
Die Debatte. MCP is dead, long live the CLI (Februar 2026), Milvus: Is MCP dead? als Gegenstimme.
Mein Artikel vom September. MCP ist langsam. Das ist kein Bug, das ist der Bauplan. Die sechs Punkte am Ende sind der Plan, an dem ich hier messe.
Stand und Vorbehalt. 7. November 2026. Die Arize-Zahlen stammen aus einer Messung, die das Unternehmen selber gemacht hat, mit offenen Daten; ich habe sie nicht nachgerechnet. Der Kommentar von Dirk Rottmar ist mit seinem Einverständnis zitiert, in Schweizer Schreibweise, mit Dank. Die Angaben zu NeoCoder sind unsere eigenen, Stand heute, und die Zahl der Werkzeuge wächst weiter.
Geschrieben von mir. Die Gedanken, die Werte, die Learnings, die Fehler: alles meins. Grammatik und Rechtschreibung korrigiert ein eigenes Twin-Modell, das auf meinen Texten trainiert ist. Manchmal wird daraus ein Mix. Ich lese natürlich alles nochmal, aber niemand ist unfehlbar. Was drin bleibt, ist dann auch von mir.