MCP: Kein Allheilmittel, aber ziemlich gut

MCP: Kein Allheilmittel, aber immer noch ziemlich gut

In der aktuellen KI-Landschaft erregt ein Konzept große Aufmerksamkeit: MCP, oder Model Context Protocol. Überraschenderweise hat die Aufmerksamkeit, die diesem Protokollsystem zuteil wird, selbst die neuesten Modellveröffentlichungen von OpenAI in den Schatten gestellt und ist zu einem zentralen Punkt in Branchengesprächen geworden.

Der Popularitätsschub der Agent-Technologie, der durch den Aufstieg von Manus ausgelöst wurde, hat die Begeisterung globaler Entwickler befeuert. MCP, das als ‘vereinheitlichtes Protokoll’ für den Aufruf von Agent-Tools positioniert ist, hat schnell an Zugkraft gewonnen und sich innerhalb von nur zwei Monaten die Unterstützung von großen KI-Playern wie OpenAI und Google gesichert. Dieser rasante Aufstieg hat MCP von einer relativ unbekannten technischen Spezifikation in einen grundlegenden Standard innerhalb des KI-Ökosystems verwandelt und ein ‘phänomenales Ereignis’ im Bereich der KI-Infrastruktur markiert.

Doch mit dem Abklingen der anfänglichen Begeisterung tauchen kritische Fragen auf: Ist MCP wirklich universell einsetzbar? Sind die Erwartungen an seine Fähigkeiten zu hoch gesteckt?

Diese Untersuchung befasst sich mit den Ursprüngen von MCP, seziert seine Kernstärken und -schwächen, klärt weit verbreitete Missverständnisse auf und untersucht seine mögliche zukünftige Entwicklung. Ziel ist es nicht, den inhärenten Wert von MCP zu verwerfen, sondern ein fundierteres Verständnis seiner Rolle und Grenzen zu fördern. Nur durch solche Klarheit kann sein Potenzial voll ausgeschöpft werden.

Enthüllung von MCP: Ein Unified Tool Invocation Protocol

Definition von MCP

MCP ist ein offenes technisches Protokoll, das entwickelt wurde, um die Art und Weise zu standardisieren, wie Large Language Models (LLMs) mit externen Tools und Diensten interagieren. Man kann es sich als einen universellen Übersetzer innerhalb der KI-Welt vorstellen, der es KI-Modellen ermöglicht, mit einer Vielzahl von externen Tools zu ‘kommunizieren’. Es bietet eine gemeinsame Sprache und Struktur für LLMs, um Funktionalitäten anzufordern und zu nutzen, die von verschiedenen Anwendungen und Diensten angeboten werden.

Der Bedarf an MCP

Vor dem Aufkommen von MCP war der Aufruf von KI-Tools durch zwei wesentliche Herausforderungen geplagt:

• Interface Fragmentation: Jedes LLM verwendete unterschiedliche Anweisungsformate, während jede Tool-API ihre eigenen Datenstrukturen hatte. Entwickler waren gezwungen, benutzerdefinierten Verbindungscode für jede Kombination zu schreiben, was zu einem komplexen und ineffizienten Entwicklungsprozess führte.
• Development Inefficiency: Dieser ‘Eins-zu-eins-Übersetzungsansatz’ erwies sich als kostspielig und schwer zu skalieren. Es war, als würde man für jeden ausländischen Kunden einen eigenen Übersetzer einstellen, was die Produktivität und Agilität beeinträchtigte.

MCP begegnet diesen Schwachstellen, indem es ein standardisiertes Framework für LLMs bereitstellt, um mit externen Tools zu interagieren, den Entwicklungsprozess zu vereinfachen und eine größere Skalierbarkeit zu ermöglichen.

Verständnis der Funktionalität von MCP

Die technische Architektur von MCP kann als ein System konzipiert werden, das aus drei Kernkomponenten besteht: MCP Host, MCP Client und MCP Server. Diese Elemente arbeiten synergetisch zusammen, um eine nahtlose Kommunikation zwischen KI-Modellen und der Außenwelt zu ermöglichen.

Um die Rolle von MCP zu verstehen, betrachten Sie eine moderne Unternehmensumgebung. In dieser Analogie:

