MCP löst nicht alle Integrationsprobleme – Microsoft Research warnt vor Grenzen

Das Model Context Protocol (MCP) gilt derzeit als Hoffnungsträger, wenn es darum geht, Integrationshürden zwischen KI-Systemen zu überwinden. Doch wie so oft bei neuen Technologien zeigt sich: Die Erwartungen sind höher als das, was die Realität bislang hergibt.

Forschende von Microsoft haben nun herausgestellt, dass MCP erhebliche Schwächen hat – insbesondere dann, wenn mehrere Agenten und MCP-Server gleichzeitig in einem Prozess arbeiten. In einem aktuellen Blogbeitrag unter dem Titel „Tool-Space-Interferenz im MCP-Zeitalter: Design für Agentenkompatibilität in großem Maßstab“ beschreibt Microsoft Research die Herausforderungen.

Die KI-Entwicklung hat in diesem Jahr enorme Fortschritte gemacht. Agentenbasierte Systeme können heute nicht nur tiefgehende Analysen durchführen, sondern auch Computer bedienen, komplexe Softwareprojekte stemmen oder mehrstufige Aufgabenketten bewältigen. Möglich wurde das vor allem durch sogenannte vertikale Integration: Tools und Agenten wurden gemeinsam entwickelt, trainiert und getestet – was eine reibungslose Zusammenarbeit sicherstellt.

Ein Beispiel: Die aktuellen Modelle von OpenAI nutzen standardmäßig Werkzeuge wie Websuche und Dokumentenabfrage. Auch bei Magentic-One sind Übergaben zwischen Agenten fest vorgesehen – der WebSurfer-Agent etwa kann heruntergeladene Dateien direkt an den Coder-Agenten weiterreichen.

Doch diese enge Verzahnung hat Grenzen. Mit der wachsenden Zahl an KI-Agenten werden künftig Systeme aufeinandertreffen, die nicht mehr aus einem Guss stammen, sondern von unterschiedlichen Unternehmen und Entwicklerteams. Microsoft spricht in diesem Zusammenhang von einer „Gesellschaft von Agenten“. Diese müssen lernen, miteinander zu interagieren – auch wenn ihre Ziele, Koordinationsmechanismen oder Informationsflüsse nicht immer kompatibel sind.

Die entscheidende Frage lautet daher: Werden heterogene Agenten in der Lage sein, produktiv zusammenzuarbeiten? Oder führen Interferenzen im „Tool-Space“ am Ende zu Behinderungen, die den Fortschritt der KI-Entwicklung bremsen?

Werden Agenten und Werkzeuge in diesem Umfeld harmonisch zusammenarbeiten – oder sich gegenseitig behindern und damit den Fortschritt verlangsamen? Erste Hinweise liefert das Model Context Protocol (MCP), eine Technologie, die seit Januar 2025 einen rasanten Aufstieg erlebt hat: von einer vielversprechenden Spezifikation hin zu einem florierenden Markt für Tool-Server.

So bietet Zapier inzwischen einen Katalog mit 30.000 Tools für 7.000 Dienste. Composio verwaltet über 100 MCP-Server mit Hunderten von Tools. Hugging Face stellt zahlreiche Spaces-Apps über MCP bereit, und Shopify hat die Technologie für Millionen von Storefronts aktiviert. Eine „Gesellschaft der Tools“ ist damit bereits Realität und soll die Fähigkeiten von Agenten durch anbieterübergreifende horizontale Integration erweitern.

Doch wie steht MCP tatsächlich zur horizontalen Integration? Mit dem schnellen Wachstum der Kataloge zeichnen sich neue Fehlermodi ab. Microsoft Research beschreibt diese als „Tool-Space-Interferenz“ und skizziert erste Beobachtungen sowie pragmatische Gegenmaßnahmen, um zu verhindern, dass die Gesellschaft der Tools sich selbst blockiert.

Unter Tool-Space-Interferenz verstehen die Forschenden Situationen, in denen an sich sinnvolle Tools oder Agenten in Kombination ihre Effektivität verlieren. Dies kann zu längeren Aktionssequenzen, steigenden Token-Kosten, erschwerter Fehlersuche oder sogar zum Scheitern ganzer Aufgaben führen.

