Ein kritischer Blick auf MCP

• MCP (Model Context Protocol) bietet eine standardisierte Integrationsmethode, mit der LLMs mit der Außenwelt interagieren können
• In letzter Zeit sind ähnliche Standards wie IBMs ACP und Googles A2A aufgetaucht, während Implementierungen von MCP und zugehörige Tools rasch zunehmen
• Als Probleme werden jedoch Verwirrung im Design, unzureichende Dokumentation und fehlende tatsächliche Protokollspezifikationen genannt – Zeichen unausgereifter Engineering-Praktiken
• Die derzeit vorgeschlagenen Transportmethoden wie HTTP+SSE und Streamable HTTP erhöhen Komplexität und Sicherheitsrisiken; als Alternative wird der Einsatz von WebSocket empfohlen
• Die neuesten Protokolle sind bei Autorisierung und Session-Management inkonsistent und fügen übermäßige Komplexität hinzu

---

MCP und aktuelle Entwicklungen im Überblick

• MCP ist ein offenes Protokoll, das geschaffen wurde, um zu standardisieren, wie Anwendungen Large Language Models (LLMs) Kontext bereitstellen
• Im vergangenen Monat hat sich MCP als zentraler Standard etabliert, um LLMs zu Agenten zu machen, und seine Nutzung sowie Implementierung verbreiten sich rasant
• Mit ähnlicher Zielsetzung entstehen schnell weitere eher orthodoxe Standards wie IBMs ACP oder Googles A2A

Probleme bei Engineering-Praktiken und Protokollspezifikation

• An vielen Stellen zeigt sich ein niedriges Niveau bei tatsächlicher Implementierung und Dokumentation
• Große Tech-Unternehmen investieren massiv in das Training von Modellen, während SDKs und Dokumentation schwach ausfallen und bei Nutzern Verwirrung stiften
• Auch MCP zeigt ähnliche Probleme: Teile des Designs sind unplausibel, und es fehlt an Spezifikationen, Beispielen und Richtlinien

Diskussion zu den Transportprotokollen

Transport per stdio

• Stdio ist die traditionelle Methode, bei der MCP-Server und -Clients lokal direkt über Pipes (stdout, stdin) verbunden werden
• Es gibt weniger komplexe Socket-Behandlung und weniger betriebssystemspezifische Probleme, wodurch sich eine schlanke Umgebungs-Konfiguration mit Umgebungsvariablen sowie Ein- und Ausgabeströmen ermöglicht

HTTP+SSE / Streamable HTTP

• Mit der Absicht, dem Web-Zeitalter gerecht zu werden, wurden HTTP+SSE und Streamable HTTP als HTTP-basierte Varianten übernommen
• Diese Ansätze wollen jedoch WebSocket ersetzen und verursachen dabei eher mehr Mehrdeutigkeit, Verwirrung im Design und Komplexität
• Da sich eine einzelne Session und Verbindung auf unterschiedliche Weise erzeugen und beenden lassen, entsteht eine erhebliche Belastung für Statusverwaltung und Sicherheit auf Serverseite

Schwierigkeiten in Praxisbeispielen für MCP-Server und -Clients

• Defizite bei der Unterstützung in verschiedenen Sprachen, etwa das Fehlen eines offiziellen Go SDK, fallen deutlich auf
• Weil Dokumentation und Spezifikation unklar sind, muss in der Praxis häufig per Reverse Engineering implementiert werden
• Obwohl die Beispielserver überwiegend auf Python und JavaScript basieren, erschweren Abhängigkeits- und Portabilitätsprobleme den Einsatz in produktiven Umgebungen
• Bei der Server-Implementierung versuchen SSE/Streamable HTTP, Sockets nachzuahmen, tatsächlich ist es aber schwierig, Session- und Verbindungszustände konsistent aufrechtzuerhalten, und es wird zusätzliche Infrastruktur wie Message Queues benötigt

Aufbau und Probleme von HTTP+SSE und Streamable HTTP