• Users repräsentieren leitende Angestellte, die für das Verständnis der Benutzerbedürfnisse und die Treffen von endgültigen Entscheidungen verantwortlich sind.
• Large Language Models (LLMs) (wie Claude oder GPT) verstehen Anweisungen von Führungskräften, planen Aufgabenschritte, bestimmen, wann externe Dienste genutzt werden sollen, und konsolidieren Informationen, um Antworten zu liefern.
• Agent Systems fungieren als persönliche Assistenten oder Chefsekretäre, die Aufgaben gemäß den Anweisungen ausführen.
• MCP fungiert als standardisierte Kommunikationsplattform oder Enterprise Service Access System, das von den Sekretären verwendet wird. Es trifft keine Entscheidungen, sondern befolgt Anweisungen und kommuniziert mit verschiedenen Dienstleistern in einem einheitlichen Format und Protokoll.

Vor MCP ähnelte die KI-Interaktion mit externen Tools einer Ära chaotischer Kommunikationsstandards. Jedes Mal, wenn ein Sekretär (Agent) eine andere Abteilung oder einen externen Lieferanten kontaktieren musste, musste er ein anderes Kommunikationsgerät oder eine andere Software verwenden. Dies erforderte die Vertrautheit mit verschiedenen Systemen, was zu Ineffizienzen führte. Entwickler mussten für jedes Tool separate Verbindungscodes schreiben, was zu Zeitverschwendung und eingeschränkter Skalierbarkeit führte.

MCP rationalisiert diesen Prozess, indem es eine einheitliche Kommunikationsplattform bereitstellt, die es Sekretären ermöglicht, jede Abteilung oder jeden Dienstleister über dasselbe System und Kommunikationsprotokoll zu kontaktieren. Entwickler müssen die MCP-Schnittstelle nur einmal implementieren, wodurch KI-Systeme mit allen Tools interagieren können, die das Protokoll unterstützen.

MCP: Eine Toolbox, die auf Function Call basiert

Es ist wichtig zu verstehen, dass MCP kein Ersatz für traditionelle Function Call ist, sondern eine komplementäre Komponente, die ihre Fähigkeiten erweitert.

Function Call ist der Kernmechanismus, mit dem LLMs mit externen Tools oder APIs interagieren. Es ist eine grundlegende Fähigkeit von LLMs, die es ihnen ermöglicht, zu erkennen, wann ein Tool benötigt wird und welche Art von Tool erforderlich ist.

MCP fungiert als Tool-Klassifizierungssystem und bietet ein strukturiertes Framework für die Organisation und den Zugriff auf verschiedene Tools. Daher ersetzt MCP nicht Function Call, sondern arbeitet in Verbindung mit Agents, um komplexe Aufgaben zu erledigen.

Der vollständige Tool-Aufrufprozess umfasst eine Kombination aus ‘Function Call + Agent + MCP System’.

Im Wesentlichen drückt das LLM die Notwendigkeit aus, ein bestimmtes Tool über Function Call aufzurufen. Der Agent befolgt die Anweisungen zur Ausführung des Tool-Aufrufs, während MCP eine standardisierte Tool-Aufrufspezifikation bereitstellt.

Betrachten Sie die folgende Analogie: Ein Chef (Benutzer) möchte Kaffee. Im Büro (MCP Host) weist der Büroleiter (LLM) den Sekretär (Agent) an, einen Americano zu kaufen (Function Call). Der Sekretär überprüft die Lieferantenliste und stellt fest, dass ein Americano-Kaffeelieferant entweder in Meituan oder in das einheitliche Beschaffungssystem des Unternehmens integriert ist (MCP Server implementiert). Der Sekretär findet dann den Lieferanten im Beschaffungssystem (MCP Client) und gibt eine Bestellung auf.

Zuvor, ohne MCP, würde der Agent, wenn das LLM einen Function Call ausgab, übersetzen und sich direkt mit der API verbinden, um das Tool aufzurufen. Jede API erforderte einen separaten Aufrufmodus und eine definierte Tool-Liste und einen Aufrufmodus, den der Agent interpretieren musste. Mit MCP können viele APIs direkt über den MCP Client des Lieferanten bestellt werden, was dem Agent Zeit und Mühe spart. Der Function Call des LLM bleibt jedoch unverändert, immer noch im Format {tool: ‘Kaffee kaufen’, ‘type’: ‘Americano’}.

