Warum MCP von Anfang an eine schlechte Idee war

Kürzlich besuchte ich eine ganztägige Veranstaltung, die sich auf das Neueste und Beste aus der MCP-Welt konzentrierte. Obwohl alle Referenten großartig waren und leidenschaftlich bei der Arbeit schienen, bin ich ehrlich gesagt der MCP überdrüssig. Es ist ein schreckliches Protokoll, das für eine Zeit gebaut wurde, in der LLMs nicht so schlau waren, und wir sind darüber hinausgewachsen.

Kurze Geschichte

MCP wurde im November 2024 vom Anthropic-Team als Protokoll veröffentlicht, das entwickelt wurde, um Agenten bei der Verbindung zu externen Diensten und Datenquellen zu helfen. Die Modelle jener Zeit waren noch relativ primitiv, zumindest im Vergleich zu dem, was wir jetzt haben. Wir hatten noch nicht einmal Claude Code, und allgemeine agente Workflows waren weit weniger zuverlässig. Nutzer begannen, den Nutzen zu erkennen, ihren KI-Modellen Zugriff auf externe Dienste zu geben. Dies ermöglichte ein Produktivitätsniveau, das wir zuvor nicht gesehen hatten. Wir sahen eine Explosion der MCP-Einführung, die mit einem ähnlichen, wenn nicht sogar explosiveren Wachstum der LLM-Einführung in der gesamten Wirtschaft zusammenfiel. Im Laufe der Zeit entwickelte sich MCP unter der Leitung von Anthropic weiter, bevor es schließlich 2025 an die Agentic AI Foundation unter der Linux Foundation gespendet wurde.

Der MCP-Industriekomplex

Mit dem enormen Wachstum der Einführung begannen Nutzer, viele MCP-Server zu ihren Setups hinzuzufügen, und stießen auf das Problem der Kontext-Aufblähung. Jeder Server kam mit mehreren Tools, jedes mit seinem eigenen Schema, was begann, den Kontext all dieser Modelle zu überlasten. Harness-Entwickler fanden viele Tricks, um dies zu umgehen, einschließlich generischer Such-/Ausführungsmuster, die jetzt von Plattformen wie Composio, Mint MCP und Pipedream angeboten werden. Sie alle lösen effektiv das Problem, einen einzigen Ort für Anmeldedaten für verschiedene externe Dienste zu haben und dem Agenten einen minimalen Tool-Satz (zur Reduzierung der Kontext-Aufblähung) zu geben, mit dem er darauf zugreifen kann. Ich möchte klarstellen, dass dies kurzfristig eine gute Sache ist.

Mit all dem, was wir um MCP herum gebaut haben, haben wir nicht berücksichtigt, oder vielleicht ignoriert, dass die Modelle besser wurden. Wir haben jetzt ganze Systeme, die MCP-Server überwachen, sicherstellen, dass die Antworten gut sind, sicherstellen, dass Agenten leicht auf Tools zugreifen können, Schemata herausfinden und bestimmen, was wir Agenten geben müssen, damit sie zum richtigen Zeitpunkt den richtigen Aufruf tätigen können.

Überraschung, Überraschung, die großen Labore hatten recht

Die Modelle wurden besser. Sie sind jetzt in der Lage, Code auf einem Computer auszuführen, über große Codebasen zu reflektieren und allgemein viel autonomer als je zuvor zu handeln. Ein großer Teil dieser Arbeit bestand darin, Skripte für Coding-Zwecke zu schreiben/auszuführen. Ein Nebeneffekt (ist es einer?) ist, dass sie jetzt gut darin sind, APIs direkt aufzurufen. Sie können Skripte schreiben, mehrere verschiedene Dienste komponieren und APIs aufrufen, die sie noch nie gesehen haben, alles in nützlichen Workflows mit minimaler Intervention seitens des Nutzers.

LLMs sind darin so gut geworden, dass Cloudflare sogar den Code Mode startete, eine bessere Art, MCP zu nutzen, indem LLMs die verschiedenen Aufrufe in Skripte komponieren, die in einer Sandbox ausgeführt werden können. Aber noch besser als das, haben LLMs herausgefunden, wie man den --help-Befehl verwendet, um CLIs zu entdecken, sodass sie MCP-Server nicht mehr benötigen, um auf viele Dienste zuzugreifen, die über dokumentierte APIs oder CLIs verfügbar sind. Die meisten Remote-Service-MCP-Server umschließen letztlich APIs, die bereits existieren.

Was nun?

Wir löschen die meisten unserer MCP-Server. Das ist es. Agenten mit Terminalzugriff können die meisten MCP-Server ersetzen und sind oft leistungsfähiger.

Es gibt immer noch einige Probleme, wie CLIs, die maschinenlesbare Antworten (JSON/XML usw.) zurückgeben, die tendenziell sehr ausführlich und token-lastig sind, aber wir haben Wege, dies zu beheben. Ein großer Teil der Alternative existiert bereits: dokumentierte HTTP-APIs, Standard-Content-Negotiation und ausgereifte Authentifizierungsmechanismen. Wir sollten beginnen zu standardisieren, wie Agenten HTTP-APIs direkt nutzen. Zum Beispiel könnten Agenten-Clients Header anhängen, um sich als Agenten zu identifizieren, und Server könnten ihnen automatisch Antwortdaten als Markdown oder Text statt HTML oder... senden.