HTTP+SSE-Modus

• Der Client öffnet eine SSE-Session mit dem Server; sendet er Schreibanfragen an einen separaten Endpoint, antwortet der Server mit 202 und liefert die Antwort über die bestehende SSE-Verbindung aus
• Session-Verbindungen und Statussynchronisierung müssen aufrechterhalten werden, doch dieser Prozess ist nur unzureichend dokumentiert und operativ sehr komplex

Streamable-HTTP-Modus

• Session-Erstellung, Öffnen von SSE und Antwortübermittlung werden in mehreren Varianten vermischt, sodass ein einzelner Request-Response-Ablauf nicht konsistent ist
• Mehrfache Statusverwaltung sowie unterschiedliche Endpoints und Header-Verfahren treten nebeneinander auf, was praktische Implementierung und Skalierbarkeit erheblich behindert

Allgemeine Implikationen

• Mit der steigenden technischen Komplexität nehmen auch kognitive Last und Wartungsaufwand für Entwickler zu; zudem treten bei verschiedenen Server- und Client-Implementierungen Kompatibilitätsprobleme und unvorhersehbares Verhalten auf
• Server müssen sämtliche Zustände und Verbindungssituationen nachverfolgen; in verteilten Umgebungen werden effiziente Skalierung und Statussynchronisierung noch schwieriger

Sicherheitsimplikationen

• Die feingranularen und vielfältigen Verbindungs- und Session-Varianten erhöhen Sicherheitslücken in der Statusverwaltung wie Session Hijacking, Replay-Angriffe und Denial of Service (DoS)
• Mehrere Einstiegspunkte und Antwortwege vergrößern die Angriffsfläche und können bösartige Aktivitäten über unbeabsichtigte Abläufe verschleiern

Verwirrung beim Autorisierungsprotokoll

• Die aktuelle Spezifikation erzwingt etwa OAuth2 nur bei HTTP-Transport, während bei STDIO-Transport willkürlich Umgebungsvariablen verwendet werden sollen – eine inkonsistente Regelung
• Es bleibt verwirrend und widersprüchlich, warum nur HTTP-Transport zu einer komplexen OAuth2-Implementierung gezwungen wird

Vorschläge zur Verbesserung

• Nötig ist eine Vereinfachung auf ein einziges JSON-RPC-Protokoll, bei dem sich die Transportarten praktisch auf Stdio und WebSocket beschränken
• Wünschenswert wäre ein Mapping, bei dem Variablen aus der Stdio-Umgebung Headern im HTTP-Umfeld entsprechen und Ein- und Ausgabe jeweils auf bidirektionale Streams von WebSocket abgebildet werden
• Dadurch lassen sich unnötiges Session-Tracking, Statusverwaltung und zahlreiche Sonderbehandlungen vermeiden
• WebSocket sollte die Standardwahl für jeden HTTP-basierten Transport sein und kann auch komplexe Probleme der Statussynchronisierung lösen

Vergleich mit alternativen Protokollen und Marktentwicklung

• IBMs ACP und Googles A2A bieten im Hinblick auf die Interoperabilität von Agenten ein schlankeres Transportdesign und Funktionen zur Agenten-Erkennung
• Im Kern lassen sie sich jedoch meist als separate Werkzeuge in MCP-basierte Umgebungen integrieren
• Da das fortlaufende Auftauchen neuer Protokolle das Risiko einer Zersplitterung von Standards birgt, ist es für das Wachstum der Branche wichtig, die Einfachheit des Transports zu priorisieren

[GN⁺]

Hacker-News-Kommentare