Durch die Unterscheidung zwischen Function Call und MCP wird deutlich, dass MCP weder bestimmt, welches Tool verwendet werden soll, noch die Aufgabenplanung oder die Benutzerabsicht übernimmt. Diese Aspekte fallen in den Zuständigkeitsbereich der Agent-Ebene. MCP bietet lediglich eine einheitliche Tool-Schnittstelle und wird zu einem anerkannten Standardprotokoll innerhalb der Branche.

Die Entwicklungsherausforderungen und die Marktlandschaft von MCP

Das Entwicklungsrätsel

Seit Februar hat die KI-Entwicklungsgemeinschaft einen ‘MCP-Goldrausch’ erlebt. In Ermangelung eines offiziellen App Stores haben Tausende von Tools innerhalb von drei Monaten freiwillig in das MCP-Protokoll integriert.

Dieses schnelle Wachstum hat MCP ins Rampenlicht der Branche gerückt, aber auch die Kluft zwischen Anspruch und Wirklichkeit aufgezeigt. Entwickler betrachteten MCP anfangs als ‘universellen Schlüssel’, haben aber festgestellt, dass es eher ein ‘Spezialschlüssel’ ist, der in bestimmten Szenarien hervorragende Leistungen erbringt, sich aber in anderen als weniger effektiv erweist.

Die Teilnehmer von MCP können in lokale Client-Anwendungen, Cloud-Client-Anwendungen und MCP-Serverentwickler kategorisiert werden. Lokale Anwendungen ähneln lokalen KI-Assistenten, während Cloud-Client-Anwendungen webbasierten Versionen von ChatGPT ähneln. MCP-Serverentwickler sind die eigentlichen Anbieter von Tools, die ihre APIs neu verpacken müssen, um den MCP-Regeln zu entsprechen.

Das Aufkommen von MCP wurde anfänglich von lokalen Client-Anwendungen begrüßt, Cloud-Client-Anwendungen und MCP-Serverentwickler standen jedoch vor Herausforderungen.

MCP stammt von der Claude Desktop-Anwendung von Anthropic, die ursprünglich als Schnittstellenprotokoll für den Aufruf lokaler Dateien und Funktionen entwickelt wurde und tief in den clientseitigen Anforderungen verwurzelt ist.

Für lokale Client-Benutzer stellte MCP eine Revolution dar und bot eine unendlich erweiterbare Toolbox, die es den Benutzern ermöglichte, die Fähigkeiten ihrer KI-Assistenten kontinuierlich zu erweitern.

Lokale Client-Anwendungen wie Cursor und Claude Desktop haben MCP genutzt, um es Benutzern zu ermöglichen, Tools basierend auf individuellen Bedürfnissen dynamisch hinzuzufügen und so eine unbegrenzte Erweiterung der KI-Assistentenfunktionen zu erreichen.

MCP adressiert einen zentralen Schwachpunkt in der lokalen Client-Entwicklung: wie KI-Anwendungen nahtlos mit lokalen Umgebungen und externen Tools interagieren können, ohne separate Schnittstellen für jedes Tool zu entwickeln. Dieses einheitliche Protokoll reduziert die Integrationskosten erheblich und bietet kleinen Startups und einzelnen Entwicklern eine Abkürzung zum Erstellen von funktionsreichen KI-Anwendungen mit begrenzten Ressourcen.

Die Attraktivität von MCP nimmt jedoch ab, wenn man die serverseitige Entwicklung (MCP Server) und Cloud-Clients berücksichtigt. Frühe Versionen von MCP verwendeten einen Dual-Link-Mechanismus für Cloud-Server (Remote), wobei eine SSE-Langzeitverbindung für das unidirektionale Pushen von Nachrichten vom Server zum Client und eine HTTP-Kurzzeitverbindung zum Senden von Nachrichten verwendet wurde.

Dieser Ansatz funktionierte gut für zeitnahes Benutzerfeedback und Eingreifen, schuf jedoch eine Reihe von technischen Herausforderungen in serverseitigen Umgebungen.

