Derzeit wird das Model Context Protocol (MCP) von zahlreichen Beratungshäusern als umfassende Lösung für Integrations- und Prozessherausforderungen in Unternehmen positioniert. Doch MCP ist nicht für jeden Anwendungsfall gut geeignet und hat einige Einschränkungen – die optimale Lösung liegt wie so häufig in der Anwendung verschiedener Technologien. In diesem Blogartikel erklären wir, welche Schwächen unsere Kunden beim Einsatz von MCP festgestellt haben und wie bessere Lösungen aussehen können.
Inhaltsverzeichnis
Was MCP ist – und was nicht
Was ist überhaupt das Model Context Protocol? MCP ist ein Standard, mit dem KI‑Modelle wie Claude oder ChatGPT strukturierter auf Tools und Datenquellen zugreifen können – etwa auf Tickets, Dokumente oder interne APIs. Es definiert, wie Tools beschrieben werden und wie ein Agent diese Tools aufrufen kann, z.B. um eine Suche auszuführen oder Daten zu verändern (Aktionen).
Wichtig ist dabei die Abgrenzung: MCP ist ein Transport‑ und Integrationsprotokoll, aber kein Suchsystem, kein Enterprise‑Graph und kein Relevanz‑Ranking. Es beantwortet nicht die Frage, welche Daten für eine konkrete Aufgabe wirklich relevant, aktuell und vertrauenswürdig sind – genau hier entstehen in der Praxis die meisten Probleme bei KI‑Agenten.
Warum MCP gerade im Trend ist
MCP ist gerade im Trend, weil es ein akutes Schmerzproblem löst: die komplexe, teure Punkt‑zu‑Punkt‑Integration von KI‑Agenten mit vielen Systemen. Als offener Standard verspricht MCP eine Art „USB‑C für KI“, also ein einheitliches Stecksystem, mit dem verschiedene Modelle auf die gleiche Weise auf Tools und Daten zugreifen können – das senkt Integrationsaufwand und Time‑to‑Market deutlich. Dazu kommt ein stark wachsendes Ökosystem: 2025 entstanden in kurzer Zeit tausende MCP‑Server und ein signifikanter Teil der großen Unternehmen testet oder nutzt MCP bereits produktiv, was den Eindruck verstärkt, man dürfe „den Zug nicht verpassen“. Gleichzeitig positionieren Beratungen und Tool‑Hersteller MCP als Hebel, um Agenten schneller produktiv zu machen und Integrationskosten um 25 – 40% zu senken – diese Argumentation trägt wesentlich zum aktuellen Hype bei, überdeckt aber oft, dass MCP die Frage nach Relevanz, Kontext‑Qualität und Governance nicht von alleine löst.
Warum gute KI‑Agenten am Kontext scheitern
Warum ist Kontext so entscheidend? Große Sprachmodelle (LLMs) haben ein festes Kontextfenster – sie können immer nur eine begrenzte Menge an Tokens „im Kopf“ behalten und verarbeiten. Wenn zu viele Informationen hineingeschoben werden, verwässert die Aufmerksamkeit des Modells: Relevante Fakten konkurrieren mit Rauschen, ältere Dokumente mit neueren, widersprüchliche Quellen mit einander.
Dieses Phänomen wird oft als „Context red“ beschrieben: Je größer der Datenhaufen, desto schwieriger fällt es dem Modell, die wirklich passenden Informationen zuverlässig zu finden und über mehrere Schritte korrekt zu verknüpfen. In aktuellen Benchmarks zeigt sich, dass Systeme mit einem starken Enterprise‑Kontext‑Layer – also guter Suche, Graphen und Signalen – deutlich häufiger die korrekte Antwort liefern als generische Assistenten, selbst wenn dieselben Basismodelle genutzt werden.
Unternehmen brauchen also zwei Dinge:
- starke Modelle für das Reasoning,
- und einen Kontext‑Layer, der dafür sorgt, dass nur die richtigen Informationen im richtigen Moment im Kontext landen.
Um den richtigen Kontext zu finden, wird üblicherweise auf eine Retrieval-Ebene gesetzt, viele kennen das Prinzip aus dem Bereich Retrieval Augmented Generation.
4 Grenzen von MCP beim täglichen Einsatz in Unternehmen
Wo stößt MCP praktisch an Grenzen? Auf dem Papier wirkt MCP wie ein Plug‑and‑Play‑Ansatz: Tools registrieren, Schema definieren, fertig. In echten Enterprise‑Umgebungen zeigt sich aber schnell, dass das Protokoll mehrere strukturelle Schwächen hat – vor allem, wenn Unternehmen es als alleinige Integrationsschicht für KI nutzen.
Typische Grenzen:
- Kein eingebautes Relevanz‑Management
MCP definiert, wie ein Tool aufgerufen wird, aber nicht, welches Tool für welche Frage geeignet ist oder wie Ergebnisse priorisiert werden sollen. Unternehmen müssen diese Logik entweder selbst bauen – und zwar pro Tool‑Landschaft und Use Case oder zukaufen (weitere Informationen zu einem späteren Zeitpunkt). - Ungleichmäßiger Kontext aus verschiedenen Tools
MCP‑basierte Tools liefern sehr unterschiedliche Datenmengen und Formate: ein langer Slack‑Thread hier, ein paar knappe Tickets dort. In der Praxis kann eine laute Quelle (z.B. Chat‑Logs) den Kontext dominieren und wichtigere, strukturierte Systeme (z.B. CRM, DMS) verdrängen. Ergebnisse müssen priorisiert werden. - Übernutzung von Tools und Kontextfenster
Viele Agenten kompensieren schwache Suche, indem sie einfach mehr Tools aufrufen und mehr Daten laden – entweder sehr „tief“ mit vielen sequentiellen Calls oder sehr „breit“ mit parallelen Anfragen. Das treibt Kosten, verstopft das Kontextfenster und erhöht die Fehlerquote, ohne wirklich bessere Antworten zu liefern. - Sicherheits‑ und Governance‑Fragen
Forschungen zeigen, dass MCP zusätzliche Angriffsflächen schafft, z.B. über manipulierte Tool‑Beschreibungen, unzureichend geprüfte Dritt‑Tools oder fehlende zentrale Governance. Unternehmen brauchen hier zusätzliche Gateways, Prüfprozesse und Policies – MCP selbst liefert das nicht „out of the box“.
MCP ist damit ein nützliches Protokoll – aber als alleinige Antwort auf Enterprise‑Integrations‑ und Kontextprobleme ist es überfordert.
Lerne jetzt verschiedene Ansätze kennen. In unserem White Paper MCP vs. Indexbasierte Ansätze erklären wir die technischen Funktionsweisen im Detail. Du kannst dir das White Paper hier kostenlos herunterladen:
Warum ein dedizierter Kontext‑Layer unverzichtbar ist
Wie löst man das Kontextproblem besser? Die Erfahrungen aus Enterprise‑Search‑Projekten der letzten Jahre zeigen: Der Kern ist ein dedizierter Kontext‑Layer (oder Index), der das interne Wissen als „Unternehmensgedächtnis“ bereithält und verbindet – und zwar unabhängig davon, ob später MCP, direkte API‑Anbindung oder andere Integrationswege genutzt werden. Diese Kontext-Layer ist genau das, was wir mit amber seit 2020 entwickeln.
Ein solcher Kontext‑Layer umfasst typischerweise:
- Indexierte Daten aus vielen Systemen
Dokumente, Tickets, Chats, Code, CRM‑Objekte u.v.m. werden permission‑aware indexiert, also immer mit Berücksichtigung der vorhandenen Zugriffsrechte. - Enterprise‑Graph / Context‑Graph
Beziehungen zwischen Projekten, Kunden, Teams, Tickets und Dokumenten werden digital verbunden. So kann ein System bei ambigen Anfragen besser verstehen, welche Entität gemeint ist und welche Quellen dafür maßgeblich sind. - Enterprise‑Memory
Das System lernt aus Agent‑Runs: Welche Tools haben zu guten Antworten geführt, welche Parameter waren hilfreich, welche Pfade waren ineffizient oder falsch. Diese Erfahrungen fließen in künftige Tool‑Entscheidungen ein – unabhängig davon, ob die Tools über MCP oder andere Wege angebunden sind.
Dieser Kontext‑Layer wirkt wie ein Filter und Verstärker zugleich: Er reduziert Rauschen und reichert Antworten mit den tatsächlich relevanten Ressourcen an. MCP kann dann auf diesem Layer aufsetzen, statt ihn ersetzen zu sollen.
Was Kunden sagen, welche MCP mit einer Kontext-Layer verglichen haben
Bei amber setzen wir genau auf die zuvor beschriebene Kontext-Layer. Mittlerweile gibt es mehrere Unternehmen, welche beide Ansätze verglichen haben. Die Lehre, die gezogen wird: Der eigentliche Hebel liegt im Kontext‑Layer, nicht im reinen MCP‑Ansatz. In einer Blindstudie mit 280 realitätsnahen Enterprise‑Anfragen bevorzugten menschliche Prüfer die Antworten, welche auf einer Kontext-Layer basierten, 1,9‑mal häufiger im Vergleich zu den Antworten von ChatGPT Enterprise und 1,6‑mal häufiger im Vergleich zu Claude – trotz derselben zugrunde liegenden Modelle.
Aus Kundensicht zeigt sich das vor allem in der Praxis: Die Kontext-Layer findet deutlich zuverlässiger das richtige Dokument, versteht unternehmensspezifische Begriffe, löst mehrstufige, technische Fragen und liefert konkrete nächste Schritte, während MCP‑getriebene Ansätze häufig viele Tools aufrufen, viel Rauschen in den Kontext schieben und trotzdem an der eigentlichen „Single Source of Truth“ vorbeigehen. Unternehmen erleben, dass Ansätze, wie Claude und ChatGPT sie verfolgen, in MCP‑Setups Lücken in der Suche durch „mehr Tool‑Calls“ zu kompensieren versuchen – das erhöht Kosten, verkompliziert Governance und verschärft Kontext‑Überladung, während Lösungen wie amber mit tiefen Konnektoren, spezialisierten Indizes, Enterprise Graph und Enterprise‑Memory stabilere, nachvollziehbare Antworten liefert.
Du möchtest amber einmal ausprobieren? Dann melde dich jetzt für unsere Demo an und erlebe amber direkt live:
Praxisbeobachtungen: Wenn MCP in Unternehmen an Grenzen stößt
Wie sieht das in realen Projekten aus? Unternehmen, die „MCP‑First“ einführen, beobachten häufig ähnliche Muster – unabhängig von Branche oder Tool‑Stack.
Typische Situationen:
- Viele Tool‑Calls, wenig Mehrwert
Agenten rufen Dutzende Tools auf, durchsuchen Slack, Drive, Tickets und Wikis, aber liefern trotzdem unvollständige oder falsche Antworten, weil der Datensatz nicht sauber identifiziert wird. Es wirkt sehr umfassend und produktiv – produziert letztendlich jedoch nur LLM-Kosten. - Dominanz einzelner Systeme
Ein System mit langen, reichhaltigen Inhalten – häufig Chat oder E‑Mail – verdrängt strukturierte, authoritative Quellen wie CRM, HR‑Systeme oder Fach‑Wikis im Kontext. Das führt zu Antworten, die sich eher an Gesprächsverläufen orientieren als an Richtlinien oder Policies, da Kontext nicht an Relevanz geknüpft ist. - Schwierigkeiten beim Kurswechsel
Wenn der Agent einmal „entschieden“ hat, dass z.B. Slack eine Frage beantworten kann, fällt es ihm schwer, auf andere Tools umzuschwenken. Die Folge: wichtige Dokumente oder Systeme bleiben unberücksichtigt, obwohl sie die bessere Quelle wären. - Kosten und Limits
Jeder Tool‑Call und jedes zusätzliche Dokument verbraucht Tokens und manchmal auch API‑Kontingente. Unternehmen berichten, dass breite MCP‑Setups schnell teuer werden und Rate‑Limits (Abbruch der Anfrage) einzelner Systeme reißen, ohne dass die Antwortqualität entsprechend steigt.
All das sind keine grundsätzlichen Argumente gegen MCP – sie zeigen aber klar, dass MCP ohne starken Kontext‑Layer nur ein weiterer Integrationsmechanismus ist, nicht die Lösung des Kontextproblems.
Zielbild: So sieht eine sinnvolle Architektur mit MCP aus
Wie lässt sich MCP sinnvoll in eine Enterprise‑Architektur integrieren? Ein zielführendes Bild besteht aus drei Ebenen:
1. Kontext‑Fundament: Enterprise Search
- Indexierung aller relevanten Systeme (Docs, Tickets, CRM, Code, Chats) inkl. Berechtigungen.
- Aufbau eines Enterprise‑ oder Context‑Graphen, der Entitäten über Systeme hinweg zusammenführt.
- Signal‑basierte Relevanz (Nutzung, Aktualität, Ownership, Links).
2. Agenten‑ und KI‑Schicht
- LLM‑basierte Assistenten und Agenten nutzen diesen Kontext‑Layer über Such‑ und Retrieval‑APIs.
- Enterprise‑Memory optimiert langfristig die Tool‑Nutzung und Pfade für typische Aufgaben.
3. Integrations‑Schicht: MCP & Co.
- MCP dient als standardisierte Schnittstelle, um diesen kuratierten Kontext in verschiedene Clients und Plattformen zu bringen – etwa in IDEs, Chat‑Oberflächen oder andere Agent‑Frameworks.
- Externe Tools können über MCP auf denselben Enterprise‑Kontext zugreifen, den Mitarbeitende bereits in der nativen Suche nutzen.
In dieser Architektur ist MCP ein Transport‑ und Integrationslayer, während Relevanz, Sicherheit, Compliance und Kontext‑Qualität im Enterprise‑Search‑ und Graph‑Layer verankert sind. So können Workflowbuildertools wie n8n, make, Zapier & Co ihre Aktionen und Entscheidungen stets auf dem aktuellsten Wissen aufbauen und mit Hilfe von MCP die richtigen Aktionen auslösen, anstatt falsche Entscheidungen auf den falschen Informationen zu liefern.
Entscheidungsleitfaden: Wann MCP sinnvoll ist – und wann nicht
Wann lohnt es sich, MCP gezielt einzusetzen – und wann sollten Unternehmen zuerst in ihren Kontext‑Layer investieren?
MCP ist sinnvoll, wenn:
- Man nur mit kleinen Datenmengen arbeitet.
- der Hauptfokus auf „Action‑Tools“ liegt, etwa dem Anlegen von Tickets oder dem Auslösen von Workflows.
- bereits ein starkes Enterprise‑Search‑ oder Kontext‑System existiert, das über MCP angebunden wird.
Unternehmen sollten zuerst einen dedizierten Kontext‑Layer aufbauen, wenn:
- viele heterogene Systeme im Spiel sind (Laufwerke, M365, DMS, CRM, HR, Code, Tickets, Chats).
- Korrektheit und Nachvollziehbarkeit der Antworten geschäftskritisch sind.
- komplexe, mehrstufige Aufgaben im Fokus stehen, etwa Analysen, Entscheidungen, technische Troubleshooting‑Flows.
- Sicherheits‑ und Compliance‑Anforderungen (DSGVO, rollenbasierte Zugriffe, Hosting‑Standort, ISO‑Zertifizierungen) eine große Rolle spielen.
Die wichtigste Frage lautet: „Habe ich mein Kontext‑Problem gelöst – oder versuche ich, es mit mehr Protokoll‑Logik zu kaschieren?“ Wenn der Kontext‑Layer fehlt, wird MCP die Symptome nur verlagern, nicht die Ursache beseitigen.
Fazit und konkrete nächste Schritte
MCP ist ein sinnvoller Baustein im modernen KI‑Tech‑Stack, aber kein Ersatz für einen robusten Enterprise‑Kontext. Unternehmen, die nur auf MCP setzen, optimieren am falschen Ende: Sie standardisieren den Zugang zu Daten und Tools, ohne sicherzustellen, dass der zugelieferte Kontext wirklich relevant und sicher ist.
Wenn du MCP oder KI‑Agenten im Unternehmen einführen willst, kannst du so starten:
- Erstelle eine Bestandsaufnahme deiner wichtigsten Systeme und Datenquellen.
- Identifiziere 3–5 kritische Use Cases, bei denen Korrektheit und Vollständigkeit entscheidend sind.
- Baue oder evaluiere eine Enterprise‑Search‑ und Kontext‑Plattform wie amber, die Berechtigungen, Graph und Signale bereits sauber abbildet.
- Nutze MCP gezielt, um diesen Kontext in deine bevorzugten KI‑Tools und Agenten zu bringen – nicht umgekehrt.
Wenn du sehen möchtest, wie eine solche Architektur in der Praxis aussieht und wie du deinen bestehenden Stack (z.B. Microsoft 365, Confluence, Jira, Salesforce, Slack) in einer Enterprise‑Search‑Plattform bündeln kannst, bevor du MCP einsetzt, melde dich gerne bei uns. Wir zeigen dir in einer Demo, wie du aus deiner bestehenden Datenlandschaft einen echten Kontext‑Layer machst – und MCP dort einsetzt, wo es wirklich Mehrwert bringt: