Das Konzept des Machine Communication Protocol (MCP) hat in der Tech-Welt, insbesondere im Bereich der Large Language Models (LLMs), beträchtliche Aufmerksamkeit erlangt. Obwohl es verspricht, die Interaktion zwischen LLMs und externen Ressourcen zu rationalisieren, offenbart ein genauerer Blick mehrere inhärente Probleme und Einschränkungen, die sorgfältige Überlegung verdienen. Diese Analyse befasst sich mit der Kritik an MCP, untersucht seine Schwachstellen, Skalierbarkeitsprobleme und die umfassenderen Auswirkungen auf die Entwicklung von KI-Agenten.
Überlastung der Verantwortlichkeiten von MCP
Eine häufige Kritik ist, dass MCP mit zu viel Verantwortung betraut wird. Der Autor argumentiert, dass MCP in erster Linie als Gateway für LLMs dienen sollte, um auf externe Ressourcen zuzugreifen und mit ihnen zu interagieren. Die Betrachtung als bloße ‘Tür’ oder ‘Brücke’ hilft, den Zweck und die Grenzen zu verdeutlichen.
Die Zuschreibung von Problemen wie versehentlicher Datenpreisgabe, Prompt-Injection-Schwachstellen und Defiziten bei der Kostenkontrolle direkt an MCP ist eine Fehlplatzierung der Schuld. Dies sind Probleme, die Entwickler innerhalb der von ihnen kontrollierten Grenzen angehen sollten. Entwickler müssen Ratenbegrenzungen implementieren und die Nutzung überwachen, unabhängig vom verwendeten Protokoll. Dies mit der Schuldzuweisung an die Straße für Geschwindigkeitsüberschreitungen gleichzusetzen, ist treffend – die Infrastruktur ist nicht für das individuelle Verhalten verantwortlich.
Letztendlich sind viele der geäußerten Bedenken umfassendere Probleme im Zusammenhang mit der Delegation von Aufgaben an KI-Agenten. Entwickler müssen die Verantwortung für die Bewältigung dieser Herausforderungen innerhalb ihrer spezifischen Anwendungen übernehmen, anstatt zu erwarten, dass die API selbst alles erledigt.
Das zweischneidige Schwert von LLMs und Prompt Injection
Jüngste Diskussionen über MCP ähneln oft Warnungen vor den inhärenten Gefahren scharfer Messer – sie können schneiden, wenn sie falsch gehandhabt werden. Prompt Injection, ein erhebliches Problem, ist eine Folge der Natur von LLMs selbst. Versuche, das Risiko von Prompt Injection zu beseitigen, würden die Fähigkeiten beeinträchtigen, die LLMs wertvoll machen.
Die Vorstellung einer Trennung von ‘Kontrolle vs. Daten’, wie sie in traditionellen Systemen üblich ist, existiert in LLMs nicht auf natürliche Weise. LLMs gewinnen ihre Leistungsfähigkeit und Allgemeingültigkeit gerade deshalb, weil ihnen diese starre Trennung fehlt. Diese inhärente Eigenschaft macht sie anfällig für Prompt-Injection-Angriffe.
Während Remote-MCPs as a Service Risiken bergen können, liegt der Fehler nicht beim Protokoll selbst, sondern bei der Übertragung sensibler Aufgaben an nicht vertrauenswürdige Dritte. Diese Analogie erstreckt sich auf die Idee, ein Messer mit Klebeband an einen unberechenbaren Roomba zu kleben – das Problem ist nicht das Messer selbst, sondern die Entscheidung, es an einem unvorhersehbaren Gerät zu befestigen.
Ermahnungen, ‘vorsichtig zu sein’, oder Vorschläge für Schutzausrüstung sind zwar technisch richtig, verfehlen aber das Kernproblem: die unüberlegte Entscheidung, ein scharfes Werkzeug mit einem unkontrollierten System zu kombinieren.
Skalierbarkeitsprobleme
Neben Sicherheitsbedenken steht MCP vor grundlegenden Skalierbarkeitsbeschränkungen. Der Autor hebt die negative Korrelation zwischen LLM-Zuverlässigkeit und der Menge des bereitgestellten instruktionellen Kontexts hervor. Dies stellt den weit verbreiteten Glauben in Frage, dass das Hinzufügen weiterer Daten und Integrationen Probleme automatisch lösen wird. Mit zunehmender Anzahl von Tools und Integrationen kann sich die Leistung eines Agenten verschlechtern, während gleichzeitig die Kosten jeder Anfrage steigen.
Der Autor betont, dass MCP nicht über eine bestimmte Schwelle hinaus skaliert. Der Versuch, dem Kontext eines Agenten eine unbegrenzte Anzahl von Tools hinzuzufügen, wird sich unweigerlich negativ auf seine Fähigkeiten auswirken. Diese Einschränkung ist dem Konzept von MCP inhärent und erfordert mehr Aufmerksamkeit als Authentifizierungsprobleme.
Benutzer können schließlich einen Leistungsabfall feststellen, wenn sie mehr MCP-Server aktivieren, was zu Interferenzen zwischen ihnen führt. Dies steht in krassem Gegensatz zu typischen Paketverwaltungssystemen, bei denen Nicht-Interferenz eine grundlegende Eigenschaft ist.
Das Kernproblem bei MCP besteht darin, dass sein tatsächliches Verhalten von den Erwartungen der Benutzer abweicht. Es ist wichtig zu erkennen, dass MCP keine Plug-and-Play-Lösung ist, die nahtlos eine unbegrenzte Anzahl von Tools ohne Konsequenzen integriert.
Behebung von Einschränkungen mit UI und Tool-Verwaltung
Eine vorgeschlagene Lösung für die Einschränkungen von MCP ist die Verbesserung der Benutzeroberfläche. Wenn ein Tool unbeabsichtigt ausgeführt wird, sollte die Benutzeroberfläche eine einfache Möglichkeit bieten, es zu deaktivieren oder seine Beschreibung zu ändern, um seine beabsichtigte Verwendung zu verdeutlichen.
Der Autor stellt auch fest, dass das Kontextwachstum oft zu einer verbesserten Leistung und realen Nutzungsfähigkeiten führt, was der Vorstellung einer strikt negativen Korrelation widerspricht. Sie räumen jedoch ein, dass in bestimmten Anwendungsfällen oder bei schlecht gestalteten Kontexten eine Leistungsverschlechterung auftreten kann.
Um die überwältigende Auswahl an Tools zu bewältigen, wird ein ‘Teile und herrsche’-Ansatz vorgeschlagen. Dies beinhaltet das Hinzufügen eines Tools, das speziell für die Auswahl der relevantesten Tools für eine bestimmte Aufgabe entwickelt wurde. Dieses ‘Tool-Auswahl-Tool’ könnte ein weiterer LLM-Aufruf sein, der damit beauftragt ist, eine Teilmenge der verfügbaren Tools an den ‘übergeordneten’ Agenten zurückzugeben. Dieser geschichtete Ansatz fügt zusätzliche Indirektionsebenen hinzu, um die Komplexität zu bewältigen.
Das bloße Vorhandensein von Tools im Kontext kann jedoch die Ausgabe eines Modells erheblich verändern. Während kontextuell relevante Tools (die durch Techniken wie Retrieval-Augmented Generation oder RAG erreicht werden) von Vorteil sind, kann es schädlich sein, alle Tools hinter einer ‘get_tools’-Anfrage zu verstecken.
MCP als Transport- und Autorisierungsebene
MCP fungiert in erster Linie als Transport- und Wire-Format mit einem Anfrage/Antwort-Lebenszyklus, wobei der Schwerpunkt auf der Autorisierung auf Tool-Ebene liegt. Der Essay argumentiert, dass das größte Problem bei MCP darin besteht, dass es KI-Agenten nicht ermöglicht, Tools funktional zusammenzusetzen.
Der Autor postuliert, dass MCP überhaupt unnötig sein könnte, da LLMs bereits die Fähigkeit besitzen, mit APIs zu interagieren, die mit OpenAPI-Spezifikationen dokumentiert sind. Das fehlende Element ist die Autorisierung – die Fähigkeit zu steuern, auf welche APIs eine KI zugreifen kann. Anstelle von MCP schlägt der Autor vor, KIs HTTP-Anfragen stellen zu lassen und gleichzeitig die Autorisierung auf bestimmte Endpunkte anzuwenden. Dieser Ansatz steht im Einklang mit dem aktuellen Trend, bestehende APIs mit schlanken MCP-Tools zu versehen.
Ein besonders ärgerlicher Aspekt von MCP ist der fehlende Support für das Streaming von Tool-Call-Ergebnissen. Das einzelne Anfrage/Antwort-Paar zwingt Clients, Tools für die Paginierung wiederholt aufzurufen, was langwierige Prozesse behindert. Die Implementierung einer Streaming-Funktion, möglicherweise mit gRPC, könnte die Effizienz von MCP erheblich verbessern.
Die Leichtigkeit der Offenlegung sensibler Daten
Ein großes Problem bei MCP ist das Potenzial für die einfache Offenlegung sensibler Daten. Darüber hinaus macht MCP KI-Agenten nicht unbedingt zuverlässiger; es gewährt ihnen lediglich Zugriff auf mehr Tools, was die Zuverlässigkeit in bestimmten Situationen paradoxerweise verringern kann.
Der Autor räumt ein, dass er nicht erwartet, dass MCP alle diese Probleme löst oder dafür verantwortlich ist. Vielmehr schafft MCP eine größere Angriffsfläche für diese Probleme, was Anwendungsentwickler und Benutzer zur Wachsamkeit zwingt.
Analogien und Stadtplanung
Der Autor verwendet die Analogie der Stadtplanung, um das Problem zu veranschaulichen. Der Vergleich von MCP mit einer sechsspurigen Stadtstraße mit einer Geschwindigkeitsbegrenzung von 40 km/h verdeutlicht die Diskrepanz zwischen Design und beabsichtigter Nutzung. Die bloße Verhängung von Bußgeldern oder das Hinzufügen oberflächlicher ‘Korrekturen’ behebt nicht das zugrunde liegende Problem des schlechten Designs.
Eine effektive Stadtplanung beinhaltet die Gestaltung von Straßen, die die Einhaltung von Geschwindigkeitsbegrenzungen auf natürliche Weise fördern. In ähnlicher Weise sollte MCP so konzipiert sein, dass potenzielle Risiken von Natur aus gemindert werden, anstatt sich ausschließlich auf externe Kontrollen zu verlassen.
LLMs, die unerwünschte Aktionen ausführen
Der Artikel geht zu einer umfassenderen Kritik an Protokollen über, die es LLMs ermöglichen, Aktionen auf Diensten auszuführen. Der Autor identifiziert ein Kernproblem: LLMs können Aktionen ausführen, die Benutzer nicht ausführen sollen. Sie unterscheiden zwischen Aktionen, die LLMs unabhängig ausführen können, und solchen, die eine Benutzeraufforderung erfordern.
Während das ultimative Ziel darin bestehen mag, dass LLMs ganze Unternehmen verwalten, ist die Technologie für eine solche Autonomie noch nicht bereit. Derzeit möchten Benutzer möglicherweise nicht einmal, dass KIs E-Mails ohne vorherige Überprüfung senden.
Der Autor lehnt die Lösung ab, den Benutzer zur Bestätigung aufzufordern, und verweist auf das Risiko, dass Benutzer in ein Muster der automatischen Bestätigung (‘YOLO-Modus’) verfallen, wenn die meisten Tools harmlos erscheinen. Dies wird mit dem psychologischen Phänomen verglichen, dass Menschen mehr mit Karten als mit Bargeld ausgeben – ein Problem, das in menschlichem Verhalten und nicht in Technologie wurzelt.
Die grundlegende Frage: Warum nicht einfach APIs verwenden?
Eine wiederkehrende Frage in Diskussionen über MCP ist, warum nicht einfach APIs direkt verwendet werden.
MCP ermöglicht es LLM-Clients, die Benutzer nicht direkt steuern (z. B. Claude, ChatGPT, Cursor, VSCode), mit APIs zu interagieren. Ohne MCP müssten Entwickler benutzerdefinierte Clients mit LLM-APIs erstellen, was weitaus teurer wäre als die Verwendung vorhandener Clients mit einem Abonnement und das Erlernen der Verwendung bestimmter Tools.
Ein Entwickler teilt seine Erfahrung beim Aufbau eines MCP-Servers, um über USB eine Verbindung zu seinem FM-Hardwaresynthesizer herzustellen und so KI-gestütztes Sounddesign zu ermöglichen.
LLM-Clientintegration und Standardisierung
Das Kernproblem ist, dass nicht alle LLM-Clients die direkte API-Interaktion nativ unterstützen, wobei ChatGPT Custom GPT-Aktionen eine bemerkenswerte Ausnahme darstellen. Anthropic, Google und OpenAI haben vereinbart, MCP als gemeinsames Protokoll einzuführen, um den Prozess für LLM-gestützte Clients wie Claude, ChatGPT und Cursor zu rationalisieren.
MCP vereinfacht den Prozess für diejenigen, die LLM-Clients erstellen. Wenn Sie möchten, dass ein LLM mit einer API interagiert, können Sie nicht einfach einen API-Schlüssel angeben und erwarten, dass er funktioniert – Sie müssen einen Agenten erstellen.
MCP kann als eine Möglichkeit angesehen werden, APIs zu dokumentieren und zu beschreiben, wie sie aufgerufen werden, zusammen mit standardisierten Tools, um diese Dokumentation bereitzustellen und Aufrufe zu erleichtern. Es bietet gerade genug Abstraktion, um APIs ohne unnötige Komplikationen zu umschließen, aber diese Einfachheit kann auch dazu führen, dass sich Benutzer ‘ins eigene Fleisch schneiden’.
Die Effizienz und Wiederverwendbarkeit von MCP
Ohne MCP müssten Entwickler dem LLM jedes Mal, wenn es aufgerufen wird, wiederholt erklären, wie ein Tool verwendet wird. Dies birgt das Risiko, dass das LLM das Tool aufgrund vergessener Informationen oder nicht standardmäßigen API-Verhaltens nicht korrekt verwendet.
Dieses ständige Erklären und Duplizieren verschwendet Token im Kontext, was Kosten und Zeit erhöht. MCP rationalisiert diesen Prozess, indem es alle notwendigen Informationen bündelt, die Tool-Nutzung effizienter gestaltet und die Tool-Freigabe erleichtert.
Indem sie einem LLM-Anbieter ‘hier ist ein Tool, das Sie verwenden können’ zusammen mit der API-Dokumentation mitteilen, können Benutzer dieses Tool in mehreren Chats wiederverwenden, ohne wiederholte Erinnerungen. Dies ermöglicht es auch Desktop-LLM-Clients, sich mit lokal laufenden Programmen zu verbinden, wodurch das Problem betriebssystemspezifischer Ausführungsprozesse behoben wird.
MCP und lokaler Ressourcenzugriff
MCP erleichtert den Zugriff auf lokale Ressourcen wie Dateien, Umgebungsvariablen und Netzwerkzugriff für LLMs. Es ist so konzipiert, dass es lokal ausgeführt wird und dem LLM einen kontrollierten Zugriff auf diese Ressourcen gewährt.
Die Standard-LLM-Tool-Call-‘Form’ spiegelt die MCP-Tool-Call-‘Form’ genau wider, was sie zu einem unkomplizierten Standard für die Verbindung von Tools mit Agenten macht.
MCP fungiert als Brücke zwischen dem Funktionsaufrufschema, das dem KI-Modell bereitgestellt wird, und den zugrunde liegenden APIs. Es übersetzt Funktionsaufrufe in Tools und ermöglicht so eine nahtlose Kommunikation.
Wenn Sie ein Tool-Anbieter sind, bietet MCP ein standardisiertes Protokoll für KI-Agenten-Frontends, um sich mit Ihrem Tool zu verbinden. Dies beantwortet die Frage, warum das Standardprotokoll nicht einfach HTTP und OpenAPI sein kann.
MCP ist eine Meta-API, die Endpunkte und ihre Betriebsdetails in die Spezifikation einbezieht, sodass LLMs effektiver mit ihnen interagieren können.
MCP in bestimmten Szenarien
MCP kann Probleme lösen, wenn Benutzer Fragen stellen oder sich nicht sicher sind, welche APIs verwendet werden sollen. Es kann auch Anforderungen basierend auf früheren Nachrichten verarbeiten.
Ein Benutzer teilt seine Erfahrung, dass er das ‘X’ eines Benutzers abrufen und an einen Endpunkt senden möchte. Sie fanden MCP für eine so einfache Aufgabe übertrieben, was darauf hindeutet, dass es nicht immer für grundlegende API-Interaktionen erforderlich ist.
MCP wird mit einem FastAPI-Web-App-Framework zum Erstellen von Software verglichen, die über das Netzwerk kommunizieren kann und speziell für agentische Erlebnisse entwickelt wurde. Es kann als ‘Rails-for-Skynet’ angesehen werden, das ein standardisiertes Framework für die Entwicklung von KI-Agenten bietet.
Bedenken hinsichtlich der Kontrolle des Anbieters
Es gibt Bedenken, dass MCP vorangetrieben wird, um die anbieterseitige Kontrolle über das System zu erhöhen. LLM-Anbieter könnten schließlich den API-Zugriff einschränken, ähnlich wie Google die Verwendung von IMAP/SMTP mit Gmail erschwert hat.
Die Verwendung von OpenAPI ermöglicht es Agenten, API-Spezifikationen von /openapi.json abzurufen.
MCP ermöglicht schnelle Interaktionen, sodass Benutzer Aufgaben in Sekundenschnelle erledigen können, anstatt Zeit mit dem Vorbereiten von Eingabedaten, dem Senden an die API, dem Parsen der Ausgabe und dem Wiederholen des Prozesses für jede Nachricht zu verbringen.
Sandboxing und Sicherheitsrisiken
Eines der größten Probleme ist, wie sich die Ausgabe eines MCP-Servertools auf andere Tools im selben Nachrichtenthread auswirken kann. Dies erfordert Sandboxing zwischen Tools, um unbeabsichtigte Folgen zu verhindern. Invariant Labs haben dies mit Tool-Beschreibungen behoben, während andere MCP-Ressourcenanhänge verwendet haben. Das fehlende Sandboxing verschärft die Risiken von Prompt Injection.
Dies wird mit SQL-Injection verglichen – einem zusammengebastelten System, bei dem Schwachstellen an jedem Punkt mit minimaler Beobachtbarkeit ausgenutzt werden können.
Die Prompt-Schnittstelle ist auch anfällig für eine Form von SQL-Injection, da das Modell vertrauenswürdige Teile des Prompts nicht von benutzerbelasteten Eingaben unterscheiden kann. Um dies zu beheben, sind grundlegende Änderungen an Codierung, Decodierung und Modelltraining erforderlich.
Dies ermöglicht sowohl Prompt Injection als auch Tool Injection, was möglicherweise zur Ausführung nicht vertrauenswürdigen Codes führt.
Containerisierung und kontrollierter Zugriff
Ein Entwickler hat einen MCP-Server erstellt, der einen Docker-Container mit gemountetem Projektcode startet. Dieser Ansatz ermöglicht es dem LLM, innerhalb einer Sandbox-Umgebung auf das gesamte Unix-Toolset und projektspezifische Tools zuzugreifen.
Dieser agentische Workflow, der über eine Chat-basierte Schnittstelle gesteuert wird, hat sich als effektiver erwiesen als herkömmliche Methoden.
Der Schlüssel liegt darin, MCP-Agenten Zugriff auf das zu gewähren, was sie benötigen, und auf nichts mehr. Containerisierung und transparente Tool-UX sind entscheidend für die Minderung von Sicherheitsrisiken.
Virtuelle Maschinen und Internetzugang
Agenten einen Computer mit einer minimalen Linux-Installation (als VM oder Container) zu geben, kann zu besseren Ergebnissen führen, da sie Informationen aus dem Internet abrufen können. Dies wirft jedoch Sicherheitsbedenken hinsichtlich bösartiger Anweisungen und Datenexfiltration auf.
Die Beschränkung des Zugriffs auf vertrauenswürdige Websites kann einige Risiken mindern, aber selbst vertrauenswürdige Quellen können bösartige Inhalte hosten. Der Kompromiss zwischen der Wahrscheinlichkeit, auf bösartige Anweisungen zu stoßen, und den Produktivitätsvorteilen muss sorgfältig abgewogen werden.
Die Unterschiede zwischen Mitarbeitern und KI-Agenten sind erheblich. Mitarbeiter sind juristische Personen, die Gesetzen und Verträgen unterliegen, was für Rechenschaftspflicht sorgt. KI-Agenten fehlt dieser rechtliche Rahmen, was das Vertrauen erschwert.
Die frühen Phasen der MCP-Entwicklung
MCP wurde erst im November 2024 angekündigt, und der RFC entwickelt sich aktiv weiter.
Einige betrachten das gesamte Konzept des KI-persönlichen Assistenten, einschließlich MCP, als grundlegend fehlerhaft.
Der erste Vorstoß für KI-Assistenten in den späten 1990er und frühen 2000er Jahren scheiterte, weil Content-Aggregatoren mit vertikaler Integration und Massenkaufkraft sich als effektiver erwiesen. Dies führte zum Aufstieg von Plattformen wie Expedia und eBay.
Multi-Agenten-Systeme erfordern, dass Programmierer den Zustand von Agenten beeinflussen, eine herausfordernde Programmieraufgabe.
Die Grenzen des freien Werts
Der Wunsch, ‘Ergebnisse nach Parkplatzverfügbarkeit zu ordnen’, unterstreicht das Problem des Zugriffs auf Daten hinter kostenpflichtigen APIs oder werbefinanzierten Frontends. Es ist unwahrscheinlich, dass Unternehmen den freien Zugriff auf ihren gesamten Datensatz über eine API gewähren.
Während nicht alle Unternehmen ihre Daten in KI-Agenten integrieren werden, ist das Potenzial, verschiedene Tools zur Stromversorgung von Workflows zu kombinieren, weiterhin erheblich.
Unternehmen, die der Aufrechterhaltung eines Datengrabens Priorität einräumen, werden sich neuen Technologien, die diesen Graben bedrohen, wahrscheinlich widersetzen.
Wenn booking.com eine API hätte, würden sie wahrscheinlich die gleichen Ergebnisse wie ihre Website zurückgeben, möglicherweise mit JSON- oder XML-Formatierung.
Umgehung des Mittelsmanns
Es macht wenig Sinn, dass ein Mittelsmann wie booking.com Benutzern die vollständige Umgehung ihrer Dienste ermöglicht.
Einzelne Hotels könnten es jedoch als vorteilhaft erachten, booking.com zu umgehen, einen Mittelsmann, den sie oft nicht mögen.
Eine Deep Research AI könnte nach Hotels basierend auf bestimmten Kriterien suchen und mit Hotel Discovery MCP-Servern interagieren, die von einzelnen Hotels betrieben werden, wodurch die Notwendigkeit entfällt, die Benutzeroberfläche und die Anzeigen von booking.com zu durchsuchen.
Praktische Anwendungsfälle
MCP kann Aufgaben wie das Abrufen von Protokollen von Elasticsearch oder das Abfragen von Datenbanken auf strukturiertere Weise erleichtern.
Die statische Natur der MCP-Serverkonfiguration, bei der neue Server das Bearbeiten einer .json-Datei und das Neustarten der App erfordern, kann einschränkend sein.
Fein abgestimmte Modelle
MCP kann als ein kleines, fein abgestimmtes Modell angesehen werden, das zahlreiche MCP-Tools versteht und für jedes Gespräch die richtigen auswählt.
Das dynamische Anpassen von Tools basierend auf dem Kontext kann für bestimmte Szenarien erforderlich sein.
Offene Gespräche und Geschäftsprobleme
MCP eignet sich gut für allgemeine, offene Gesprächssysteme ohne vordefinierten Ablauf. Es ist jedoch keine Universallösung für jedes Geschäftsproblem. Es soll Frameworks wie LangChain nicht ersetzen.
Die Alternative zu MCP, einem offenen, von der Community gesteuerten Standard, sind fragmentierte, proprietäre und anbietergebundene Protokolle. Ein fehlerhafter, sich aber entwickelnder Standard ist besser als gar kein Standard.
Am besten betrachtet man MCP als eine Verlagerung von einzelnen Entwicklern, die Client-Wrapper um APIs erstellen, hin zu API-Anbietern oder von der Community gepflegten Wrapper-Erstellern. Dies bietet einen großen Werkzeugkasten, ähnlich wie NPM oder PyPi. Orchestrierung, Sicherheit und Nutzungsdefinition sind jedoch weiterhin erforderlich.
Die nächste Generation von Langchains wird von diesem größeren Werkzeugkasten profitieren, aber Innovation ist immer noch erforderlich.
Benutzerspezifische Tools
In einigen Fällen können Tools spezifisch für Benutzerdaten sein, z. B. Tools zum Schneiden und Bearbeiten hochgeladener CSV-Dateien.
Ein oft übersehenes Problem ist, dass MCP den Modellkontext mit zu vielen Optionen überladen kann. Priorisierung und Metadaten-Offenlegung sind entscheidend, um verschwenderische Token-Nutzung und unregelmäßiges Modellverhalten zu vermeiden.
Standards und sich entwickelnde Technologie
Im Laufe der Zeit entstehen neue Standards, und es ist so lange her, dass Standards wirklich wichtig waren, dass die Leute vergessen haben, wie sie sich entwickeln.
Das Herunterladen winziger Serverprogramme von zufälligen Entwicklern, um LLM-Clients ‘Tools’ hinzuzufügen, kann riskant sein.
Die aufgeworfenen Probleme sind legitime Probleme, die das MCP-Ökosystem angehen muss. Einige Lösungen werden innerhalb der MCP-Spezifikation liegen, während andere extern sein werden.
Claude-Code und reale Nutzung
Es gibt gegensätzliche Meinungen zum Erfolg von MCP. Einige haben Geschichten von Unternehmen gehört, die sich in MCP integrieren, während andere von Benutzern gehört haben, die es enttäuschend fanden.
Dies unterstreicht den Nachteil von Hype und früher Einführung.
Einige Entwickler finden, dass HTTP-APIs für die meisten Anwendungsfälle MCP überlegen sind. Sie argumentieren, dass die Verwendung von ‘Tools’ auf API-Endpunkte für Fähigkeiten und Funktionen hinausläuft.
APIs sind standardmäßig nicht selbstbeschreibend, was eine verpasste Gelegenheit für REST- und HATEOAS-Befürworter darstellt, ihre Ansätze zu präsentieren.
MCP als LangChain-Alternative?
MCP wurde als mit einem ‘LangChain-Geruch’ behaftet beschrieben – es löst kein dringendes Problem, ist übermäßig abstrakt und hat Schwierigkeiten, seine Vorteile zu erklären.
Vielleicht muss es ‘END OF LINE’ sagen und Möchtegern-Hackern ins Game Grid verbannen!
Eine Schlüsselfrage ist, ob das ‘allgemeine’ Chatbot-Paradigma bestehen bleibt. Spezialisierte Apps mit eigenen Tools benötigen möglicherweise kein MCP.
Umgekehrt könnten externe Tools weniger notwendig werden, wenn LLMs leistungsfähiger werden. Warum sollten Sie ein MCP verwenden, um Photoshop anzusteuern, wenn das LLM das Bild einfach direkt bearbeiten könnte?
Der Sci-Fi-Roboterassistent-Traum verwirklicht sich möglicherweise nicht, und spezialisierte Sprachmanipulationswerkzeuge könnten nützlicher sein.
Die Benutzerbasis und das Sicherheitsbewusstsein
Die Benutzerbasis von MCP umfasst weniger technikaffine Personen, was Sicherheitsfragen besonders relevant macht. Die Sensibilisierung für bewährte Sicherheitspraktiken ist entscheidend.
Die Basierung von Xops auf OpenRPC, das die Definition des Ergebnisschemas erfordert, hilft bei der Planung, wie Ausgaben mit Eingaben verbunden werden, wodurch die Zuverlässigkeit komplexer Workflows verbessert wird.
Die Technologie wird sich wahrscheinlich im Laufe der Zeit weiterentwickeln und festigen.
Redundanz und Cloud-Infrastruktur
Einige stellen die Vorteile der Verwendung von MCP gegenüber dem OpenAPI-Standard in Frage und betrachten es als redundant.
Was wird das LLM verwenden, um ein OpenAPI-System aufzurufen? Wie wird es an die Shell gebunden? Wie wird der Host des LLM das orchestrieren?
MCP bietet eine strukturierte Möglichkeit für LLMs, Tool-Aufrufe zu tätigen.
MCP-Server sind bereits HTTP-Server.
Der größte Vorteil von MCP liegt für LLM-Anbieter wie OpenAI und nicht für Anwendungsentwickler.
LLMs sind Gehirne ohne Werkzeuge, und Tool-Aufrufe befähigen sie. Bei normalen APIs haben LLM-Anbieter jedoch keinen Zugriff auf diese Tools. MCP gewährt ihnen Zugriff und positioniert sie als Gateway zur KI.
CLI vs. API
Warum nicht die CLI direkt verwenden, da LLMs auf natürlicher Sprache trainiert werden und CLIs eine gängige, für Menschen lesbare und beschreibbare Lösung darstellen?
MCP entstand zu schnell und braucht Zeit, um zu reifen. Es fehlt die Prüfung durch eine konventionelle Normungsorganisation und wird durch Hype angetrieben.
Es mangelt an realen Anwendungen.
Wichtige Anwendungen von MCP
MCP wird in Claude Desktop und Nischen-KI-Chat-Apps, Code-Automatisierungstools und Agenten-/LLM-Automatisierungs-Frameworks verwendet.
Es ist eine weitere überstürzte Technologie, die wahrscheinlich verworfen wird, wenn das nächste Hype-fähige Akronym eintrifft.
Es gibt zwei Arten von Tool-Calling-Protokollen für Sprachmodelle: die, über die sich die Leute beschweren, und die, die niemand verwendet.
Anthropic hat diesen ‘Standard’ in einem Vakuum entwickelt, was zu Sicherheitsproblemen geführt hat.
JSON-RPC 2.0
MCP basiert auf JSON-RPC 2.0, einem schlanken Protokoll, das die Client-Server-Kommunikation mithilfe von JSON ermöglicht.
Es fühlt sich an wie eine zentralisierte Spezifikation, die für ein bestimmtes Ökosystem entwickelt wurde und Universalität beansprucht, ohne sie zu verdienen.
MCP ist leistungsstark genug, um nützliche Dinge zu tun, was Sicherheitsbedenken aufwirft.
Es ist kein ausgereifter Standard und wurde nicht auf Sicherheit ausgelegt.
Es gibt zwar Empfehlungen, diese werden jedoch nicht erzwungen oder umgesetzt.
Langchain und Tool-Aufrufe
Langchain ist eines von vielen Frameworks, die das Muster ‘Tool-Aufruf’ implementieren.
MCP ist eine Spezifikation dafür, wie externe Informationen in das Kontextfenster eines Sprachmodells gelangen, einschließlich Tool-Aufrufe, Vorlageneingabe, Abbruch, Fortschrittsverfolgung und Zustandsbehaftung von Tool-Servern.
Es hilft, Details zu standardisieren, sodass jede Assistenten-/Integrationskombination kompatibel ist.
MCP hat zwar legitime Probleme, aber Kritiker sollten ihre Argumente verfeinern.
Die Authentifizierung ist entscheidend und hätte in der ursprünglichen Version nicht fehlen dürfen.
Es gibt zu viele Komplexitäten.