Erstens stellt die Implementierung der MCP-Schnittstelle eine zusätzliche Arbeitsbelastung für große Unternehmensdienstanbieter dar, ohne dass dies unbedingt zu entsprechenden Vorteilen führt. Diese Dienste verfügen oft über ausgereifte API-Systeme, und die Bereitstellung einer zusätzlichen MCP-Anpassungsschicht kann nur die Wartungskosten erhöhen, ohne einen wesentlichen Mehrwert zu schaffen. Viele Anwendungen auf Unternehmensebene bevorzugen geschlossene, steuerbare Tool-Aufrufmechanismen gegenüber dem offenen Ökosystem von MCP.

Darüber hinaus müssen MCP-Dienste zur Handhabung von Aufrufen mit hoher Parallelität oft auf Multi-Server-Architekturen skaliert werden. Das Dual-Connection-Modell von MCP führt die Komplexität der rechnerübergreifenden Adressierung ein. Wenn eine Langzeitverbindung auf einem Server hergestellt wird und eine Anforderung an einen anderen Server weitergeleitet wird, ist ein zusätzlicher Broadcast-Warteschlangenmechanismus erforderlich, um diese verteilten Verbindungen zu koordinieren, was die Implementierungsschwierigkeit und die Wartungskosten erheblich erhöht.

Zweitens hat MCP Einschränkungen im Bereich der Cloud-Anwendungen. Cloud-KI-Agenten (serverseitige Agenten) werden in der Regel in zustandslosen Diensten ausgeführt, verarbeiten Aufgaben nach der Annahme und geben Ressourcen nach Abschluss frei. Die Verwendung von MCP Client auf der Serverseite erfordert die temporäre Erstellung eines SSE-Links, das Senden einer Tool-Aufrufanforderung, den Empfang des Ergebnisses vom SSE und das anschließende Schließen des SSE-Links, was ein ineffizienter Ansatz ist, der die Komplexität erhöht und die Leistung reduziert. Eine einzelne RPC-Anforderung sollte in diesem Szenario ausreichen.

In der Praxis verlassen sich Cloud-Anwendungen, die MCP verwenden, oft auf voreingestellte Toolsets und nutzen nicht die Signaturfähigkeit von MCP zur dynamischen Tool-Erkennung und zum flexiblen Laden.

Der Datenaustauschmodus von Cloud-Umgebungen schränkt die Möglichkeit ein, Tools so frei zu verwenden, wie MCP es beabsichtigt. Er erfordert einen hochstandardisierten Prozess für den Aufruf bestimmter, fest codierter Tools, was die Flexibilität beeinträchtigt.

Das MCP-Team hat seine Reaktionsfähigkeit auf Benutzerfeedback unter Beweis gestellt. Nach Erhalt von Feedback von serverseitigen Entwicklern aktualisierte MCP sein Protokoll am 26. März und ersetzte den ursprünglichen SSE-Transport durch streamable HTTP-Transport. Das neue Protokoll unterstützt sowohl zustandslose Dienstszenarien, die nur einzelne Tool-Aufrufanforderungen erfordern, als auch Echtzeit-Push-Anforderungen, die zuvor über HTTP + SSE-Dual-Links erfüllt wurden.

Diese Verbesserungen deuten darauf hin, dass die aktuellen MCP-Probleme auf anfängliche Designbeschränkungen zurückzuführen sind, aber nicht unüberwindbar sind.

Die Unordnung des Marktes

Eine weitere Herausforderung für MCP ist die geringe Benutzerfreundlichkeit vieler Implementierungen auf dem Markt.

Der aktuelle MCP-Markt erlebt einen typischen Technologie-Hype-Zyklus. Ähnlich dem Chaos des frühen App Stores haben weniger als 20 % der Tausenden von MCP-Tools, die derzeit verfügbar sind, einen praktischen Wert. Viele Implementierungen weisen schwerwiegende Probleme auf, von einfachen Konfigurationsfehlern bis hin zur vollständigen Unbrauchbarkeit. Einige werden ohne angemessene Tests auf den Markt gebracht, während andere experimentelle Produkte sind, die nie für den praktischen Einsatz bestimmt waren.

