MCP steht für Model Context Protocol: ein offener Standard, über den ein LLM-Client — etwa ein KI-Agent — Werkzeuge, Datenquellen und Prompt-Vorlagen entdeckt und aufruft, ohne für jede Anbindung eigenen Integrationscode zu schreiben. Seit der Verbreitung durch Anthropic Ende 2024 haben praktisch alle relevanten Agenten-Frameworks und Modellanbieter MCP-Unterstützung nachgezogen. Mitte 2026 ist die Frage bei neuen Projekten nicht mehr, ob man MCP nutzt, sondern wie man es sicher betreibt.
Genau da liegt das Problem, das wir in diesem Artikel behandeln. MCP-Server sind einfach zu bauen und noch einfacher direkt an einen Agenten zu hängen. In einem Prototyp ist das in Ordnung. In Produktion, mit echtem Datenzugriff und echten Kosten, ist die Direktanbindung eine Wette, die man nicht eingehen sollte — und wir zeigen, warum ein Tool-Gateway davor gehört, wie es aufgebaut ist und wo die Grenze eines solchen Ansatzes liegt. Der Tool-Layer ist eine von fünf Schichten unserer Agentic-AI-Infrastruktur — einen Überblick über alle Schichten samt interaktiver Systemkarte finden Sie auf der Übersichtsseite.
Was ein MCP-Server tatsächlich ist
Ein MCP-Server ist ein Prozess, der eine Menge von Tools, Resources und optional Prompts über ein standardisiertes JSON-RPC-Protokoll bereitstellt. Jedes Tool trägt einen Namen, eine natürlichsprachliche Beschreibung und ein JSON-Schema für Eingabe und Ausgabe. Ein Client — der Agent oder die Runtime, die ihn ausführt — verbindet sich mit dem Server, fragt die verfügbaren Tools ab und kann sie danach mit validierten Parametern aufrufen.
Der entscheidende Unterschied zu klassischer Software-Integration: Das Schema ist Teil des Protokolls, nicht nur der Dokumentation. Ein Modell erhält beim Verbindungsaufbau exakt die Information, die es braucht, um zu entscheiden, ob und wie es ein Werkzeug einsetzt — ohne dass ein Mensch vorher Code schreibt, der API-Aufruf und Modellausgabe manuell verdrahtet.
MCP-Server vs. REST-API: der Unterschied, der zählt
Technisch ließe sich fast jeder MCP-Server auch als REST-Endpunkt bauen — und umgekehrt lässt sich fast jede REST-API über einen schlanken MCP-Server erschließen. Der Unterschied liegt nicht im Transportweg, sondern darin, für wen die Schnittstelle gedacht ist.
- Zielgruppe: Eine REST-API richtet sich an Entwickler, die die Dokumentation lesen und Client-Code schreiben. Ein MCP-Server richtet sich an ein Modell, das die Beschreibung zur Laufzeit interpretiert.
- Discovery: REST-Endpunkte werden zur Build-Zeit fest verdrahtet. MCP-Tools werden zur Laufzeit über die Registry entdeckt — dazu mehr im nächsten Abschnitt.
- Fehlerformat: MCP definiert ein einheitliches Fehler- und Rückgabeformat, das ein Modell konsistent interpretieren kann. Bei REST-APIs variiert das von Anbieter zu Anbieter.
- Vertrauensmodell: Eine REST-Antwort landet in Ihrem Code. Eine MCP-Rückgabe landet im Kontextfenster des Modells — und wird damit potenziell wie eine Anweisung behandelt, wenn man nicht aktiv gegensteuert.
Der letzte Punkt ist praktisch der wichtigste und der Grund, warum MCP-Server anders behandelt werden müssen als klassische Backend-Integrationen. Mehr dazu im Abschnitt zur agentischen Lieferkette weiter unten.
Die Registry verschiebt die Werkzeugauswahl in die Laufzeit
Statisch konfigurierte Werkzeuglisten altern schlecht: Jedes neue Tool erfordert ein Deployment des Agenten, jede Entfernung hinterlässt tote Referenzen im Prompt. Eine MCP-Registry löst das, indem sie ein Verzeichnis verfügbarer Server samt Tool-Beschreibungen führt. Ein Agent fragt zur Laufzeit ab, welche Werkzeuge zu seiner Aufgabe und seiner Identität passen — er kann also Werkzeuge nutzen, die es beim Deployment noch gar nicht gab.
In der Praxis: Diese Verschiebung von Start- zu Laufzeit ist der eigentliche Architekturwechsel gegenüber klassischer Softwareintegration. Sie bringt Flexibilität — und genau deshalb braucht sie eine Instanz, die zur Laufzeit auch verweigern kann. Diese Instanz ist das Gateway, nicht der einzelne MCP-Server.
Wichtig für die Praxis: Die Registry entscheidet, was ein Agent sehen kann. Sie entscheidet nicht, ob ein konkreter Aufruf gerade erlaubt ist. Diese zweite Entscheidung — mit welchen Parametern, wie oft, mit welchem Ergebnis protokolliert — ist Aufgabe des Gateways, das wir im Folgenden im Detail beschreiben.
Warum MCP-Server in Produktion nicht direkt an den Agenten gehören
Ohne Gateway spricht der Agent direkt mit dem MCP-Server. Das funktioniert im Prototyp, weil dort meist ein Entwickler, ein Server und ein überschaubares Risiko zusammentreffen. Sobald mehrere Systeme, mehrere Agenten und echte Schreibrechte im Spiel sind, ändert sich die Rechnung fundamental — aus vier Gründen, die uns in Projekten regelmäßig begegnen.
- Geteilte Admin-Token statt Scopes je Server. Ohne zentrale Instanz landet meist ein einziges, weitreichendes Zugangstoken in der Agent-Konfiguration — für Postgres, M365, ERP und Ticketsystem gleichzeitig. Ein kompromittierter Agent kompromittiert dann alle vier Systeme auf einmal.
- Keine einheitliche Schema-Prüfung auf dem Rückweg. MCP-Server prüfen in der Regel die Eingabe gegen ihr eigenes Schema. Die Ausgabe — also das, was zurück ins Modell fließt — wird selten geprüft, obwohl sie potenziell Anweisungen enthält, die das Modell befolgt.
- Rate-Limits und Timeouts liegen verstreut. Jeder Server implementiert sie unterschiedlich oder gar nicht. Ein Agent, der sich in einer Schleife verfängt, kann so unbemerkt eine Datenbank oder eine externe API überlasten.
- Kein einheitliches Audit-Log. Bei einem Sicherheitsvorfall oder einer Rückfrage der Fachabteilung müssen Sie aus vier verschiedenen Server-Logs rekonstruieren, was der Agent wann getan hat — wenn die Server überhaupt ausreichend protokollieren.
Die Lösung ist kein zusätzlicher MCP-Server, sondern eine Schicht zwischen Agent und MCP-Servern: das Tool-Gateway. Im Architektur-Kapitel unserer Agentic-AI-Plattform ist das die dritte von fünf Schichten — und aus gutem Grund keine optionale.
Die sechs Bausteine eines produktionstauglichen Gateways
Ein Tool-Gateway im Sinne von HostSpezials Tool-Layer ist kein Reverse-Proxy mit ein bisschen Logging. Es ist eine Policy-Engine mit sechs klar abgegrenzten Aufgaben, die jeder Aufruf durchläuft, bevor er den eigentlichen MCP-Server erreicht.
1. Auth je Server, nicht ein geteiltes Admin-Token
Jeder angebundene MCP-Server bekommt ein eigenes Dienstkonto mit eigenem Scope. Das Gateway übersetzt die Identität des aufrufenden Agenten in das jeweilige Dienstkonto — der Agent selbst sieht das zugrundeliegende Credential nie. Fällt ein Agent aus oder wird kompromittiert, lässt sich sein Zugriff auf ein einzelnes System sperren, ohne die anderen drei anzufassen.
2. Schema-Validierung auf Ein- und Ausgabe
Die Eingabe wird gegen das deklarierte JSON-Schema des Tools geprüft, bevor sie den Server erreicht. Die Rückgabe wird ebenfalls gegen ein Schema geprüft und als reine Daten markiert — nicht als Anweisung. Das ist der Punkt, an dem die meisten Direktanbindungen versagen: Sie prüfen, was hineingeht, aber nicht, was zurückkommt.
3. Rate-Limiting je Agent und Werkzeug
Quoten pro Zeitfenster verhindern, dass eine fehlerhafte Schleife oder ein manipulierter Prompt eine Datenbank mit tausenden Abfragen pro Minute belastet. Das Limit liegt im Gateway, nicht in der Kontrolle des Modells — ein Modell kann eine Prompt-Anweisung ignorieren, ein Rate-Limit im Gateway nicht.
4. Timeouts mit definiertem Fehlerverhalten
Jeder Aufruf bekommt ein hartes Zeitbudget. Läuft ein MCP-Server in einen Timeout, erhält der Agent eine strukturierte Fehlermeldung statt eines hängenden Prozesses — wichtig, damit die Orchestrierung sauber auf Fehlschläge reagieren kann, statt den gesamten Lauf zu blockieren.
5. Audit-Log je Aufruf
Agent-ID, Werkzeug, sanitisierte Parameter, Latenz, Entscheidung — in einem Format, mit einer Aufbewahrungsfrist, unabhängig davon, wie gut der einzelne MCP-Server selbst protokolliert. Details zum Trace-Format und zur Auswertung stehen im Observability-Kapitel.
6. Egress-Allowlist für nicht verifizierte Server
Extern gepflegte oder neue MCP-Server laufen zusätzlich in einer isolierten Umgebung mit einer festen Liste erlaubter Zielhosts. Ein Server, der eigentlich nur ein CRM abfragen soll, kann so keine beliebigen Daten an fremde Endpunkte senden, selbst wenn er dazu manipuliert würde. Die Details dazu stehen im Security-Kapitel.
Praxisbeispiel: vier Systeme, vier Dienstkonten, ein Gateway
Ein typisches Anbindungsprojekt bei einem Mittelständler sieht bei uns so aus: ein Support- oder Sachbearbeitungsagent soll auf vier Systeme zugreifen können — Postgres-Datenbank, Microsoft 365, das interne Ticketsystem und das ERP. Statt einer Sammelverbindung entstehen vier eigenständige MCP-Server mit eigenem Dienstkonto und eigenem Scope.
- MCP-Server Postgres: Dienstkonto mit ausschließlich lesenden Rechten, Statement-Allowlist auf
SELECT, Begrenzung auf maximal 500 Zeilen je Antwort. Scope:read:orders,read:customers. - MCP-Server Microsoft 365: Delegierte Rechte über eine Azure-App-Registrierung, kein globaler Admin-Zugriff. Scope:
read:mail,read:calendar. Details zur Anbindung stehen im Artikel zur Agentic-AI-Systemintegration. - MCP-Server Ticketsystem: Eigener API-Key mit Lese- und begrenztem Schreibzugriff. Scope:
read:tickets,write:comment— Statuswechsel und Eskalation sind explizit ausgenommen und laufen über eine separate Freigabe. - MCP-Server ERP: Technischer Benutzer mit Zugriff nur auf die für den Anwendungsfall relevanten Belegarten, keine Buchungsrechte. Scope:
read:invoices.
Der Ablauf eines einzelnen Calls: Der Agent entscheidet im Rahmen seiner Orchestrierung, dass er eine offene Rechnung im ERP nachschlagen muss. Er sendet den Tool-Call an das Gateway, nicht an den ERP-MCP-Server direkt. Das Gateway prüft die Agent-Identität, validiert die Parameter gegen das Schema des Tools, prüft das Rate-Limit für diesen Agenten und dieses Werkzeug, trifft die Policy-Entscheidung (erlaubt, weil Scope und Statement passen), leitet den Aufruf mit dem ERP-Dienstkonto weiter, validiert die Rückgabe gegen das Ausgabeschema und schreibt Agent-ID, Werkzeug, sanitisierte Parameter und Latenz ins Audit-Log.
Latenzbudget als Rechenbeispiel: In unserer Plattform liegt der p95-Zusatzaufwand des Gateways bei rund 8 Millisekunden je Aufruf — unabhängig von der Laufzeit des Tools selbst. Bei einer typischen ERP-Abfrage von 80 bis 150 Millisekunden ist das ein Aufschlag von etwa 5 bis 10 Prozent, meist innerhalb der Messtoleranz des Gesamtlaufs. Bei einer Kette aus zehn Tool-Calls in einem orchestrierten Multi-Agent-Lauf summiert sich das auf rund 80 Millisekunden zusätzliche Wartezeit — in der Praxis meist geringer als die Varianz einzelner Backend-Antwortzeiten.
Kostenseitig gilt: Die Betriebspauschale für Gateway, Registry und Monitoring ist Teil unserer KI Managed Services — je nach Umfang zwischen 690 und 1.490 Euro monatlich zzgl. USt. für Standard- bis Business-Betrieb, ab 3.900 Euro monatlich für individuell geschnittene Enterprise-Setups. Hinzu kommen nutzungsabhängige Komponenten je Lauf, je Tool-Call und je Million Tokens. Diese Nutzungsraten sind zum jetzigen Zeitpunkt noch nicht final kalkuliert — Details dazu und ein durchgerechnetes Rechenbeispiel finden Sie auf der Preise-Seite.
Direktanbindung, Gateway oder SaaS-Connector: die Entscheidung im Vergleich
Nicht jedes Projekt braucht sofort ein eigenes Gateway. Die folgende Übersicht zeigt, wo die drei gängigen Anbindungswege in der Praxis stehen.
| Kriterium | Direktanbindung | Tool-Gateway davor | SaaS-Agent-Connector |
|---|---|---|---|
| Authentifizierung | Meist ein geteiltes Admin-Token für alle Systeme | Eigenes Dienstkonto je MCP-Server, zentral verwaltet | Anbieter-OAuth, kaum eigenes Scoping möglich |
| Schema-Prüfung Eingabe | Nur, wenn der einzelne Server sie selbst implementiert | Zentral vor jedem Aufruf, unabhängig vom Server | Ja, aber als Blackbox des Anbieters |
| Schema-Prüfung Ausgabe | Praktisch nie vorhanden | Ja, Rückgabe wird geprüft und als Daten markiert | Anbieterabhängig, meist nicht einsehbar |
| Rate-Limiting & Timeouts | Je Server unterschiedlich oder gar nicht vorhanden | Zentral, je Agent und je Werkzeug konfigurierbar | Anbieterseitig fest vorgegeben |
| Audit-Log | Verstreut in einzelnen Server-Logs | Ein Format, ein Aufbewahrungszeitraum, ein Ort | Nur so weit, wie der Anbieter exportiert |
| Egress-Kontrolle | In der Regel keine | Allowlist je nicht verifiziertem Server | Keine, Traffic verlässt die eigene Infrastruktur vollständig |
| Betriebsaufwand | Gering am Anfang, hoch bei Skalierung oder Vorfall | Mittel, dafür zentral gebündelt | Gering, dafür Anbieterbindung |
| Typischer Einsatz | Prototyp mit ein bis zwei internen Werkzeugen | Produktivbetrieb mit mehr als drei Systemen und Schreibzugriff | Schneller Start ohne eigene Infrastruktur, geringer Kontrollbedarf |
Die agentische Lieferkette: warum das Gateway kein Selbstzweck ist
Ein Tool-Gateway ist auch deshalb notwendig, weil MCP-Server 2026 zu einer eigenen Risikokategorie geworden sind, der sogenannten agentischen Lieferkette. Drei Muster begegnen uns regelmäßig: Die Tool-Beschreibung selbst landet im Modellkontext und wird damit zur Angriffsfläche, ohne dass das Werkzeug je aufgerufen wird. Eine Rückgabe — ein Dokument, eine Ticketnotiz, eine API-Antwort — enthält Text, der wie eine Anweisung aussieht; ohne klare Trennung zwischen Daten und Instruktion folgt das Modell ihr, klassische Prompt Injection über die Hintertür. Und ein extern gepflegter MCP-Server ändert sein Verhalten in einem Update, ohne dass sich das deklarierte Schema ändert.
Das Gateway adressiert alle drei Muster strukturell: gepinnte Versionen für verifizierte Quellen, Isolation mit Egress-Allowlist für alles andere, und die feste Regel, dass jede Werkzeug-Rückgabe als Daten und nie als Anweisung gilt. Eine ausführliche Einordnung dieses Risikotyps — inklusive Checkliste für die Bewertung fremder MCP-Server — behandeln wir im Schwesterartikel zur agentischen Lieferkette. Wer stattdessen strukturiert Kontenrechte statt geteilter Admin-Zugänge vergeben will, findet die Grundlagen im Artikel Agent Identity statt Admin-Rechte.
Wann sich ein eigenes Gateway nicht lohnt
Ehrlich: Nicht jedes Setup braucht die volle Ausbaustufe. Ein Tool-Gateway lohnt den Aufwand nicht, wenn eine der folgenden Bedingungen zutrifft:
- Ein einziger Agent, ein einziges internes Werkzeug. Wenn nur ein Anwendungsfall ein stabiles, selbst kontrolliertes Tool nutzt, reicht ein direkt im Orchestrierungs-Framework registrierter Funktionsaufruf. Der MCP-Umweg lohnt sich, sobald mehr als ein Agent oder mehr als ein Client dasselbe Werkzeug braucht.
- Reine Lesezugriffe ohne sensible Daten. Ein Wetter- oder Wechselkurs-Tool ohne Personenbezug und ohne Schreibrecht rechtfertigt selten den vollen Policy-Aufbau — ein einfaches Rate-Limit reicht oft aus.
- Sehr kleine Pilotphasen. In den ersten Wochen eines Proof of Concept ist ein schlankes, manuell überwachtes Setup vertretbar — solange der Übergang zum Gateway vor dem Produktivstart feststeht und nicht auf „später" verschoben wird.
- Bereits vorhandene, geprüfte SaaS-Agentenplattform. Wer einen fertigen Agent-SaaS-Connector nutzt, der bereits Auth, Logging und Rate-Limits mitbringt, muss diese Schicht nicht doppelt selbst bauen — dafür entsteht Anbieterbindung, siehe Vergleichstabelle oben.
- Strenge Datenresidenz-Anforderungen sprechen für On-Premise. Soll das gesamte Setup inklusive MCP-Servern und Gateway im eigenen Rechenzentrum bleiben, ist das technisch möglich und Teil unseres Angebots zur KI On-Premise — dort verschiebt sich die Abwägung eher in Richtung Betriebsaufwand als Sicherheitsrisiko.
Grenzen des Gateways selbst: Ein Gateway prüft Form, Herkunft und Grenzwerte eines Aufrufs — nicht dessen fachliche Richtigkeit. Ein syntaktisch korrekter, formal erlaubter Aufruf mit inhaltlich falschem Parameter (die falsche Rechnungsnummer, der falsche Kunde) geht durch. Deshalb gehören Betragsgrenzen, Freigabeschwellen und eine Eval-Suite zwingend dazu — nicht als Ersatz, sondern als Ergänzung zum Gateway. Details dazu im Observability-Kapitel.
Häufige Fragen zu MCP-Servern und Tool-Gateways
Was ist ein MCP-Server, und wie unterscheidet er sich von einer klassischen REST-API?
Ein MCP-Server macht Werkzeuge, Daten und Prompts über das Model Context Protocol für LLM-Anwendungen entdeckbar und aufrufbar — inklusive maschinenlesbarer Beschreibung, was ein Werkzeug tut und welche Parameter es erwartet. Eine REST-API kennt kein eingebautes Vokabular für Agenten: Jede Anbindung braucht eigene Dokumentation und eigenes Client-Mapping, das der Agent nicht automatisch versteht.
Warum reicht es nicht, den Agenten direkt mit dem MCP-Server sprechen zu lassen?
Weil MCP selbst keine Instanz für Autorisierung, Rate-Limiting oder Audit über mehrere Server hinweg vorschreibt. Ohne Gateway landet die Kontrolle verstreut in jedem einzelnen Server — meist gar nicht. In der Praxis bedeutet das ein geteiltes Admin-Token für mehrere Systeme und keine Stelle, an der ein riskanter Aufruf zuverlässig gestoppt werden kann.
Was genau prüft ein Tool-Gateway bei jedem Aufruf?
Fünf Dinge in fester Reihenfolge: Wer ruft auf und mit welchem Dienstkonto, entsprechen Ein- und Ausgabe dem deklarierten Schema, ist das Rate-Limit noch nicht ausgeschöpft, erlaubt die Policy diesen Aufruf mit diesen Parametern, und wird der Aufruf mit Parametern, Entscheidung und Latenz protokolliert. Erst danach erreicht der Aufruf den MCP-Server.
Wie viel Latenz kostet ein Gateway zusätzlich?
In unserem Betrieb liegt der p95-Zusatzaufwand bei rund 8 Millisekunden je Aufruf — ohne die Laufzeit des eigentlichen Werkzeugs. Gegenüber der Latenz eines typischen Datenbank- oder API-Calls von 50 bis 300 Millisekunden ist das kaum relevant, sollte bei sehr langen Tool-Ketten aber ins Latenzbudget eingeplant werden.
Wie viele MCP-Server sollte ein Unternehmen typischerweise anbinden?
Unser Standardkatalog deckt sieben gängige Systeme ab, von Datenbanken über Microsoft 365 bis zum SIEM. Die meisten Mittelständler starten mit drei bis fünf: eine Datenquelle, ein Kommunikationssystem, ein Ticket- oder ERP-System. Mehr Server bedeuten nicht automatisch mehr Nutzen, sondern vor allem mehr Scopes, die gepflegt werden müssen.
Wann reicht ein einfacher Funktionsaufruf statt eines MCP-Servers?
Wenn nur ein einziger Agent ein einziges, stabiles internes Werkzeug nutzt, das sich nie ändert und nie von Dritten wiederverwendet wird, ist ein direkt registrierter Funktionsaufruf oft schneller gebaut als ein eigener MCP-Server mit Schema und Betrieb. Der Umweg über MCP lohnt sich, sobald mehr als ein Agent oder Client dasselbe Werkzeug braucht.
Was passiert, wenn ein MCP-Server kompromittiert oder manipuliert wird?
Nicht verifizierte oder extern gepflegte Server laufen bei uns zusätzlich isoliert mit Egress-Allowlist, gepinnter Version und der festen Regel, dass ihre Rückgabe als Daten und nie als Anweisung gilt. Das begrenzt den Schaden, ersetzt aber nicht die Prüfung des Anbieters selbst.
Ein letzter Punkt zur Einordnung, weil er in Kundengesprächen häufig auftaucht: Weder EU AI Act noch DSGVO schreiben ein Tool-Gateway wörtlich vor. Aber beide verlangen Nachvollziehbarkeit, Zugriffskontrolle nach dem Zero-Trust-Prinzip und die Fähigkeit, im Vorfallsfall zu belegen, wer wann worauf zugegriffen hat. Ein Audit-Log je Aufruf ist in der Praxis die einfachste Art, diese Anforderung zu erfüllen, ohne bei jedem Systemwechsel neue Nachweise zu konstruieren.
Wer die Systemintegration eines Agenten von Grund auf plant, findet den technischen Gesamtüberblick im Artikel Agentic-AI-Systemintegration. Wie sich der gesamte Weg vom ersten Prototyp bis zur Gateway-gestützten Produktivumgebung realistisch planen lässt, beschreibt unser Artikel zu Durable Execution für KI-Agenten aus der Laufzeit-Perspektive dieser Serie.