MCP vs. RAG: Was braucht dein Agent?
Die kurze Antwort: RAG bringt Wissen in den Kontext deines Agenten, MCP lässt deinen Agenten in anderer Software handeln. Das eine füttert das Modell mit Informationen, das andere gibt ihm Hände. Die Frage MCP vs. RAG ist selten ein Entweder-oder; die meisten funktionierenden Agenten-Setups nutzen beides, und die eigentliche Kunst ist zu wissen, welcher Job wohin gehört.
So hältst du beides auseinander, plus der Fehler, der am meisten Engineering-Zeit verbrennt.
Was RAG macht: Retrieval Augmented Generation
RAG, Retrieval Augmented Generation, beantwortet genau eine Frage: Wie bekommt man das richtige Wissen vor ein Modell, genau in dem Moment, in dem es gebraucht wird? Du nimmst einen Korpus (Doku, Verträge, alte Tickets, ein Wiki), zerlegst ihn in Stücke, machst Embeddings daraus und speicherst sie. Bei einer Frage wird die Frage embedded, die nächstliegenden Stücke werden geholt und in den Prompt gelegt. Das Modell antwortet mit diesem Material vor Augen.
Beachte, was RAG nicht ist: Es ändert nie etwas. Es ist ein reines Lese-Muster, das einen großen Textberg nach Bedeutung durchsuchbar macht, damit das Modell seine Antworten auf deine Inhalte stützt statt auf Trainingsdaten-Raten.
Damit ist es das richtige Werkzeug, wenn das Wissen groß, weitgehend stabil und unstrukturiert ist. Niemand sollte ein 900-Seiten-Handbuch in jeden Prompt kleben.
Was MCP macht: dem Agenten Werkzeuge geben
MCP, das Model Context Protocol, ist ein offener Standard, der KI-Agenten mit Tools verbindet. Ein MCP-Server stellt bereit, was eine Software kann (suchen, holen, anlegen, ändern), als typisierte Tools. Der Agent liest die Tool-Liste, wählt eines, ruft es auf und bekommt strukturierte Daten zurück. Das ganze Bild steht in [Was ist ein MCP-Server?](/de/blog/what-is-an-mcp-server).
Zwei Eigenschaften trennen das von Retrieval. MCP-Aufrufe sind live: Die Antwort kommt zum Aufrufzeitpunkt aus dem führenden System, nicht aus einer Kopie, die du letzte Nacht indexiert hast. Und MCP geht in beide Richtungen: Der Agent kann eine Rechnung holen, aber auch eine anlegen. Retrieval kann kein Ticket eröffnen. Ein Tool-Aufruf schon.
MCP ist auch keine umbenannte API: Das Protokoll lässt jeden Agenten jeden Server ohne eigenen Klebercode nutzen, aufgedröselt in [MCP vs. API](/de/blog/mcp-vs-api).
MCP vs. RAG: der eigentliche Unterschied
| Frage | RAG | MCP |
|---|---|---|
| Kernjob | Wissen in den Kontext bringen | Den Agenten in Software handeln lassen |
| Frische | So frisch wie dein letzter Index-Lauf | Live zum Aufrufzeitpunkt |
| Richtung | Nur lesen | Lesen und schreiben |
| Beste Daten | Große, stabile, unstrukturierte Texte | Strukturierte, veränderliche, bearbeitbare Datensätze |
| Typischer Fehler | Veraltete oder unpassende Chunks | Falsches Tool gewählt, Auth-Reibung |
Klar gesagt: RAG beantwortet "Was darf das Modell wissen?", MCP beantwortet "Was darf der Agent tun?". Die Frage als Duell zu framen und einen Sieger zu küren, geht am Punkt vorbei.
Sie kombinieren sich, und genau das ist der Punkt
Die saubersten Architekturen nutzen beides, geschichtet.
Eine RAG-Pipeline ist ein hervorragendes MCP-Tool. Pack deine Vektorsuche in ein search_docs-Tool auf einem MCP-Server, und jeder Agent, den du betreibst, fragt den Korpus über dasselbe Protokoll ab wie alles andere.
Es geht auch andersherum. Das Such-Tool eines MCP-Servers ist selbst eine Form von Retrieval: Wenn dein Agent die Suche eines CRM aufruft, dann retrievt er, nur eben aus einer Live-Datenbank statt aus einem Vektor-Index. Die Grenze ist unscharf, und das ist okay: Entscheide pro Datenquelle, nicht pro Ideologie.
Der Fehler: RAG über Daten, die ein Tool-Aufruf frisch holen könnte
Ein Team will, dass sein Agent Fragen zu Kunden, Rechnungen oder Tickets beantwortet, und baut eine Pipeline: nächtlicher CRM-Export, zerlegen, embedden, bei Fragen abrufen. Jetzt besitzen sie eine Index-Pipeline, und jede Antwort ist bis zu einem Tag alt, für Daten, die längst in Software mit einer völlig brauchbaren Abfrage-Schnittstelle liegen.
Rechne es an einer einzigen Frage durch, etwa "Welchen Plan hat dieser Kunde?". Der RAG-Weg holt, sagen wir, fünf 400-Token-Chunks einer exportierten Abrechnungstabelle: 2.000 Tokens im Prompt, und die Antwort ist nur so aktuell wie der letzte Export. Der Tool-Weg macht einen MCP-Aufruf ans Abrechnungssystem und bekommt einen Datensatz zurück, ein paar hundert Tokens, korrekt zum jetzigen Zeitpunkt. Frischere Antwort, weniger Tokens, eine Pipeline weniger zu hüten.
Die Faustregel: Wenn die Daten in Software liegen, die Abfragen beantworten kann, ruf die Software auf. Heb dir RAG für Text auf, der kein abfragbares Zuhause hat: Dokumentation, Richtlinien, historische Inhalte.
Was braucht dein Agent nun?
- Fragen zu Handbüchern, Doku oder einer Wissensdatenbank: RAG. Der Korpus ist groß, weitgehend statisch, unstrukturiert.
- Live-Datensätze lesen oder ändern (CRM-Einträge, Rechnungen, Kalender-Termine, Tickets): MCP. Frische und Schreibzugriff entscheiden.
- Beide Arten von Arbeit: beides, meist mit dem Retrieval-Schritt als einem MCP-Tool unter vielen.
- Sich merken, was der Agent selbst letzte Session getan hat: keins von beiden. Das ist Memory, ein drittes Ding, das ständig in diesen Vergleich gerührt wird. Dazu gibt es [Agent Memory vs. RAG](/de/blog/agent-memory-vs-rag), weil die Verwechslung so häufig ist.
Ein guter erster Schritt: Prüf, ob die Software, die dein Agent braucht, schon MCP spricht. Das [kuratierte Verzeichnis agent-fähiger Tools](/de/discover) beantwortet das schnell. Existiert ein Live-Server, musst du diese Daten wahrscheinlich gar nicht indexieren.
Häufige Fragen
Ersetzt MCP RAG?
Nein. MCP verbindet Agenten mit Software, damit sie handeln können; RAG bringt Text in den Kontext, damit das Modell daraus antworten kann. Sie lösen verschiedene Probleme und laufen oft nebeneinander im selben Agenten, mit dem Retrieval-Schritt als MCP-Tool.
Wann ist RAG die falsche Wahl?
Wenn die Daten strukturiert sind, sich oft ändern und in einem System liegen, das Abfragen beantworten kann. Dein CRM nächtlich zu indexieren liefert veraltete Kopien von Daten, die ein Live-Tool-Aufruf frisch zurückgibt. Nutze RAG für unstrukturierten Text ohne abfragbare Quelle.
Kann eine RAG-Pipeline über MCP bereitgestellt werden?
Ja, das ist ein sauberes Muster: Stell deine Vektorsuche als Such-Tool auf einem MCP-Server bereit. Jeder Agent erreicht den Korpus über dasselbe Protokoll wie seine anderen Tools, und du kannst die Retrieval-Interna austauschen, ohne den Agenten anzufassen.
Ist Agent Memory nur RAG in Verkleidung?
Nein. Memory speichert, was dein Agent gelernt und entschieden hat (IDs, Vorlieben, frühere Entscheidungen), über Sessions hinweg. RAG holt aus einem Dokumenten-Korpus, den du vorab vorbereitet hast. Die Maschinerie kann ähnlich aussehen, aber Daten und Job sind verschieden.