Ein grundlegenderes Problem ist, dass viele MCP-Implementierungen vom Markt möglicherweise nicht benötigt werden. Viele Tools, die über MCP angeboten werden, sind einfach neu verpackte APIs, die bereits vor dem Aufkommen von MCP verfügbar waren und verwendet wurden, was wenig Mehrwert bietet.

Beispielsweise werden Dutzende von Suchdiensten über MCP angeboten, deren Qualität jedoch erheblich variiert. Einige Dienste sind möglicherweise ungenau oder langsam, was sie weniger wünschenswert macht als bestehende Lösungen.

Darüber hinaus fehlt MCP ein robustes Bewertungssystem, das es Agenten erschwert, das am besten geeignete Tool anhand zuverlässiger Metriken auszuwählen. Dieser ineffiziente Auswahlprozess verschwendet Rechenressourcen, verlängert die Aufgabenabschlusszeiten und beeinträchtigt das Benutzererlebnis.

Das Fehlen eines Bewertungssystems erschwert es Agenten, das am besten geeignete Tool auszuwählen. Wenn mehrere MCP-Dienste Tools mit ähnlichen Namen und Beschreibungen anbieten, kann es für den Agenten schwierig sein, die beste Option auszuwählen, was zu verschwendeten Token und einer geringeren Effizienz führt.

Die erfolgreichsten KI-Anwendungen verfolgen oft den gegenteiligen Ansatz und bieten präzisere Tools anstatt einer größeren Anzahl von Tools. Manus beispielsweise entschied sich für den Aufbau interner Anwendungen anstelle der Einführung des MCP-Protokolls, obwohl dieses existierte. Manus priorisierte die Aufrufgenauigkeit und -stabilität gegenüber der Integration in das MCP-Ökosystem.

Code-Editoren wie Cursor verfügen über integrierte Entwicklungsfunktionen, wodurch die meisten externen MCP-Toolsüberflüssig werden.

Der aktuelle chaotische Zustand des MCP-Marktes ist nicht unbedingt ein Zeichen des Scheiterns, sondern ein notwendiges Wachstumsstadium für jedes aufstrebende Technologie-Ökosystem. Die historische Präzedenzfall deutet darauf hin, dass diese anfängliche Überausdehnung allmählich durch Marktselektionsmechanismen konvergieren wird, wobei die wertvollsten Elemente zurückbleiben.

Dieser Prozess wird es der Branche ermöglichen, aus den aktuellen Herausforderungen zu lernen und ein stärkeres, zuverlässigeres MCP-Framework zu schaffen. Ähnlich wie die Dotcom-Blase zu bahnbrechenden Innovationen im E-Commerce und in den sozialen Medien führte, kann der MCP-Trend zu einem rationalisierteren und wertvolleren Tool-Ökosystem führen.

Die offene Haltung des MCP-Teams gegenüber Benutzerfeedback ist ermutigend, und die Branche benötigt bessere Tools zur Bewertung und Sicherstellung der Qualität von MCP-Diensten, was dazu beitragen wird, das Ökosystem benutzerfreundlicher zu gestalten.

MCP ist gut, kein Allheilmittel

Die oben genannten Probleme ergeben sich aus den Einschränkungen und Mängeln von MCP und verdeutlichen, was es realistisch erreichen kann. Andere Kritikpunkte ergeben sich jedoch aus unrealistischen Erwartungen.

Ein aktueller Kritikpunkt bezeichnet MCP als fehlerhaftes Protokoll, weil es die Interaktionsmuster zwischen LLMs und MCP nicht vorgibt.

Einige erwarten, dass MCP die Entscheidungsfindung von KI-Systemen automatisch verbessert oder die Effizienz der Aufgabenplanung steigert. Diese Erwartung verwechselt Werkzeuge mit Handwerkern.

Das Problem rührt von einer kognitiven Diskrepanz her – der Erwartung, dass ein Kommunikationsprotokoll Aufgaben eines intelligenten Systems ausführt. Das ist, als würde man USB dafür verantwortlich machen, dass es keine Fotos bearbeitet, oder 5G-Standards dafür, dass sie keinen Code schreiben. MCP ist in erster Linie eine standardisierte ‘Tool-Buchse’, die die Steckkompatibilität gewährleistet, anstatt vorzuschreiben, welches Gerät verwendet werden soll oder wie.