• Ich bin überzeugt, dass der Grund, warum von LLM-Anbietern verfasste Dokumentationen so verwirrend sind, darin liegt, dass sie LLMs zum Schreiben der Dokumentation verwenden. Das ist ein sehr schlechter Ansatz; insbesondere ist der Einsatz von LLMs bei der Arbeit an Spezifikationen noch deutlich schlimmer als bei guter Dokumentation. Der eigentliche Prozess des Spezifikationsschreibens ist der Kern: Es ist wichtig, dass menschliche Designer durchdacht Fehler und Lücken finden und Randfälle behandeln. In der MCP-Spezifikation sehe ich zu wenig Spuren solcher menschlichen Sorgfalt. Der charakteristisch fade Stil, die Zerstreutheit und die listenzentrierte Struktur sind genau das typische Ergebnis von LLMs.
  • Bei der Dokumentation von DeepSeek ist das Problem eher, dass sie sehr viele Rechtschreib- und Grammatikfehler enthält. Es ist wirklich seltsam, dass ein Unternehmen, das den ganzen Tag mit Sprache arbeitet und zeitweise sogar eines der besten englischen LLMs der Welt hatte, es nicht schafft, Dokumente zu produzieren, die professionell wirken.
  • Ich habe ebenfalls stark das Gefühl, dass auch diese Spezifikation von einem LLM geschrieben wurde. Alle Indizien deuten darauf hin. Ich vermute, dass die meisten Produkte bereits nur dafür da sind, Investoren vor einem IPO zu zeigen, dass man das plausibelste Mittelmaß herausgemittelt hat.
  • Falls das stimmt, wäre das wirklich bedauerlich. Anthropic hat viele kluge Leute, daher ist es schade, dass so etwas bei einem Kernbaustein eines wichtigen Ökosystems passiert.
  • Mir fällt jetzt erst ein, dass AI-Coding-Anbieter einen Anreiz haben könnten, Dokumentation absichtlich unverständlich zu machen. So würden sie Code erzeugen, den Menschen nicht verstehen und nur ihre eigene AI interpretieren kann, wodurch Nutzer vollständig von ihrem speziellen AI-Service abhängig würden. Wenn es ihnen in den nächsten zwei Jahren nicht gelingt, echte Programmierer vollständig zu ersetzen, würde diese Strategie am Ende alle Verbraucher verschwinden lassen und sogar ihren eigenen Markt zerstören. Übrig bliebe dann nur ein riesiger Haufen Code, der weder für Menschen noch für AI gut übertragbar ist.
  • Wenn ich von LLMs geschriebene Prosa lese, merke ich, dass nicht nur bei mir die Konzentration abreißt: Diese maschinell erzeugten, repetitiven und kontextlosen Texte enthalten keine tiefen Gedanken und verursachen zunehmend sogar emotionale Ermüdung. Wenn ein solches LLM dann auch noch technische Spezifikationen schreibt, mischt sich am Ende unbewusst Inhalt hinein, den der Autor selbst nicht versteht. Das beunruhigt mich immer mehr.
  • Die Dokumentation von DeepSeek wirkte insgesamt gar nicht so schlecht. Sie sieht zwar so aus, als sei sie schnell zusammengeschustert worden, aber das Niveau ist nicht schlecht. Das zeigt, dass es Ausnahmen von der These geben könnte, dass von LLMs geschriebene Dokumentation immer schlecht ist.
• Das LLM-Feld imitiert derzeit Software-Paradigmen fast so, als würde es Cheatcodes benutzen. Es gibt bereits viele frühere Beispiele dafür, wie man Remote-Funktionen exponiert, etwa DLL, gRPC, SOAP, IDL und dCOM, und doch scheint das aktuelle LLM-Lager kaum zu wissen, dass diese existieren. Ich hoffe, dass das mit der Zeit reifer wird, aber die offenen Hausaufgaben müssen trotzdem noch gemacht werden.
  • In ein paar Monaten wird das sicher reifer sein, aber wenn ich an das frühe Python-Ökosystem denke, erinnere ich mich daran, wie Fehler sich in den unteren Schichten des Stacks festsetzen und dann alle neue Tools darauf aufbauen. Noch bedauerlicher ist dieses Mal, dass das AI-Ökosystem denselben Weg geht, obwohl es bereits eine Geschichte identischer Fehler aus der Vergangenheit gibt.
  • Als ich MCP zum ersten Mal sah, musste ich an COM/DCOM denken, und auch an die alte DLL-Hell. Ich werde beobachten, wie sich MCP entwickelt.
  • Ich habe noch keine Erklärung gefunden, aus der klar wird, was MCP genau ist, und frage mich, wie man es in Begriffen älterer Programmiersprachen nennen würde.
  • Ich möchte darauf hinweisen, dass bei so strengen und deklarativen Protokollen der potenzielle Bedeutungsraum und die semantischen Stärken von LLMs verloren gehen. Es könnte intuitiver sein, einfach eine agents.json-Datei ins Web-Root zu legen und Agenten den Rest über semantische Gespräche automatisch lösen zu lassen. Dann würde HTTP letztlich zum Standard-Ein- und -Ausgang für Agenten.
  • Ich halte alle genannten Beispiele für passend.
  • Ich frage mich, ob MCP auf JSON-RPC basiert.
• Ich stimme dem Gesamtinhalt des Artikels zu und teile besonders die irritierende Erfahrung, auf der MCP-Website keine substanziellen Informationen finden zu können. RFCs sind schwer zu lesen, aber immer noch viel besser als „benutz einfach das SDK“.
  • Ich wünschte, mehr Leute würden erkennen, wie wichtig dieser Blog ist. Man sollte die Einführung von MCP kurz anhalten und noch einmal prüfen, ob es dafür ein grundlegend solides technisches Fundament gibt. Es gibt viel Begeisterung, aber wer tiefer in die Implementierung einsteigt, wird enttäuscht sein. Bei Kernfunktionen und verschiedenen Entscheidungen wie WebSockets bleibt vieles fragwürdig, und auch wenn nicht alles so ist, wirkt manches wie ein hastig zusammengebautes Provisorium.
  • Es ist schade, dass es auf der Website keine klare Spezifikation gibt. Die Hälfte der Spezifikation wirkt, als sei sie mit Sonnet erzeugt worden, und die tatsächliche Funktionsweise des Protokolls ist nicht klar beschrieben. Im Vergleich dazu ist die GraphQL-Spezifikation deutlich besser geschrieben.
• Der Großteil der aktuellen Arbeit im AI-Bereich wird vor allem von Mathematikern, (Daten-)Wissenschaftlern, Studenten und enthusiastischen Amateuren geleistet. Nach Maßstäben professioneller Software Engineers wirkt vieles unreif, fast wie Wochenendprojekte.
  • Ich denke, dass professionelle Software Engineers tatsächlich einen Großteil der Arbeit machen.
• MCP hätte von Anfang an auf zustandsloses HTTP setzen sollen. Die meisten Server müssen keinen Zustand halten; globale Zustandsverwaltung oder einfach eine Session-ID würden ausreichen.
  • Ich verstehe die Struktur der tatsächlichen Interaktionen in MCP nicht. Ich würde gern wissen, warum es nicht zustandslos ist und warum Verbindungen offen gehalten werden müssen.
  • Ich habe persönlich nicht viel Erfahrung damit, aber wenn man nach einer Anfrage die Verbindung schließt, muss man für die nächste Anfrage erneut verbinden. Ob man Sessions offen halten oder schließen sollte, hängt von verschiedenen Faktoren ab, etwa Nutzungsmustern und Speicherverbrauch.
