MCP, RAG und das LLM: Was jede Schicht in Ihrer App wirklich leistet

Wer schon vor dem KI-Boom Software gebaut hat, hat sich wahrscheinlich gefragt, warum plötzlich alles eine Abkürzung braucht. AI, LLM, RAG, MCP, Agenten, Vektordatenbanken. Viele Entwickler sehen sich diesen Stapel an und denken, dass sie ihre Anwendungen auch ohne all das gut ausgeliefert haben. Ein fairer Weg durch die Schlagworte ist die Frage, was jedes Teil eigentlich zu dem hinzufügt, was Sie schon haben.

Beginnen wir mit etwas Bekanntem

Angenommen, ein Kunde möchte seine letzten 5 abgerechneten Transaktionen sehen. Das ist kein neuartiges Problem, und Ihre Anwendung erledigt das bereits.

User
 ↓
Application
 ↓
SQL
 ↓
Database
 ↓
Transactions

Die Abfrage dahinter kann so schlicht sein:

SELECT *
FROM transactions
WHERE status = 'billed'
ORDER BY transaction_date DESC
LIMIT 5;

Das war's. Keine KI, kein MCP, keine Vektordatenbank, kein Agent, und es funktioniert einwandfrei.

Varianten ändern wenig

Nehmen wir an, der Kunde möchte stattdessen 37 Transaktionen. Die App nimmt einfach einen Parameter entgegen.

limit = 37

Oder er fragt nach abgerechneten Transaktionen aus dem August über ₹10.000. Das Backend macht daraus die passende Abfrage, wieder ganz ohne MCP.

An dieser Stelle wird MCP meist verwirrend. Man ist versucht anzunehmen, dass MCP irgendwie selbst herausfindet, wie Ihre Datenbank abzufragen ist. Das tut es nicht. MCP kennt Ihr Schema nicht, schreibt nicht Ihre Geschäftslogik, holt Ihre Daten nicht von allein und macht die Anwendung, die Sie bereits gebaut haben, nicht überflüssig.

Was ist MCP also?

Die kürzeste Beschreibung, die standhält, lautet: MCP ist ein gemeinsames Protokoll, mit dem KI-Anwendungen Tools und Datenquellen finden und auf eine einheitliche Weise aufrufen können.

Stellen Sie sich drei voneinander unabhängige Systeme vor. Transaktionen liegen in einer Datenbank.

Transactions → Database

Support-Tickets stecken in einem CRM oder in Jira, und die Unternehmensrichtlinien in einem RAG-Setup, hinter dem eine Vektordatenbank steht.

Support Tickets → CRM/JiraCompany Policies → RAG / Vector Database

Ein KI-Assistent könnte alle drei brauchen. MCP kann jedes davon als Fähigkeit veröffentlichen, die der Assistent finden und aufrufen kann:

get_transactions()
get_support_tickets()
search_knowledge_base()

Das Modell kann dann entscheiden, dass es Informationen aus allen dreien braucht. Der Haken: Die eigentliche Arbeit macht MCP nicht. Etwas darunter muss weiterhin die Transaktionen holen, die Tickets abfragen, die Wissensdatenbank durchsuchen, Berechtigungen durchsetzen und die Ergebnisse filtern. Deshalb kann sich MCP wie eine zusätzliche Schicht anfühlen, und manchmal ist es genau das.

Ist es dann sinnlos?

Nein, es löst nur ein anderes Problem als das, an das man zuerst denkt.

Wenn Sie eine einzelne Anwendung bauen und das Backend selbst besitzen, ist es völlig vernünftig, Ihre Funktionen direkt als Tools aufzurufen. Anders wird es, sobald es mehrere Abnehmer gibt.

AI Agent 1
AI Agent 2
AI Agent 3
Customer Chatbot
Internal Copilot

Stellen Sie sich nun vor, alle brauchen dieselben Systeme:

CRM
Jira
Databases
Internal APIs
Knowledge Base
Cloud services

Dann haben Sie ein Integrationsproblem. Ohne gemeinsames Protokoll würde jede KI-Anwendung ihren eigenen Weg erfinden, mit jedem System zu sprechen. MCP bietet stattdessen eine gemeinsame Schnittstelle, und genau da beginnt sich ein Standard auszuzahlen.

Wo RAG hingehört

RAG ist leichter einzuordnen, denn es beantwortet eine Frage der Suche. Jemand fragt, wie die Rückerstattungsrichtlinie lautet, und RAG durchsucht einen großen Berg Dokumente und liefert die relevanten Passagen.

MCP ersetzt das nicht. Sie könnten Ihr RAG-System sogar über MCP veröffentlichen. Die drei Rollen lassen sich sauber trennen:

• RAG findet die relevanten Informationen.
• MCP gibt der KI einen standardisierten Weg, diese Fähigkeit zu erreichen.
• Das LLM versteht die Frage, entscheidet, was es braucht, und zieht Schlüsse aus dem, was zurückkommt.

Das sind unterschiedliche Aufgaben.

Die eigentliche Lehre

Die Erkenntnis ist weder, dass MCP großartig ist, noch, dass MCP Zeitverschwendung ist. Sondern diese: Ein Trend ist ein schlechter Grund, eine Schicht hinzuzufügen, ein echtes Problem, das diese Schicht löst, ein guter.

Sie haben jahrelang APIs, Datenbanken, Authentifizierung, Suche, Caching, Integrationen und Geschäftslogik gebaut. KI löscht nichts davon aus. Sie gibt Ihnen nur eine weitere Möglichkeit, damit zu interagieren. Manchmal macht eine neue Schicht die Architektur besser, und manchmal ist sie nur eine weitere Schicht. Zu wissen, welcher Fall bei Ihnen vorliegt, ist das Nützlichste, was man aus all diesen Abkürzungen mitnehmen kann.