Glossar
MCP
Auch: Model Context Protocol · MCP-Server
Ein offener Standard, über den Sprachmodelle Werkzeuge und Datenquellen ansprechen: eine gemeinsame Schnittstelle statt einer Integration je Anbieter.
Vor MCP schrieb man die Anbindung eines Werkzeugs für jedes Modell und jede Umgebung neu. Das Protokoll normiert, wie ein Modell erfährt, welche Werkzeuge es gibt, welche Parameter sie erwarten und was sie zurückgeben. Ein Server, viele Verbraucher.
Ein MCP-Server ist dabei keine KI, sondern ein ganz gewöhnlicher Dienst: Er bietet Werkzeuge an, nimmt Aufrufe entgegen, führt sie aus und antwortet. Der interessante Teil ist deshalb selten das Protokoll, sondern was dahinter steht: Zugriffsrechte, Protokollierung, Fehlerverhalten und die Frage, was ein Aufruf im Zielsystem tatsächlich anrichten kann.
Genau hier trennt sich Demo von Produktion. In der Demo greift der Server mit einem allmächtigen Schlüssel auf die Datenbank zu. In Produktion braucht es die Identität des Nutzers, in dessen Namen gehandelt wird, ein Rechtemodell dahinter und einen Audit-Trail, der später beantwortet, wer was ausgelöst hat.
Der zweite Produktionsaspekt ist die Werkzeugmenge. Jedes angebotene Werkzeug kostet Kontext, weil seine Beschreibung bei jedem Aufruf mitgeschickt wird, und erhöht die Wahrscheinlichkeit einer falschen Wahl. Zwanzig gut beschriebene Werkzeuge sind schlechter als sechs, die die Aufgabe abdecken.
Sicherheitsseitig ist ein MCP-Server eine neue Angriffsfläche. Was in einem Dokument steht, das ein Werkzeug zurückgibt, landet im Kontext des Modells und kann dort als Anweisung gelesen werden. Wer schreibende Werkzeuge anbietet, braucht eine Bestätigungsstufe für alles, was nicht rückgängig zu machen ist.
Woran Sie es erkennen
- Für jedes Modell wurde die Werkzeuganbindung neu geschrieben.
- Der Server greift mit einem einzigen technischen Konto auf alle Daten zu.
- Es gibt kein Protokoll darüber, welcher Nutzer welches Werkzeug ausgelöst hat.
- Schreibende Werkzeuge laufen ohne Bestätigungsschritt.
Nicht zu verwechseln mit
- Function Calling
- Der modellseitige Mechanismus, überhaupt ein Werkzeug aufzurufen. MCP standardisiert, wie die Werkzeuge beschrieben und angebunden werden. Function Calling ohne MCP ist möglich, aber je Anbieter anders.
- REST-API
- Eine Schnittstelle für Programme. MCP beschreibt Werkzeuge zusätzlich so, dass ein Modell sie ohne Vorwissen auswählen kann. Oft liegt ein MCP-Server als dünne Schicht vor bestehenden REST-Diensten.
- RAG
- Liefert Wissen in den Kontext. MCP liefert Handlungsfähigkeit. Viele Systeme brauchen beides, aber es sind verschiedene Probleme.
- Plugins der Anbieter
- Herstellergebunden. MCP ist offen, weshalb derselbe Server von verschiedenen Modellen und Werkzeugen genutzt werden kann.
Wann es trägt
- Mehrere Modelle oder Umgebungen sollen dieselben Werkzeuge nutzen.
- Das Modell soll in Bestandssystemen handeln, nicht nur Text erzeugen.
- Zugriffe müssen nachvollziehbar sein, weil sie Geschäftsvorfälle auslösen.
Wann nicht
- Für einen einzelnen, festen Aufruf reicht eine direkte Integration.
- Wenn nur Wissen fehlt und nichts ausgelöst werden soll: dann ist RAG das Thema.
- Ohne Rechtemodell im Zielsystem. Ein MCP-Server erbt dessen Schwächen und macht sie leichter erreichbar.
Wie man rangeht
- Werkzeuge nach Aufgaben schneiden, nicht nach TabellenEin Werkzeug „Kunde anlegen" ist besser als drei, die einzelne Felder schreiben. Grobe, fachliche Schnitte reduzieren Fehlgriffe und Kontextverbrauch.
- Lesen und Schreiben trennenLesende Werkzeuge sind unkritisch, schreibende brauchen eine eigene Freigabe. Diese Trennung im Server sichtbar zu machen ist einfacher, als sie später nachzurüsten.
- Identität durchreichenDer Aufruf handelt im Namen eines Nutzers, mit dessen Rechten, nicht mit einem Dienstkonto. Über OAuth und einen Token-Broker, nicht über einen gemeinsamen Schlüssel.
- Jeden Aufruf protokollierenWer, welches Werkzeug, welche Parameter, welches Ergebnis. Ohne diesen Trail lässt sich hinterher nicht klären, was passiert ist, und genau das wird gefragt werden.
- Kosten und Grenzen setzenRatelimit je Nutzer, Obergrenze für Aufrufe je Vorgang, Zeitlimit je Werkzeug. Ein Modell, das in einer Schleife hängt, ruft sonst unbegrenzt auf.
- Rückgaben als unsichere Daten behandelnWas ein Werkzeug zurückgibt, kann Anweisungen enthalten. Klar vom Systemtext trennen und niemals ungeprüft als Befehl ausführen.
Häufig gefragt
Was ist der Unterschied zwischen MCP und Function Calling?
Function Calling ist der Mechanismus im Modell, überhaupt ein Werkzeug aufrufen zu können. MCP standardisiert die andere Seite: wie Werkzeuge beschrieben, angeboten und angebunden werden. Ohne MCP funktioniert Function Calling auch, aber die Integration ist je Anbieter unterschiedlich und wird bei jedem Wechsel neu geschrieben.
Wie viele Werkzeuge sollte ein Server anbieten?
So wenige wie möglich, fachlich geschnitten. Jede Werkzeugbeschreibung geht bei jedem Aufruf in den Kontext und kostet damit Geld und Aufmerksamkeit. Sechs klar abgegrenzte Werkzeuge liefern in der Regel bessere Ergebnisse als zwanzig feingliedrige.
Wie sichert man einen MCP-Server ab?
Identität des Nutzers durchreichen statt Dienstkonto, Rechte im Zielsystem prüfen statt im Server, schreibende Aufrufe mit Bestätigung, jeden Aufruf protokollieren, Ratelimits setzen und Rückgaben von Werkzeugen als unsichere Daten behandeln. Der letzte Punkt wird am häufigsten vergessen und ist der Einstiegspunkt für Prompt-Injection.
Braucht man MCP oder reicht eine normale API?
Wenn genau ein festes Werkzeug an genau ein Modell angebunden wird, reicht eine direkte Integration. MCP lohnt sich, sobald mehrere Werkzeuge, mehrere Modelle oder mehrere Umgebungen im Spiel sind, und dort spart es die Mehrfacharbeit, die sonst bei jedem Wechsel anfällt.