Ein Beispiel für die Einbindung

Betrachten wir MCP als Erweiterung für Magentic-One, ein generalistisches Multi-Agenten-System, das wir im vergangenen Jahr veröffentlicht haben, um mehr Software-Engineering-Aufgaben abzudecken. Magentic-One wird mit Agenten ausgeliefert, die Code schreiben, mit dem Computerterminal interagieren, im Internet surfen und auf lokale Dateien zugreifen können.

Um Magentic-One bei Versionskontrolle, der Suche nach zu lösenden Problemen und der Erstellung von Pull-Anfragen zu unterstützen, könnte ein Agent hinzugefügt werden, der mit dem GitHub MCP Server ausgestattet ist. Das Team muss dann jedoch jedes Mal entscheiden, wie es mit GitHub-Aufgaben vorgeht: github.com im Browser aufrufen, einen Git-Befehl in der Befehlszeile ausführen oder den MCP-Server nutzen.

Während der Bearbeitung kann es zu Abweichungen im Verständnis des Zustands durch die Agenten kommen: Änderungen des Branches im Browser wirken sich nicht automatisch auf das Terminal aus, und ein autorisiertes MCP-Tool bedeutet nicht automatisch eine Berechtigung im Browser.

Ein einzelner Agent kann die Aufgabe effizient erledigen. Bei mehreren Agenten hingegen können Missverständnisse oder gegenseitige Störungen auftreten, was zusätzliche Debugging-Runden erfordert oder im schlimmsten Fall zum Scheitern der Aufgabe führt.

Microsoft-Forscher untersuchen Tool-Space-Interferenzen aus Sicht von MCP

Um die potenziellen Interferenzmuster und den aktuellen Stand des MCP-Ökosystems besser zu verstehen, führten die Forscher eine Umfrage unter MCP-Servern durch, die in zwei Registern aufgeführt sind: smithery.ai und Docker MCP Hub. Smithery listet über 7.000 First-Party- und Community-Beiträge, die aus der Smithery-API entnommen wurden. Docker MCP Hub verteilt MCP-Server als Docker-Images, wobei beliebte Einträge manuell gesammelt wurden. Jeder Server wurde anschließend zur Überprüfung gestartet. Nach Ausschluss leerer oder nicht startbarer Server sowie der Bereinigung von Duplikaten blieben 1.470 Server im Katalog.

Zur Automatisierung der Überprüfung entwickelten die Forscher das MCP-Interviewer-Tool. Dieses katalogisiert Tools, Eingabeaufforderungen, Ressourcen, Ressourcenvorlagen und Fähigkeiten des Servers. Aus diesen Daten lassen sich deskriptive Statistiken wie die Anzahl der Tools oder die Tiefe der Parameterschemata berechnen. Anschließend erstellt der Interviewer mit Hilfe eines LLM (OpenAI GPT-4.1) einen funktionalen Testplan, der jedes Tool mindestens einmal aufruft und dabei Ausgaben, Fehler und Statistiken sammelt. Darüber hinaus kann der Interviewer qualitativere Kriterien bewerten, indem speziell entwickelte Rubriken auf Tool-Schemas und Tool-Ausgaben angewendet werden. Das MCP-Interviewer-Tool wird als Open-Source-CLI veröffentlicht, damit Entwickler ihre MCP-Server automatisch bewerten und Nutzer neue Server validieren können.

Die Umfrage liefert erste Einblicke, ist jedoch eingeschränkt. Eine zentrale Hürde ist die Autorisierung: Viele populäre MCP-Server erfordern für den Zugriff auf ihre Dienste eine Genehmigung, was automatisierte Tests erschwert. Während statische Merkmale oft erfasst werden können, sind die durchführbaren Funktionstests in diesen Fällen begrenzt.

Eine Größe passt für alle – aber nicht für jeden gleich gut

