Für ein Protokoll, das kaum zwei Jahre alt ist, hatte das Model Context Protocol eine ungewöhnliche Karriere: Aus einer Spezifikation wurde binnen achtzehn Monaten eine Selbstverständlichkeit. Die Einschätzung von Figma-Mitgründer Dylan Field, am 20. Oktober von TechCrunch berichtet – MCP sei kein perfektes Protokoll –, verdient Aufmerksamkeit nicht weil sie gegen den Strich geht, sondern weil sie von jemandem kommt, der gegen das Protokoll ausliefern musste.
Was MCP tut und warum es gewann
MCP standardisiert, wie eine KI-Anwendung Werkzeuge und Daten für ein Modell bereitstellt. Ein Server erklärt seine Fähigkeiten, ein Client verbindet sich, das Modell ruft Werkzeuge auf. Der Reiz war struktureller Natur: Vorher baute jedes KI-Produkt, das Dateien lesen, eine Datenbank abfragen oder ein Designwerkzeug steuern wollte, eine eigene Integration – und jede Integration wurde doppelt gepflegt, einmal vom Werkzeug und einmal vom Assistenten. Ein Protokoll statt N-mal-M-Integrationen.
Der Preis für diesen Erfolg ist, dass eine Spezifikation, die so schnell zum Ist-Zustand wurde, kaum Zeit hatte, sich an ihren eigenen Fehlern zu schärfen. Was jetzt sichtbar wird, sind Ingenieursprobleme – und sie betreffen überwiegend Kosten und Vertrauen, nicht Fähigkeiten.
Vier Stellen, an denen es reibt
**Kontext ist nicht kostenlos.** Werkzeugdefinitionen verbrauchen Token. Ein Server mit zwanzig Werkzeugen kann Tausende Token damit verbringen, sich selbst zu beschreiben, bevor das Modell ein einziges Wort der Anfrage gelesen hat. In einer agentischen Schleife über viele Runden kumuliert diese Steuer. Ein Protokolldesign, das Werkzeugschemas als schwerelos behandelt, sieht anders aus, wenn pro Token und pro Runde abgerechnet wird.
**Authentifizierung ist der Punkt mit Sicherheitsfolgen.** MCP-Server halten häufig Zugangsdaten zu echten Systemen. Die Authentifizierungsgeschichte des Protokolls wurde nach frühen Einsätzen nachgeschärft, weil Confused-Deputy-Probleme sichtbar wurden: Ein Server, der im Namen eines Nutzers handeln kann, muss genau wissen, in wessen Namen – und Token-Begrenzung über eine Kette aus Client, Modell und Server ist leicht subtil falsch zu bauen. Ein Berechtigungssystem, das im Demo funktioniert, ist im Mehrbenutzerbetrieb nicht dasselbe.
**Zustand und Versionierung.** Sitzungen, Fähigkeitsaushandlung und das Verhalten bei Schemaänderungen sind die Teile einer Spezifikation, die niemand liest, bis sie brechen. Ökosysteme, die schnell wachsen, wachsen ungleichmäßig: Ein Serverautor testet gegen zwei oder drei Clients, und der Rest des Marktes findet die Lücken.
**Fragmentierung der Clients.** Ein Standard, dessen Referenzimplementierungen faktisch die Spezifikation sind, driftet. Wenn verschiedene Clients unterschiedliche Teilmengen umsetzen, wird „unterstützt MCP“ zu einer Angabe, die man pro Client nachprüfen muss.
Warum ausgerechnet Figma das sagt
Designdaten sind der pathologische Fall für dieses Modell. Eine Designdatei ist groß, stark strukturiert und in hoher Treue – den ganzen Inhalt in den Kontext zu legen ist gleichzeitig teuer und verlustbehaftet. Genau dort, wo Kontextkosten und Ausgabetreue gleichzeitig unter Druck stehen, treten die Schwächen eines Protokolls zuerst zutage. Figma hat MCP-Unterstützung ausgeliefert; damit zu leben ist etwas anderes, als es zu demonstrieren.
Das ist auch der Grund, warum die Bemerkung nicht als Ablehnung zu lesen ist. Sie ist das normale Geräusch eines Standards, der reift: Die erste Welle der Begeisterung ist vorbei, die zweite Welle besteht aus Leuten, die Rechnungen dafür bezahlen.
Was ein besseres Protokoll auszeichnet
Die konstruktive Antwort auf diese Kritik ist wenig spektakulär, und sie ist weitgehend bekannt.
Werkzeuge sollten auffindbar sein, statt vollständig deklariert zu werden – eine kurze Beschreibung, die auf Anfrage Details nachlädt, statt zwanzig Schemata im Voraus. Fähigkeiten sollten ausgehandelt werden, damit Client und Server sich auf die Schnittmenge einigen, statt sich gegenseitig zu unterstellen. Token sollten eng begrenzt und an einen konkreten Zweck gebunden sein, nicht an eine Sitzung. Und Lesen sollte von Handeln getrennt werden: Ein Server, der eine Datenbank abfragen darf, sollte nicht dieselbe Berechtigung haben wie einer, der schreibt.
Nichts davon ist unmöglich, und vieles davon ist in Arbeit. Der offene Punkt ist Governance: Kann die Stewardship von MCP inkompatible Änderungen durchsetzen, solange das Ökosystem noch jung genug ist, sie zu verkraften? Genau dieses Zeitfenster schließt sich gerade.
Die Lesart
Die schärfste Kritik an einem Standard kommt selten von seinen Gegnern. Sie kommt von den Anwendern, die ihn ernst genommen haben. Dass ein Mitgründer eines großen Designwerkzeugs öffentlich sagt, das Protokoll sei nicht perfekt, ist kein Zeichen dafür, dass MCP scheitert – es ist ein Zeichen dafür, dass es wichtig genug geworden ist, um kritisiert zu werden.
Beobachten sollte man in den nächsten Monaten zwei Dinge: ob Auth- und Berechtigungsmodelle über die Spezifikation hinaus vereinheitlicht werden, und ob die großen Clients anfangen, sich auf dieselbe Teilmenge zu einigen. Solange beides ausbleibt, bleibt „MCP-kompatibel“ eine Aussage, die man prüfen muss, statt eine, auf die man bauen kann.