Die Effektivität des Agent-Tool-Aufrufs hängt von Faktoren wie der Kompetenz bei der Tool-Auswahl, den Fähigkeiten zur Aufgabenplanung und dem Kontextverständnis ab, die alle nicht in den Zuständigkeitsbereich von MCP fallen. MCP garantiert nur eine standardisierte Tool-Schnittstelle, nicht wie diese Tools ausgewählt und kombiniert werden.

Wir suchen in der Technologie oft nach Allheilmitteln, universell einsetzbaren Lösungen. Wie das Axiom des Software-Engineerings ‘kein Allheilmittel’ gibt es auch für die KI-Tool-Nutzung keine magische Lösung. Ein starkes KI-System benötigt konzipierte Komponenten: LLMs zum Verstehen und Generieren, Agent-Frameworks zum Planen und Ausführen und MCP, das sich auf einheitliche Tool-Schnittstellen konzentriert.

MCP zeigt ein gutes Protokolldesign – die Konzentration auf ein Problem und dessen gute Lösung anstelle von allem. Seine Zurückhaltung hilft ihm, bei der clientseitigen Tool-Integration Fortschritte zu erzielen.

Unternehmen wie Alibabas Qwen, Baidus ‘Xinxiang’ und ByteDances Kouzi Space übernehmen das MCP-Protokoll und versuchen, effizientere interne MCP-Ökosysteme aufzubauen.

Es gibt jedoch wesentliche Unterschiede beim Einsatz: Baidu und ByteDance sind aggressiver. Baidu versucht einen C-End-Ansatz und integriert mehrere KI-Modelle und externe Tools über das ‘Xinxiang’ (Kokone), das das MCP-Protokoll nutzt, hauptsächlich für mobile Geräte, um sich in das tägliche Leben der Benutzer zu integrieren und die Akzeptanz zu fördern.

ByteDances Kouzi Space verfügt über mehr als 60 MCP-Erweiterungs-Plugins. Der Zugriff erfolgt über eine Webseite. Außerdem wurde eine KI-native IDE, Trae, auf den Markt gebracht, die MCP unterstützt und sich hauptsächlich an Produktivitätsszenarien richtet.

Alibaba integrierte das MCP-Protokoll in Produkte wie Alipay, was den KI-Tool-Aufruf mit einem Klick ermöglicht, und hat das Qwen3-Modell mit Open-Source versehen, das das MCP-Protokoll unterstützt und seine Agent-Fähigkeiten verbessert.

Tencent Cloud-Entwickler haben eine KI-Entwicklungssuite veröffentlicht, die MCP-Plugin-Hosting-Dienste unterstützt. Die Large Model Knowledge Engine von Tencent Cloud ermöglicht es Benutzern, MCP-Plugins aufzurufen. Der von Tencent Clouds CodeBuddy entwickelte intelligente Softwareentwicklungsagent Craft ist mit dem offenen MCP-Ökosystem kompatibel. Darüber hinaus haben Tencent Maps und Tencent Cloud Storage ihren eigenen MCP SERVER veröffentlicht.

Die Nutzung von KI-Tools kann sich von der direkten Bedienung einzelner Tools zu professioneller Agent-Zusammenarbeit entwickeln, so wie sich Programmierstile von der Assemblersprache zur Objektorientierung entwickelt haben.

In diesem Paradigma kann MCP einfach Teil der zugrunde liegenden Infrastruktur werden, anstatt einer benutzer- oder entwicklerorientierten Schnittstelle. Ein umfassenderer Plan erfordert möglicherweise Architekturen wie Agent to Agents (A2A), um die Effizienz der Aufgabenplanung und Tool-Auswahl durch Erhöhung der Abstraktionsebenen zu verbessern.

Indem wir MCP in seine ‘Protokoll’-Rolle zurückversetzen, können wir seine wahre Kraft zur Förderung der Branchenstandardisierung erkennen – dies ist möglicherweise der wertvollste ‘Entmystifizierungs’-Moment in der technologischen Entwicklung.