Jetzt mal ganz ehrlich: MCP ist langsam. Nicht ein bisschen, nicht manchmal, sondern von der Konstruktion her. Ich sage das nicht aus der Ferne. Wir haben in NeoCoder 33 Tools über MCP angebunden, und ich sitze seit Monaten davor. Was mir dabei aufgefallen ist, steht inzwischen auch bei denen, die das Protokoll erfunden haben. Im Juli haben sie es umgebaut, so gründlich, dass alte und neue Implementierungen nicht mehr zusammenpassen. Das ist kein Vorwurf. Das ist die ehrlichste Form von „wir haben es anders gedacht, als es dann gebraucht wurde". Meine Meinung dazu, mit Belegen.
Was MCP ist, in drei Sätzen
Das Model Context Protocol, Ende 2024 von Anthropic veröffentlicht, ist ein Standard dafür, wie ein Modell Werkzeuge findet und aufruft: Dateien lesen, eine Datenbank abfragen, ein Ticket anlegen. Ein Server beschreibt seine Werkzeuge, der Client lädt die Beschreibungen ins Modell, das Modell ruft auf, JSON hin, JSON zurück. Die Idee ist gut: Einmal anbinden, überall nutzbar. Das SDK wird inzwischen fast hundert Millionen Mal im Monat heruntergeladen, es gibt über zehntausend Server. Der Standard hat gewonnen. Und genau deshalb lohnt es sich, hinzuschauen, wo er nicht funktioniert.
33 Tools, und was dann passiert
In NeoCoder hängen 33 Werkzeuge am Modell: Repos lesen, Tickets anlegen, Tests starten, Deployments prüfen, Logs holen, Dokumente durchsuchen, und so weiter. Jedes davon hat eine Beschreibung mit Parametern, Typen, Rückgabewerten. Alle 33 Beschreibungen gehen bei jeder Anfrage in den Kontext. Bevor das Modell die Frage liest, hat es schon ein kleines Handbuch gelesen. Nach meiner Rechnung sind das zehn- bis zwanzigtausend Tokens, jedes Mal, für Werkzeuge, von denen es in diesem Moment zwei braucht.
Dann die Aufrufe. Ein Sprint-Review über MCP sieht so aus: Modell liest, ruft „Tickets holen", wartet. Antwort kommt, Modell liest die Antwort, ruft „Commits holen", wartet. Antwort, lesen, „Tests holen", warten. Zehn Werkzeuge sind zehn Runden, und jede Runde geht einmal durch das Modell, mit dem ganzen Kontext. Was ein Script in zwei Sekunden macht, dauert so eine Minute und kostet das Zehnfache.
Problem eins: Der Kontext ist voll, bevor die Frage kommt
Das ist das Problem, das Anthropic selber am deutlichsten beschrieben hat. Im November 2025 haben ihre Ingenieure einen Artikel veröffentlicht, in dem sie es vorrechnen: Wenn alle Werkzeugbeschreibungen vorab in den Kontext geladen werden, braucht ein Agent mit vielen Werkzeugen Hunderttausende Tokens, bevor er die Anfrage überhaupt gelesen hat. Ihr Beispiel: 150'000 Tokens für die Werkzeuge, 2'000 Tokens, wenn das Modell nur liest, was es braucht. Das sind 98,7 Prozent weniger.
Und das zweite, das man leicht übersieht: Jedes Zwischenergebnis läuft durch das Modell. Ihr Beispiel ist ein Protokoll aus einem Meeting, das aus einem Dokument geholt und in ein CRM geschrieben wird. Der ganze Text geht einmal ins Modell hinein und einmal wieder heraus, 50'000 Tokens für nichts, und bei grossen Dokumenten reisst das Kontextfenster. Bei uns ist das derselbe Effekt mit Logs: Zweitausend Zeilen Log gehen ins Modell, damit es die drei Zeilen findet, die zählen.
Problem zwei: Jeder Aufruf ist eine Runde
MCP kennt keinen Ablauf, nur Aufrufe. „Hole die Tickets, filtere die offenen, hole zu jedem die Commits, prüfe, ob Tests dazu grün sind" ist für ein Script eine Schleife. Für MCP sind es dreissig Einzelaufrufe, jeder mit einer Runde durch das Modell, und das Modell muss sich bei jeder Runde neu merken, wo es war. Das ist nicht nur langsam. Es ist der Punkt, an dem Modelle Fehler machen, weil sie Daten von Runde zu Runde abschreiben, statt sie einmal zu verarbeiten.
Und es kostet Zeit auf eine Art, die man nicht am Token sieht: „Time to first token" pro Runde. Wenn das Modell eine Bedingung auswerten muss, ob dieses Ticket relevant ist, wartet man auf eine Modellantwort für etwas, das eine Zeile Code in einer Mikrosekunde entscheidet. Anthropic schreibt das selber so: Eine Bedingung im Code auszuführen ist schneller, als auf ein Modell zu warten, das ein If auswertet.
Problem drei: Für den Laptop gebaut
Das ist der Teil, der im Juli öffentlich wurde. Das ursprüngliche MCP war zustandsbehaftet: Eine Sitzung pro Verbindung, der Server muss sich merken, wer da ist, was er kann, wo er steht. Auf dem Laptop ist das harmlos. Auf einem Server hinter einem Loadbalancer ist es Gift: Welcher Server hält die Sitzung? Was passiert, wenn er neu startet? Wie routet man eine Anfrage, deren eigentliche Operation tief in einem JSON-Body vergraben ist, den kein Netzwerkgerät liest?
Bei uns hat das dazu geführt, dass wir eine Zustandsschicht daneben gebaut haben. Der Standard war dann nur noch der Transport, und der Sinn eines Standards ist weg, wenn jeder seine eigene Schicht darüberlegt. Eine Studie der Polytechnique Montréal, die im März 2026 die erste grosse Fehler-Taxonomie für MCP-Server veröffentlicht hat, bestätigt das aus der Breite: fünf Fehlerklassen, darunter Performance und Stabilität, mit Hängern, langsamen Operationen und Timeouts unter Last. Das sind keine Anfängerfehler. Das sind die Fehler, die ein Protokoll erzeugt, das für eine andere Umgebung gedacht war.
Was die Revision vom Juli ändert
Am 28. Juli 2026 haben die Maintainer die grösste Revision seit dem Start finalisiert. Die Sitzungen auf Protokollebene sind weg; jede Anfrage trägt ihre Metadaten selber, so wie im Rest des Internets. Die Routing-Information steht jetzt auch in HTTP-Headern, damit Netzwerkgeräte sie lesen können, ohne den JSON-Body zu öffnen. Wenig genutzte Funktionen wurden gestrichen, Sampling, Roots, das eigene Logging. Ein Anthropic-Ingenieur hat es im Livestream so zusammengefasst: Vieles von dem, was MCP ausgemacht hat, ist weg. Und wer sein eigenes MCP gebaut hat, hat viel Arbeit vor sich, denn alt und neu sind nicht kompatibel.
Ich finde das richtig. Und ich finde es bemerkenswert, dass es so lange gedauert hat, denn zustandslos ist seit zwanzig Jahren der Standard für alles, was skalieren muss. Aber es zeigt auch: Das MCP, das die meisten heute einsetzen, ist das alte. Die Migration kommt erst.
Was ich in der Umsetzung anders mache
Das Protokoll selber ändere ich nicht, das machen die Maintainer. Aber wie man es einsetzt, entscheidet man selber. So würde ich es bauen, und so bauen wir es gerade um.
Werkzeuge erst laden, wenn sie gebraucht werden. Nicht 33 Beschreibungen im Kontext, sondern eine Suche: Das Modell fragt „was gibt es für Tickets", bekommt drei Namen, lädt die Beschreibung von einem. Anthropic nennt das Progressive Disclosure. In Claude Code gibt es das inzwischen eingebaut, mit über 85 Prozent weniger Kontext. Bei uns wird das ein kleines Modell, das aus der Anfrage die zwei bis vier passenden Werkzeuge auswählt, bevor das grosse Modell überhaupt liest. Das ist der Umbau, der gerade läuft.
Das Modell schreibt ein Script, das die Aufrufe macht. Statt dreissig Runden eine: Das Modell schreibt zehn Zeilen, die Tickets holen, filtern, Commits holen, Tests prüfen, und gibt nur das Ergebnis zurück. Die Werkzeuge sind dann Funktionen in einem Ordner, nicht Einträge im Kontext. Das ist genau das, was ich beim Avatar beschrieben habe: einmal ein generisches Script, das danach ohne Modell läuft. Die Latenz fällt um eine Grössenordnung, und die Logs gehen nie durch das Modell, nur die drei Zeilen, die zählen.
Kein Zustand im Server. Jede Anfrage trägt, was sie braucht. Das ist das, was die Revision jetzt vorschreibt, und es ist der Grund, warum die Zustandsschicht daneben wieder wegkommt: Sie skaliert nicht. Idempotenz-Schlüssel pro Aufruf, damit ein Wiederholen nichts doppelt anlegt. Der Server darf jederzeit sterben.
Kleine, klare Werkzeuge. Keine grossen. „Mach alles mit dem Ticket" ist ein schlechtes Werkzeug. „Ticket lesen", „Ticket-Status setzen", „Kommentar anhängen" sind gute. Kleine Werkzeuge haben kurze Beschreibungen, das Modell wählt sicherer, und im Script lassen sie sich kombinieren. Dieselbe Regel wie bei den Micro-Modellen: Jedes kann nur seine Aufgabe, jedes versteht man.
Daten filtern, bevor sie das Modell sehen. Das Script filtert die zehntausend Zeilen auf fünf. Und wo Kundendaten drin sind, ersetzt die Schicht dazwischen sie durch Platzhalter, bevor das Modell sie sieht, und setzt sie erst beim nächsten Werkzeug wieder ein. Das ist die Pseudonymisierung aus dem Testdaten-Artikel, nur an anderer Stelle. Anthropic beschreibt in ihrem Artikel genau dieses Muster.
Timeouts und ein Script, das aufräumt. Jeder Aufruf hat eine Frist. Und daneben läuft das kleine Script, das Prozesse prüft und stoppt, die zu lange brauchen. Ich habe es im Regeln-Artikel beschrieben und man hat mich dafür belächelt. Die Taxonomie aus Montréal listet genau diese Hänger als eigene Fehlerklasse.
Man sieht das Muster. Alles davon ist alte Software-Technik: Lazy Loading, zustandslose Dienste, kleine Schnittstellen, Filtern nahe an der Quelle, Timeouts. Nichts davon ist neu. Neu ist nur, dass man es bei Modellen wieder vergessen hat, weil die erste Demo auf dem Laptop so gut aussah.
Belege
Ich stelle hier keine Behauptungen ohne Quelle auf, das habe ich mir vorgenommen. Die Zahlen und Aussagen oben stammen aus diesen Texten, alle im September 2026 nachgelesen:
Anthropic Engineering, „Code execution with MCP", 4. November 2025. Beschreibt die beiden Kernprobleme (Werkzeugbeschreibungen füllen den Kontext, Zwischenergebnisse laufen durch das Modell) und das Beispiel 150'000 zu 2'000 Tokens, 98,7 Prozent. Empfiehlt Code statt Einzelaufrufe, Progressive Disclosure, Filtern vor dem Modell, Platzhalter für sensible Daten. anthropic.com/engineering/code-execution-with-mcp
The Register, „Model Context Protocol prepares to break with its stateful past", 23. Juli 2026. Bericht zur Revision 2026-07-28: Sitzungen entfernt, Metadaten pro Anfrage, Routing in HTTP-Headern, Sampling und Roots gestrichen, nicht rückwärtskompatibel, grosser Aufwand für eigene Implementierungen. Zahlen zu SDK-Downloads und Serveranzahl. theregister.com
Taraghi, Morovati, Khomh (Polytechnique Montréal), „Real Faults in Model Context Protocol (MCP) Software: a Comprehensive Taxonomy", arXiv, März 2026, revidiert August 2026. Erste grosse Fehler-Taxonomie für MCP-Server mit fünf Fehlerklassen, bestätigt durch eine Umfrage unter Praktikern. arxiv.org/abs/2603.05637
Eigene Erfahrung. 33 Werkzeuge in NeoCoder über MCP, seit Anfang 2026 im Betrieb. Die Token-Schätzung pro Anfrage ist meine Rechnung, keine Messung, und steht deshalb als Schätzung im Text.
Was bleibt
MCP bleibt. Als Beschreibung, welche Werkzeuge es gibt und wie man sie aufruft, ist es nützlich, und nach der Revision auch auf Servern brauchbar. Was nicht bleibt, ist die Idee, dass das Modell jedes Werkzeug einzeln aufruft und jedes Ergebnis liest. Das war die Demo. Der Betrieb sieht anders aus: Das Modell entscheidet, ein Script arbeitet, und das Modell sieht nur, was zählt.
MCP ist langsam, weil es so gebaut wurde: alle Werkzeuge im Kontext, jeder Aufruf eine Runde, Zustand im Server. Das sagen inzwischen die Erfinder selber, mit Zahlen, und sie haben das Protokoll im Juli umgebaut. Was ich anders mache: Werkzeuge erst laden, wenn sie gebraucht werden, das Modell schreibt ein Script statt dreissig Aufrufe, kein Zustand im Server, kleine Werkzeuge, filtern vor dem Modell, Timeouts. Alte Technik. Sie funktioniert immer noch.
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.