Die API: ein zustandsloser Aufruf
Der Zugang zu einem Modell ist technisch unspektakulär: ein HTTP-POST mit einem JSON-Körper, in dem der Gesprächsverlauf steht, und einer JSON-Antwort zurück. Es gibt drei Rollen – system (Rahmen und Regeln), user (Eingaben) und assistant (bisherige Antworten des Modells).
Entscheidend ist die Eigenschaft dahinter: Der Aufruf ist zustandslos. Das Modell erinnert sich an nichts. Was wie ein Gespräch mit Gedächtnis wirkt, entsteht dadurch, dass Ihre Software bei jedem Aufruf den kompletten bisherigen Verlauf erneut mitschickt. Daraus folgt unmittelbar, warum lange Unterhaltungen teurer werden und warum ein Kontextfenster irgendwann voll ist.
Function Calling: das Modell ruft nichts auf
Der am häufigsten missverstandene Punkt der ganzen Technik: Wenn ein Modell ein Werkzeug „benutzt“, führt es nichts aus. Es gibt strukturiert aus, welche Funktion es mit welchen Argumenten aufgerufen sehen möchte, und beendet seinen Zug.
Ausgeführt wird der Aufruf von Ihrem Code. Der entscheidet, ob er es tut, prüft Rechte, validiert Parameter, protokolliert und schickt das Ergebnis als neue Nachricht zurück. Erst dann formuliert das Modell die Antwort für den Nutzer.
Das ist eine gute Nachricht für die Sicherheit: Die Kontrolle liegt vollständig bei Ihnen. Und es ist zugleich die Stelle, an der in der Praxis die meisten Fehler passieren – weil Teams die Ausführung als Formsache behandeln und Werkzeuge mit weit mehr Rechten ausstatten, als die Aufgabe erfordert.
- Ein Werkzeug wird durch Name, Beschreibung und ein JSON-Schema seiner Parameter definiert
- Die Beschreibung ist Teil des Prompts – schlechte Beschreibungen führen zu falschen Aufrufen
- Ihr Code prüft Rechte und Plausibilität, bevor er ausführt
- Rückgabe erfolgt als eigene Nachricht; erst danach antwortet das Modell dem Nutzer
- Lesende und schreibende Werkzeuge gehören getrennt betrachtet und unterschiedlich abgesichert
MCP: ein Stecker statt N×M Kabel
Function Calling löst die Frage, wie ein Modell Werkzeuge anfordert. Offen bleibt, wer diese Werkzeuge bereitstellt. Ohne Standard schreibt jedes Team für jede Anwendung eigene Anbindungen an jedes System: 5 Anwendungen mal 8 Datenquellen ergeben 40 individuelle Integrationen, die alle gepflegt werden wollen.
Das Model Context Protocol setzt genau hier an. Ein MCP-Server stellt Werkzeuge, Daten und vorgefertigte Abläufe über eine standardisierte Schnittstelle bereit; jede MCP-fähige Anwendung kann sie nutzen. Aus N×M Integrationen werden N+M – dieselbe Idee, die USB für Peripheriegeräte hatte.
Für die Praxis heißt das: Der einmal gebaute MCP-Server für Ihr ERP funktioniert in der Entwicklungsumgebung, im internen Chat-Assistenten und im Agenten gleichermaßen. Wichtig ist die saubere Abgrenzung: Die API verbindet Ihre Software mit dem Modell, MCP verbindet die Anwendung mit Werkzeugen und Daten. Das eine ersetzt das andere nicht – beides greift ineinander.
Beispiel: MCP-Server fürs ERP
Ein Mittelständler baut einen MCP-Server mit vier Werkzeugen: rechnung_status (lesend), kunde_suchen (lesend), bestand_abfragen (lesend) und angebot_entwurf (schreibend, aber nur als Entwurf). Zugriffsrechte laufen über den angemeldeten Mitarbeiter, nicht über einen technischen Sammelbenutzer – ein Vertriebsmitarbeiter sieht über den Assistenten also genau das, was er auch im ERP sehen dürfte. Derselbe Server bedient anschließend den internen Chat-Assistenten und einen Agenten für die Angebotserstellung, ohne dass eine Zeile Anbindung doppelt geschrieben wurde.
Die vier Wege, ein Modell an eigene Daten zu bringen
Die häufigste Fehlentscheidung in Projekten ist der Griff zum Fine-Tuning, wenn eigentlich RAG gemeint ist. Faustregel: Fine-Tuning ändert, „wie“ ein Modell antwortet. RAG und Werkzeuge ändern, „worüber“ es Bescheid weiß.
- Prompt: Daten einfach in die Anfrage schreiben. Sofort einsatzbereit, begrenzt durch Kontextfenster und Kosten.
- RAG: passende Stellen per Vektorsuche holen und beilegen. Der Standardweg für Dokumentenwissen, aktualisierbar in Sekunden.
- Werkzeuge / MCP: das Modell fragt Live-Systeme ab. Der einzige Weg für Daten, die sich ständig ändern – Bestände, Status, Preise.
- Fine-Tuning: das Modell selbst nachtrainieren. Sinnvoll für Stil, Format und Spezialsprache – ungeeignet, um Faktenwissen aktuell zu halten.
| Weg | Aktualität | Aufwand | Kosten je Anfrage | Gut geeignet für |
|---|---|---|---|---|
| Prompt | sofort | Minuten | hoch (alles wird mitgeschickt) | Kleine, feste Datenmengen; Prototypen |
| RAG | Minuten | Tage bis Wochen | mittel | Dokumentenwissen: Handbücher, Verträge, Wiki, Berichte |
| Werkzeuge / MCP | in Echtzeit | Tage bis Wochen | mittel | Live-Daten: Bestände, Status, Preise, Buchungen |
| Fine-Tuning | veraltet ab Trainingsende | Wochen, Spezialwissen | niedrig (kurze Prompts) | Stil, Tonalität, festes Ausgabeformat, Fachsprache |
Das Wichtigste in Kürze
- API-Aufrufe sind zustandslos – der gesamte Verlauf wird jedes Mal neu mitgeschickt.
- Beim Function Calling führt das Modell nichts aus; es formuliert nur einen Aufrufwunsch.
- Die Ausführung samt Rechteprüfung und Protokoll liegt vollständig in Ihrem Code.
- MCP standardisiert den Zugang zu Werkzeugen und Daten und ersetzt N×M Integrationen durch N+M.
- API verbindet Software mit dem Modell, MCP verbindet die Anwendung mit Werkzeugen – beides ergänzt sich.
- Fine-Tuning ändert den Stil, RAG und Werkzeuge ändern das Wissen.
?Wissens-Check
Beantworten Sie die Fragen, um Ihr Verständnis zu prüfen. Sie erhalten sofort eine Rückmeldung.
Frage 1.Was passiert technisch, wenn ein Modell ein Werkzeug „aufruft“?
Frage 2.Warum sind API-Aufrufe an Sprachmodelle zustandslos?
Frage 3.Welches Problem löst MCP?
Frage 4.Ihre Lagerbestände ändern sich stündlich und sollen im Assistenten abfragbar sein. Welcher Weg passt?