Wer sich mit KI-Agenten beschäftigt, stolpert aktuell überall über zwei Abkürzungen: RAG und MCP. Beide werden oft in einem Atemzug genannt — und genauso oft verwechselt. Dabei lösen sie fundamental unterschiedliche Probleme: RAG gibt einem Agenten Zugang zu Wissen. MCP gibt ihm Zugang zu Werkzeugen und Systemen. Wer beides in einen Topf wirft, baut am Ende Agenten, die entweder viel wissen aber nichts tun können — oder blind handeln, ohne den nötigen Kontext zu haben.
In diesem Artikel erklären wir den Unterschied zwischen RAG und MCP, zeigen an einem konkreten Praxisbeispiel, wie beide zusammenspielen, und geben Ihnen eine klare Entscheidungshilfe für Ihre eigene Agenten-Architektur.
Warum Large Language Models allein nicht reichen
Large Language Models wie GPT-4, Claude oder Gemini sind beeindruckend leistungsfähig. Aber sie haben zwei grundlegende Schwächen, die ihren Einsatz im Unternehmenskontext limitieren:
Schwäche 1: Kein Unternehmenswissen. Ein LLM weiß nur das, womit es trainiert wurde. Es kennt keine Kundendaten, keine internen Prozesse, keine Produktdokumentation und keine Geschäftslogik. Fragen Sie ein LLM nach dem Status einer Kundenbestellung, bekommen Sie bestenfalls eine allgemeine Antwort — aber keine konkrete.
Schwäche 2: Keine Handlungsfähigkeit. Ein LLM kann Text generieren, aber es kann kein Ticket erstellen, keine E-Mail versenden, keinen Termin buchen und kein CRM-System aktualisieren. Es ist — isoliert betrachtet — ein reines Textwerkzeug.
RAG adressiert die erste Lücke: Zugang zu Wissen. MCP adressiert die zweite: Zugang zu Werkzeugen und Systemen. Erst wenn beides zusammenkommt, entsteht ein Agent, der in der Praxis echten Mehrwert liefert.
Was ist RAG? — Die Wissensschicht für KI-Agenten
Retrieval Augmented Generation (RAG) ist ein Architekturansatz, der LLMs mit unternehmensspezifischem Wissen anreichert. Statt das Modell selbst nachzutrainieren, werden relevante Dokumente und Informationen zur Laufzeit abgerufen und dem LLM als Kontext mitgegeben.
So funktioniert RAG in fünf Schritten
- Frage (Ask): Der Nutzer stellt eine Frage — zum Beispiel: „Warum lädt mein Dashboard seit dem letzten Update nicht mehr?“
- Suche (Retrieval): Das System durchsucht eine Wissensdatenbank (z. B. via Vektor-Suche) und findet relevante Passagen in Dokumenten, Handbüchern oder Release Notes.
- Rückgabe (Return): Die gefundenen Passagen werden zurückgegeben.
- Zusammenführung (Augment): Die ursprüngliche Frage wird zusammen mit den gefundenen Dokumenten zu einem erweiterten Prompt zusammengepackt.
- Antwort (Generate): Das LLM generiert eine Antwort, die auf der Frage und den abgerufenen Dokumenten basiert.
Ein entscheidender Vorteil von RAG: Gute Implementierungen liefern die Quellen mit. Der Nutzer kann nachprüfen, woher eine Antwort stammt — und idealerweise direkt an die relevante Stelle im Originaldokument springen.
Welche Daten nutzt RAG?
RAG arbeitet typischerweise mit statischen oder selten veränderten Daten: Handbücher, Produktdokumentation, Release Notes, FAQ-Artikel, Richtlinien, Wissensdatenbanken. Diese Inhalte werden vorab indexiert und als Vektoren in einer Datenbank gespeichert.
In unserer Beratungspraxis setzen wir RAG unter anderem für interne Wissensplattformen, Kunden-Support-Systeme und die Erschließung großer Dokumentenbestände ein — beispielsweise bei einem Q&A Chatbot für ein Telekommunikationsunternehmen.
Was ist MCP? — Die Aktionsschicht für KI-Agenten
Das Model Context Protocol (MCP) ist ein offener Standard, der KI-Agenten mit externen Systemen und Werkzeugen verbindet. Während RAG dem Agenten Wissen gibt, gibt MCP ihm die Fähigkeit zu handeln: Daten abfragen, Einträge erstellen, Prozesse auslösen.
MCP wurde Ende 2024 von Anthropic als Open-Source-Projekt veröffentlicht und hat sich innerhalb eines Jahres zum De-facto-Standard für die Tool-Anbindung von LLMs entwickelt. OpenAI, Google, Microsoft und zahlreiche weitere Unternehmen unterstützen das Protokoll mittlerweile. Seit Dezember 2025 wird MCP von der Agentic AI Foundation unter dem Dach der Linux Foundation verwaltet — ein klares Signal für die langfristige Relevanz.
So funktioniert MCP in fünf Schritten
- Verbindung (Connect): Das LLM verbindet sich mit einem MCP-Server und sieht die verfügbaren Tools — zum Beispiel ein Ticketsystem, ein CRM oder einen Kalender.
- Verstehen (Discover): Das LLM liest die Beschreibungen der Tools, versteht deren Zweck, die erwarteten Eingaben und die möglichen Ausgaben.
- Planen (Plan): Das LLM entscheidet, welche Tools es in welcher Reihenfolge aufrufen muss. Zum Beispiel: Erst ein Ticket erstellen, dann eine Priorität setzen, dann einen Ansprechpartner zuweisen.
- Ausführen (Execute): Das LLM sendet die entsprechenden Aufrufe an den MCP-Server. Die Aktionen werden im Zielsystem durchgeführt.
- Ergebnis (Return): Die Ergebnisse fließen zurück zum LLM — etwa eine Bestätigung mit Ticketnummer, ein gebuchter Termin oder ein aktualisierter Datensatz.
Welche Daten nutzt MCP?
MCP arbeitet mit Live-Systemen und Echtzeitdaten: CRM, Ticketsysteme, Kalender, E-Mail, Datenbanken, APIs. Die Daten ändern sich ständig — deshalb werden sie nicht vorab indexiert, sondern zur Laufzeit abgefragt oder manipuliert.
Die Architektur folgt einem Client-Server-Modell auf Basis von JSON-RPC 2.0. MCP-Server stellen drei Kernbausteine bereit: Tools (Funktionen, die das LLM aufrufen kann), Resources (Datenquellen zum Lesen) und Prompts (vorgefertigte Workflows).
RAG vs. MCP im direkten Vergleich
| Kriterium | RAG | MCP |
|---|---|---|
| Zweck | Wissen bereitstellen | Handlungen ausführen |
| Was es dem LLM gibt | Kontext und Informationen | Fähigkeiten und Werkzeuge |
| Datentyp | Statische Dokumente (Handbücher, FAQs, Knowledge Base) | Live-Systeme (CRM, Ticketsystem, Kalender, APIs) |
| Richtung | Informationen fließen zum LLM | Aktionen fließen vom LLM zu externen Systemen |
| Kernprozess | Suchen → Finden → Antworten | Entdecken → Planen → Handeln |
| Analogie | Ein Mitarbeiter, der Zugang zur Firmenbibliothek hat | Ein Mitarbeiter, der Zugang zu allen Firmensystemen hat |
| Typisches Ergebnis | Eine fundierte Antwort mit Quellenangabe | Eine ausgeführte Aktion mit Bestätigung |
| Veränderung im Zielsystem | Keine (nur Lesen) | Ja (Erstellen, Ändern, Auslösen) |
Einfach gesagt: Wenn Ihr Agent etwas wissen muss — viel, statisch, kontextreich — dann ist das RAG. Wenn Ihr Agent etwas tun soll — eine Aktion auslösen, eine kurze Abfrage machen, ein System bedienen — dann ist das MCP.
Unser CTO Laurenz erklärt Ihnen in 6 Minuten die wichtigsten Unterschiede zwischen RAG und MCP.
Praxisbeispiel: Support-Agent mit RAG und MCP
Ein konkretes Beispiel macht den Unterschied greifbar. Stellen Sie sich einen KI-gestützten Support-Agenten vor:
Schritt 1 — RAG im Einsatz:
Ein Kunde schreibt: „Meine Dashboards laden seit dem letzten Update nicht mehr.“ Der Agent durchsucht per RAG die interne Wissensdatenbank, findet die passende Stelle in den Release Notes und antwortet mit einer Schritt-für-Schritt-Anleitung. Der Agent hat Wissen abgerufen.
Schritt 2 — MCP im Einsatz:
Der Kunde antwortet: „Das hat leider nicht geholfen. Ich brauche einen Ansprechpartner.“ Jetzt wechselt der Agent zur Aktionsschicht: Per MCP erstellt er ein Ticket im Support-System, fasst das bisherige Gespräch als Beschreibung zusammen, setzt die Priorität und weist einen Mitarbeiter zu. Der Kunde erhält eine Bestätigung mit Ticketnummer und Kontaktdaten. Der Agent hat gehandelt.
Ohne RAG hätte der Agent keine Antwort auf die technische Frage gehabt. Ohne MCP hätte er kein Ticket erstellen können. Erst die Kombination beider Ansätze ergibt einen Agenten, der den Support-Prozess tatsächlich End-to-End abbildet.
In unserer Beratungspraxis sehen wir genau dieses Muster bei vielen Kunden: Der erste Schritt ist oft ein RAG-basierter Chatbot für die Wissenserschließung. Der zweite Schritt — und hier entsteht der eigentliche Produktivitätssprung — ist die Anbindung an operative Systeme über Tool-Schnittstellen.
Warum die besten KI-Systeme beides nutzen
RAG und MCP sind keine Konkurrenten. Sie funktionieren auf komplett unterschiedlichen Ebenen:
- RAG ist die Wissensschicht — sie gibt dem Agenten Zugang zu Informationen, die das LLM allein nicht hat.
- MCP ist die Aktionsschicht — sie gibt dem Agenten die Fähigkeit, in der realen Welt zu handeln.
Ein vollständiger KI-Agent braucht beides. Die Wissensschicht liefert den Kontext für gute Entscheidungen. Die Aktionsschicht setzt diese Entscheidungen in konkrete Handlungen um. Erst wenn beides zusammenspielt, entsteht Automatisierung auf einem Level, das über einfache Chatbots hinausgeht.
So sehen wir das in der Praxis
In unseren Projekten folgen wir einem klaren Stufenmodell:
- Stufe 1 — Wissen erschließen (RAG): Unternehmensdokumente werden indexiert, ein Chatbot beantwortet Fragen auf Basis interner Daten. Das liefert schnellen Mehrwert und schafft Vertrauen in die Technologie.
- Stufe 2 — Systeme anbinden (MCP / Tools): Der Agent wird an operative Systeme angebunden — Ticketing, CRM, E-Mail, Kalender. Er kann jetzt nicht nur antworten, sondern handeln.
- Stufe 3 — Orchestrierung: Mehrere Agenten arbeiten zusammen. Ein Routing-Agent entscheidet, ob RAG oder ein Tool-Aufruf nötig ist. Komplexe Workflows werden End-to-End automatisiert.
Dieses Stufenmodell hat sich bewährt, weil es Komplexität schrittweise aufbaut und nach jeder Stufe messbaren Mehrwert liefert — statt alles auf einmal zu versuchen und in Pilotitis zu enden.
Generative KI mit Datasolut
Wir bauen einen KI-Agenten, der auf Ihre Bedürfnisse zugeschnitten ist.
Häufige Fehler bei der Agenten-Architektur
Aus unserer Beratungserfahrung kennen wir typische Stolpersteine, die Unternehmen beim Aufbau von KI-Agenten begegnen:
Alles mit RAG lösen wollen. RAG ist stark bei der Wissenserschließung. Aber wenn ein Agent Aktionen ausführen soll — Daten schreiben, Systeme bedienen, Prozesse auslösen — reicht RAG nicht. Hier brauchen Sie eine Tool-Schicht.
MCP ohne Kontext einsetzen. Ein Agent, der Tickets erstellen kann, aber nicht weiß, was im Ticket stehen soll, ist nutzlos. Die Aktionsschicht braucht immer eine Wissensschicht als Grundlage.
Statische und dynamische Daten verwechseln. Produktdokumentation gehört in eine RAG-Pipeline. Der aktuelle Status einer Kundenbestellung gehört in einen Live-API-Aufruf über MCP. Wer beides vermischt, bekommt entweder veraltete Antworten oder unnötig komplexe Architekturen.
Keine Quellenangaben implementieren. Gute RAG-Systeme liefern Quellen mit. Nutzer müssen nachprüfen können, woher eine Antwort kommt. Ohne Transparenz schwindet das Vertrauen schnell — besonders bei kritischen Geschäftsprozessen.
Zu viele Tools gleichzeitig anbinden. MCP macht es technisch einfach, dutzende Systeme anzubinden. Aber jedes Tool erhöht die Komplexität für das LLM. In der Praxis hat sich bewährt, mit wenigen, klar definierten Tools zu starten und schrittweise zu erweitern.
Fazit
RAG und MCP lösen zwei fundamental verschiedene Probleme für KI-Agenten. RAG gibt dem Agenten Wissen — Zugang zu Dokumenten, Handbüchern und Knowledge Bases. MCP gibt ihm Fähigkeiten — Zugang zu Werkzeugen, Systemen und Aktionen. Wer beides verwechselt oder nur eines davon einsetzt, verschenkt Potenzial.
Die klare Empfehlung: Starten Sie mit RAG, um Unternehmenswissen für Ihre Agenten nutzbar zu machen. Erweitern Sie dann mit MCP (oder vergleichbaren Tool-Schnittstellen), um von der Wissensebene zur Handlungsebene zu kommen. Und orchestrieren Sie beides in einer durchdachten Agenten-Architektur, die schrittweise Mehrwert liefert.
KI-Agenten richtig aufsetzen — mit Datasolut
Sie möchten KI-Agenten einsetzen, die nicht nur antworten, sondern handeln? Wir begleiten Sie vom ersten RAG-Prototyp bis zur produktiven Agenten-Plattform — mit einer Architektur, die Wissen und Aktionen sauber verbindet.
Jetzt kostenloses Erstgespräch vereinbaren und erfahren, wie Sie RAG und MCP in Ihrem Unternehmen einsetzen.
Lassen Sie uns sprechen und Ihr Potenzial entdecken.
Ob und wie künstliche Intelligenz Ihnen weiterhelfen kann, können Sie in einem ersten, unverbindlichen Gespräch mit uns herausfinden.
In diesem Gespräch erfahren Sie:
- Wie Ihr Use-Case technisch am besten umgesetzt werden kann
- Wie wir maximal sicher mit Ihren Kundendaten umgehen
- Wie lange wir für die Umsetzung benötigen und wie ein konkreter Projektplan aussehen könnte