Was zeigt die Umfrage unter MCP-Servern über das Ökosystem? Die Zahlen liefern wichtige Einblicke, doch ein zentrales Muster fällt auf: MCP-Server wissen nicht, mit welchen Clients oder Modellen sie arbeiten, und stellen allen Nutzern denselben Satz an Tools, Prompts und Ressourcen zur Verfügung. Manche Modelle kommen jedoch besser mit langen Kontexten und umfangreichen Werkzeugräumen zurecht als andere und reagieren unterschiedlich auf gängige Eingabeaufforderungen. Der Leitfaden von OpenAI empfiehlt Entwicklern beispielsweise, beim Aufruf von Funktionen Beispiele und Randfälle zu berücksichtigen, um wiederkehrende Fehler zu vermeiden – warnt aber gleichzeitig, dass zusätzliche Beispiele die Leistung von Schlussfolgerungsmodellen beeinträchtigen können. In dieser Hinsicht stehen MCP-Server bereits im Nachteil gegenüber vertikalen Integrationen, die für eine bestimmte Betriebsumgebung optimiert sind.

Anzahl der Tools beeinflusst die Leistung

Obwohl die Leistungsfähigkeit der Modelle beim Aufruf von Tools variiert, zeigt sich ein klarer Trend: Mit steigender Anzahl von Tools sinkt die Genauigkeit. OpenAI begrenzt die Zahl der Tools für Entwickler auf 128 und empfiehlt, die Anzahl der Funktionen gering zu halten, um bessere Ergebnisse zu erzielen. Idealerweise sollten weniger als 20 Funktionen gleichzeitig genutzt werden, auch wenn dies nur eine unverbindliche Orientierung ist.

Derzeit kann ein großer Werkzeugraum die Leistung einzelner Modelle um bis zu 85 % reduzieren. Die meisten MCP-Server in der Umfrage enthalten jedoch vier oder weniger Tools. Ausreißer gibt es dennoch: Der größte katalogisierte Server bietet 256 Werkzeuge, während die zehn nächstgrößten Server jeweils mehr als 100 Tools enthalten. Beliebte Server wie Playwright-MCP mit 29 Tools oder GitHub MCP mit 91 Tools (teilweise über alternative Endpunkte verfügbar) könnten für manche Modelle bereits zu umfangreich sein.

Antwortlänge kann die Leistung stark beeinflussen

Tools werden häufig in agentenbasierten Schleifen aufgerufen, wobei die Ausgabe als Eingabekontext ins Modell zurückgeführt wird. Modelle unterliegen strengen Beschränkungen des Eingabekontexts, doch selbst innerhalb dieser Limits können große Kontexte die Kosten erhöhen und die Leistung mindern, sodass die praktischen Einschränkungen oft deutlich geringer ausfallen. MCP gibt keine Vorgaben, wie viele Tokens ein Toolaufruf erzeugen darf, und manche Antworten sind überraschend umfangreich.

In der Analyse wurden 2.443 Tool-Aufrufe über 1.312 unterschiedliche Tools untersucht. Die Mehrheit erzeugte 98 oder weniger Tokens, doch einige Tools sind extrem „schwergewichtig“: Das Spitzen-Tool lieferte im Durchschnitt 557.766 Tokens – genug, um die Kontextfenster vieler beliebter Modelle wie GPT-5 zu überlasten. Weitere 16 Tools erzeugten mehr als 128.000 Tokens und überschreiten damit die Kapazitäten von GPT-4o und anderen Modellen. Selbst wenn die Antworten ins Kontextfenster passen, können übermäßig lange Outputs die Leistung um bis zu 91 % verringern und die Anzahl zukünftiger Aufrufe einschränken. Agenten können eigene Strategien zum Kontextmanagement implementieren, doch die MCP-Spezifikation definiert kein standardisiertes Verhalten, sodass Serverentwickler nicht auf ein einheitliches Clientverhalten zählen können.

Komplexität der Werkzeugparameter

Ähnlich wie die Herausforderungen, die sich aus der zunehmenden Anzahl von Werkzeugen ergeben, kann auch die zunehmende Komplexität des Parameterbereichs eines Werkzeugs zu einer Verschlechterung führen. Während MCP-Tools beispielsweise komplexe Objekttypen und -strukturen als Parameter verwenden können, hat composio (öffnet in neuem Tab) herausgefunden, dass eine Vereinfachung des Parameterraums die Leistung beim Aufruf von Tools im Vergleich zur Basisleistung um 47 % verbessern kann. In der Analyse finden wir zahlreiche Beispiele für tief verschachtelte Strukturen – in einem Fall sogar mit einer Tiefe von 20 Ebenen.

Probleme mit Namespaces und Mehrdeutigkeit bei der Benennung

Ein weiteres häufig genanntes Problem der aktuellen MCP-Spezifikation ist das Fehlen eines formalen Namespace-Mechanismus. Wenn zwei Server für denselben Agenten oder dieselbe Anwendung registriert sind und die Server gemeinsame Tool-Namen haben, ist eine Eindeutigkeit nicht mehr möglich. Bibliotheken wie das OpenAI Agents SDK geben in diesem Fall eine Fehlermeldung aus. Clients wie Claude Code umgehen dieses Problem, indem sie den Toolnamen eindeutige Kennungen voranstellen. Bei unserer Analyse von MCP-Servern haben wir Namenskonflikte zwischen 775 Tools festgestellt. Der häufigste Konflikt war „search”, der auf 32 verschiedenen MCP-Servern auftrat. In der folgenden Tabelle sind die 10 häufigsten Konflikte aufgeführt.

Selbst wenn Namen eindeutig sind, können sie semantisch ähnlich sein. Wenn sich diese Tools ähnlich verhalten, ist die Redundanz möglicherweise nicht sofort problematisch, aber wenn Sie ein bestimmtes Tool aufrufen möchten, erhöht die Namensähnlichkeit das Verwirrungspotenzial. Die folgende Tabelle listet einige Beispiele für semantisch ähnliche Tool-Namen im Zusammenhang mit der Websuche auf:

Fehler und Fehlermeldungen

Wie alle Softwarebibliotheken stößt auch MCP gelegentlich auf Fehlerzustände. In diesen Fällen ist es wichtig, dem Agenten ausreichende Informationen zur Verfügung zu stellen, damit er den Fehler beheben und die nächsten Schritte planen kann. Die Analyse ergab, dass dies nicht immer der Fall war. MCP verfügt zwar über ein „IsError”-Flag, um Fehler zu signalisieren, aber es wurde festgestellt, dass Server Fehler häufig durch die Rückgabe von Zeichenfolgen behandelten, während dieses Flag auf „false” gesetzt blieb, was einen normalen Beendigungszustand signalisierte. Von 5.983 Tool-Aufruf-Ergebnissen ohne Fehlerflag beurteilte GPT-4.1, dass 3.536 Fehler in ihrem Inhalt aufwiesen. Noch besorgniserregender war, dass die Fehlermeldungen oft von geringer Qualität waren. Beispielsweise schlug ein Tool mit Web-Suchfunktionen mit der Zeichenfolge „error: job” fehl, während ein anderes Tool für die akademische Suche die Meldung „Please retry with 0 or fewer IDs” zurückgab.

Konventionen für die gemeinsame Nutzung von Ressourcen

Schließlich ermöglicht MCP neben Tools auch die gemeinsame Nutzung von Ressourcen und Ressourcenvorlagen durch Server und Clients. In der Umfrage gaben nur 112 (7,6 %) Server an, über Ressourcen zu verfügen, während 74 (5 %) Vorlagen bereitstellten. Ein möglicher Grund für die geringe Akzeptanz ist, dass die aktuelle MCP-Spezifikation nur begrenzte Hinweise dazu enthält, wann Ressourcen abgerufen werden oder wie sie in den Kontext integriert werden. Eine eindeutige Situation, in der ein Client eine Ressource abrufen könnte, ist die Antwort eines Tools, das einen resource_link (öffnet in neuem Tab) als Ergebnis zurückgibt – aber nur 4 Tools zeigten dieses Verhalten in unserer Umfrage (dies wäre wohl das ideale Verhalten für Tools, die sehr lange, dokumentähnliche Antworten zurückgeben, wie zuvor beschrieben).

Umgekehrt ergeben sich ganz andere Probleme, wenn Ressourcen vom Client an den Server weitergegeben werden müssen. Betrachten wir zum Beispiel ein Tool, das eine Analyse einer lokalen PDF-Datei bereitstellt. Im Fall eines lokalen MCP-Servers, der STDIO-Transport nutzt, kann ein lokaler Dateipfad als Argument für das Tool angegeben werden, aber es gibt keine ähnlichen Konventionen für die Übermittlung einer lokalen Datei an einen Remote-MCP-Server. Diese Probleme sind schon bei der Implementierung eines einzelnen Servers eine Herausforderung. Wenn mehrere Tools oder Server innerhalb desselben Systems interagieren müssen, erhöht sich das Risiko von Interoperabilitätsfehlern.