• Ich baue einen auf Ruby on Rails basierenden MCP-Dienst namens ninja.ai. Es ist ein App-Store, der MCP-Server mit einem Klick installiert. Mit Tauri installiert er Model Context Protocol-Server auf dem Client-Gerät, und mit Rails bietet er auch Cloud-MCP-Server an. Ich sehe HTTP+SSE oder Streamable HTTP kritisch. Für bidirektionale Echtzeitkommunikation sind WebSockets besser, und da die SSE-Unterstützung von Rails eingeschränkt ist, habe ich Endpunkte auf den Falcon-Webserver migriert. Mich interessiert, warum Shopify-Ingenieure sich für Streamable HTTP entschieden haben; möglicherweise lag es an Infrastruktur- oder Deployment-Einschränkungen. Bemerkenswert ist auch, dass die MCP-Transportschicht abstrahiert ist. Künftige Implementierungen sind also durchaus offen für WebSockets oder WebRTC.
• Ich betreibe eines der MCP-Register (glama.ai/mcp/servers). Ich stimme dem Autor teilweise zu, aber das Protokoll ist noch in einem sehr frühen Stadium und kann sich noch stark verändern. Es hat viel mehr Aufmerksamkeit bekommen als erwartet: Aus anfangs nur einigen Dutzend Servern wurden plötzlich Tausende, aber tatsächlich funktionierende Server sind nur ein Teil davon, sodass ich viel Zeit mit dem Aussortieren verbringe. Das ist ein Effekt davon, dass MCP noch vor seiner Reife öffentliche Aufmerksamkeit bekam. Gleichzeitig wächst das Ökosystem mit Code-Frameworks, Registern und MCP-unterstützenden Clients in erstaunlichem Tempo. Dass sich in nur einem halben Jahr so viel verändert hat, ist beispiellos. Wenn sich dieser Trend fortsetzt, sind die Aussichten gut. Ich stelle auch eine nützliche Materialsammlung für Einsteiger bereit.
  • Wenn man in der frühen Phase des Protokolldesigns Fehler macht, muss man diese Fehler für immer mit sich herumschleppen. Deshalb sollte man Spezifikationen mit Demut gestalten. Eine Struktur wie diese SSE-Rube-Goldberg-Maschine könnte sonst dauerhaft bestehen bleiben, ohne je korrigiert zu werden. Auf Enterprise-Niveau sind irgendwelche protokollbrechenden Änderungen ohnehin schwer durchzusetzen, sodass man lange an frühen Entscheidungen festhängen kann.
  • Dass sich das MCP-Protokoll im Lauf der Zeit weiterentwickelt, halte ich für selbstverständlich. Es wäre eher seltsam, von Anfang an Vollständigkeit zu erwarten. Vor allem ist die Standardisierung agentischer APIs wirklich eine starke Veränderung. Wenn man selbst Code schreibt und deployt und die AI ihn sofort erkennt und automatisch nutzt, muss man das direkt erlebt haben, um es wirklich zu begreifen.
  • Meine Sorge ist, ob MCP bei diesem Tempo zu früh ein Design der Transportschicht akzeptiert, das lange bestehen bleiben soll. Das erinnert mich an Fälle wie die Browserkriege der 90er, als sich Standardspaltungen sehr lange nicht auflösten, ähnlich wie IE11 viel zu lange erhalten blieb.
• Die Kontroverse rund um Berechtigungen (Authentication) wird bereits überarbeitet. In Zusammenarbeit mit Anthropic und der Security-Community wurde im MCP die Trennung zwischen Resource Server (RS) und Authorization Server (AS) umgesetzt. Bis die neue Protokollversion formalisiert ist, wurde vorläufig eine Entwurfsspezifikation veröffentlicht.
  • Ich frage mich, welcher Anteil der MCP-Spezifikation aus LLM-Ausgaben besteht. Mich würde interessieren, ob die Warnsignale einfach so stark waren, dass man es instinktiv gemerkt hat.
  • Ich sehe das relativ neutral, aber es wirkt, als hätte man einfach grob einen OAuth-Entwurf kopiert, und mich stört die Struktur, bei der man bei der Nutzung von HTTP keine Wahl hat und dem einfach folgen muss. Eigentlich hätte man klarer festhalten können, dass Client und Server jeweils OAuth2-Unterstützung optional haben können.