Insgesamt ist der durchschnittliche MCP-Server in jeder Hinsicht recht vernünftig – aber wie wir gesehen haben, können Ausreißer und abweichende Annahmen zu Problemen führen. „Wir gehen zwar davon aus, dass sich viele dieser Herausforderungen mit der Zeit verbessern werden, möchten aber dennoch einige kleine Empfehlungen aussprechen, die unserer Meinung nach immer aktuell sind. Wir haben sie unten nach Zielgruppen geordnet.“ Microsoft.

Microsoft zieht Fazit: Empfehlungen für das MCP-Ökosystem

Protokollentwickler: Microsoft erkennt die Vorteile einer schlanken MCP-Struktur, die in einem schnelllebigen KI-Umfeld nicht durch zu viele Vorschriften belastet wird. Gleichzeitig halten die Forscher kleinere Verbesserungen für sinnvoll: MCP sollte eine Spezifikation für vom Client bereitgestellte Ressourcen enthalten, damit Tools auf Remote-Servern gezielt mit lokalen Dateien oder Dokumenten arbeiten können. Auch formale Namespaces könnten helfen, Namenskollisionen bei Tools zu vermeiden und große Kataloge hierarchisch zu organisieren. Erste Erfahrungen, etwa mit GitHub MCP oder VS Code, zeigen, dass Tool-Gruppierungen eine flexible Aktivierung und Deaktivierung ermöglichen und hierarchische Tool-Aufrufe erleichtern könnten.

Serverentwickler: Obwohl das MCP-Interviewer-Tool viele Eigenschaften von Servern katalogisiert, können Entwickler ihre Tools besser charakterisieren. Sie sollten Laufzeiteigenschaften wie Token-Ausgabe, Latenz oder getestete Modelle dokumentieren, bekannte Inkompatibilitäten angeben und Tests, etwa mit Beispielaufgaben, transparent machen.

Client-Entwickler: Clients können durch Optimierungen die Performance einzelner MCP-Server verbessern, etwa durch Caching von Tool-Schemas, Prompt-Optimierungen oder RAG-ähnliche Auswahlansätze. Proaktive Maßnahmen gegen Namenskonflikte und Strategien zur Reduzierung langer Tool-Ausgaben können die Effizienz steigern, auch ohne Änderungen am Protokoll abzuwarten.

Marktentwickler: Marktplätze könnten Best Practices zentralisieren, Kompatibilitätsprobleme erkennen und modell- oder agentenbezogene Optimierungen bereitstellen. Ähnlich wie PyPI Python-Wheels liefert, könnten MCP-Marktplätze Tool-Schemas für spezifische Clients oder Modelle optimieren. Erste Ansätze sind bereits bei Registries wie Smithery zu sehen.

Fazit: Das MCP-Ökosystem bietet trotz anfänglicher Herausforderungen einen erheblichen Mehrwert für die Entwicklung von KI-Agenten. Horizontale Integration erweitert die Fähigkeiten, zeigt aber auch Toolspace-Interferenzen auf, die die End-to-End-Effektivität einschränken können. Die Empfehlungen zielen darauf ab, Protokoll-, Server-, Client- und Marktplatzentwickler zu unterstützen: formale Namespaces einführen, Protokollunterstützung für Client-Ressourcen verbessern und transparente Serverdokumentation fördern. Durch die Umsetzung dieser Maßnahmen kann die KI-Agenten-Community eine zuverlässigere, skalierbare und effizientere Infrastruktur schaffen, die sowohl Entwicklern als auch Endnutzern zugutekommt. Die Zukunft von MCP bleibt vielversprechend, mit Chancen für Experimente, Standardisierung und kollektiven Fortschritt.

Lesen Sie auch

---

Bild/Quelle: https://depositphotos.com/de/home.html

Folgen Sie uns auf X

Folgen Sie uns auf Bluesky