• Im Zusammenhang mit der Einführung von Streamable HTTP für MCP habe ich einmal ein Issue dazu erstellt, ob man nicht einfach alles zu normalen HTTP-Requests machen könnte. Die MCP-Spezifikation wirkt als allgemeine Lösung zur Verbindung von LLMs und Tools vielversprechend, stößt in der Praxis aber auf viele Schwierigkeiten, etwa Authentifizierung, Streaming, toolspezifische benutzerdefinierte Befehle und die Verifikation der Vertrauenswürdigkeit von Tools. Tatsächlich halte ich eine Integration nur über REST APIs für einfacher. OpenAI oder Gemini haben zwar ebenfalls angekündigt, MCP zu übernehmen, aber ich erwarte, dass die Spezifikation bald auf Inkonsistenzen bei Dingen wie unerwünschter UI, Interaktionsschichten und Ähnlichem stoßen wird, die entweder nicht zur Marke passen oder Probleme wie kompromittierte Authentifizierung verursachen.
  • Selbst wenn Anthropic MCP entwickelt hat, ist die Größenordnung im Vergleich zu ChatGPT deutlich kleiner. Ich frage mich, ob große Unternehmen wie OpenAI oder Google auf Dauer wirklich eine Spezifikation akzeptieren werden, bei der ein externes Team die Grenzen der Nutzererfahrung festlegt. Es gibt frühere Beispiele wie ChatGPT Plugins, die nicht an schlechter Technik, sondern an den Grenzen der Consumer Experience gescheitert sind. Trotzdem bin ich bereit, auf die Stärke einer starken Community zu hoffen.
  • Nachdem ich den Blog veröffentlicht hatte, habe ich selbst ähnliche Issues eingereicht. Gerade weil das so wichtig ist, fühlt es sich so an, als wären Fehler nur schwer rückgängig zu machen.
• Ich finde es merkwürdig, warum MCP so stark im Trend liegt, aber es ist nun einmal ein Trend. Im Vergleich zur OpenAPI-Spezifikation würde ich gern hören, in welchen Punkten MCP besser sein soll.
  • Meiner Meinung nach verdankt MCP seine Popularität vor allem dem Umstand, dass die Nutzbarkeit von LLM-Tools in letzter Zeit tatsächlich besser geworden ist. OpenAI-Plugins sind 2023 gescheitert, weil LLMs damals bei der Tool-Nutzung noch nicht zuverlässig genug waren; für MCP ist das Timing viel besser.
  • Ein weiterer wichtiger Faktor ist, dass sich ein MCP-Server extrem leicht starten lässt und die Einstiegshürde niedrig ist. Wenn es mehr Tools gibt, steigt auch die Menge an Text, die an das LLM geschickt wird; liefert man stattdessen OpenAPI mit einzelnen Pfaddetails und Beschreibungsmeldungen, kann auch Claude das hervorragend integrieren.
  • Ein Grund, warum MCP wichtig ist, liegt darin, dass OpenAPI statische Dokumentation ist und das LLM den gesamten Prozess der Request-Erzeugung selbst übernehmen muss, während ein MCP-Server diese Last durch Abstraktion reduziert. Das ist aus Sicht des LLM letztlich einfacher, schneller und sicherer.
  • Ich halte MCP nicht für perfekt, aber in einigen Punkten ist es für LLMs besser geeignet als OpenAPI. Vor allem lassen sich MCP-Tools viel kürzer und einfacher spezifizieren, während OpenAPI-Spezifikationen zu groß sind und zu viel LLM-Kontext verbrauchen. LLMs erzeugen ja nicht wirklich Aufrufe, sondern nur Ausgabetext, daher ist der MCP-Ansatz natürlicher. Außerdem ist MCP bei dynamischen Strukturen wie dem Hinzufügen oder Ändern von Tools deutlich flexibler und überwindet die statischen Grenzen von OpenAPI. Natürlich gibt es klare Probleme, insbesondere bei der Transportschicht, wo noch Verbesserungsbedarf besteht. Auch die zentralen Bibliotheken sind ziemlich gut implementiert.