Künstliche Intelligenz entfaltet ihr volles Potenzial erst, wenn sie sich kontrolliert in bestehende Prozesse und Werkzeuge einfügt. Dieser Beitrag zeigt, wie LiteLLM, MCP und Supergateway gemeinsam den Rahmen schaffen, KI‑Fähigkeiten gezielt zu steuern, sicher zu betreiben und Schritt für Schritt nutzbar zu machen.
Genau hier setzen LiteLLM und das Model Context Protocol (MCP) an: LiteLLM bündelt über 100+ Modelle hinter einem zentralen Endpunkt, MCP standardisiert die Tool-Schnittstellen für Agenten und Clients. Kombiniert erhalten wir ein einziges Gateway, das sowohl Modelle als auch Tools kontrolliert verteilt.
Dieser Beitrag ergänzt unsere Reihe zu LLM Infrastruktur und intelligenten Tools, mit den Artikeln
„KI mit Web Search Power – Perplexity accountfrei selbst betreiben“ und
„Model Context Protocol: Potenziale und Risiken des MCP“ als bisherige Grundlagen.
Architektur: MCP pro Pod mit Supergateway
Das Muster „MCP pro Pod“ trennt Fähigkeiten sauber. Jede konkrete Fähigkeit oder jeder Team‑Service läuft als eigener MCP-Server (Pod). Diese Pods sprechen oft stdio (Prozess-I/O) und sind zunächst lokal. Hier kommt Supergateway ins Spiel: Es macht stdio-basierte MCP-Server netzwerkfähig und für unterschiedliche Clients erreichbar, indem es Transportformate überbrückt. Es hebt stdio auf einfache, webtaugliche Transporte wie SSE und optional WebSockets, damit Clients und Gateways Pods konsistent ansprechen können.
Der Sinn ist Reichweite und Ordnung statt Spezialpfade. Pods werden remote nutzbar, Debugging und Betrieb vereinfachen sich und auf der Client-Seite entfällt das Pflegen unterschiedlicher Transportarten. Gleichzeitig bleiben Zuständigkeiten klar, jede Fähigkeit skaliert, wird versioniert und beobachtet, ohne andere Fähigkeiten zu berühren.
LiteLLM als zentrales Gateway: Governance, Routing, Gruppen
Über der Landschaft der Pods liegt LiteLLM als zentrale Vermittlungsschicht. Es stellt einen einheitlichen API Endpunkt bereit, registriert MCP Tools und macht sie auch für Clients nutzbar, die MCP nicht sprechen, indem es die Tool Schemas als kompatible Funktionsaufrufe bereitstellt.
Der Mehrwert liegt in Governance und Betrieb. LiteLLM verwaltet Benutzergruppen, Rollen und Zugriffsprofile, setzt Quotas und Rate Limits, trennt Mandanten sauber und gibt Authentifizierungsinformationen wie OAuth Bearer und zusätzliche Header kontrolliert weiter. Policies definieren, wann welches Modell zum Einsatz kommt, etwa sensible Inhalte lokal und generische Anfragen kosteneffizient, und Fallbacks sichern die Verfügbarkeit bei Ausfällen. Alle Aufrufe sind auditierbar, nachvollziehbar ist, wer welches Tool genutzt hat und mit welchen Kosten und Latenzen.
Prompt und Output Redaktion sowie die Handhabung von Chain of Thought lassen sich standardisieren. Ein konsistentes Observability und Kostenbild rundet den Betrieb ab, neue Tools kommen als zusätzliche MCP Pods hinzu, neue Modelle per Konfiguration.
Auszug aus der Config von LiteLLM:
mcp_servers:
perplexity:
url: "http://supergateway-perplexity:8096/sse"
transport: "sse"
auth_type: "none"
access_groups: ["*"]
context7:
url: "http://supergateway-context7:8097/sse"
transport: "sse"
auth_type: "none"
access_groups: ["*"]
Integration: Open WebUI und GitHub Copilot
Das Ziel ist ein konsistentes Nutzererlebnis über verschiedene Clients. Open WebUI nutzt eine OpenAI kompatible Schnittstelle und zeigt einfach auf den LiteLLM Endpunkt. LiteLLM registriert die MCP Tools, hängt sie bei Bedarf an Anfragen an und führt den passenden Pod aus, sobald das Modell einen Aufruf anfordert. Das Ergebnis fließt direkt in die Antwort, Open WebUI muss MCP dafür nicht kennen.
Auch wenn MCP-Server ihre Fähigkeiten standardisiert anbieten, ist damit noch nicht garantiert, dass Nutzer:innen sie entdecken und zielgerichtet einsetzen. Hier kommt die Bedeutung von Tool-Discovery und Bündelung ins Spiel. Sammelnde Portale oder Workspaces, die Funktionen thematisch gruppieren, erleichtern die Orientierung und senken die Einstiegshürde. So bleibt die Vielfalt kontrolliert nutzbar, statt im Überangebot unterzugehen.
Für GitHub Copilot bietet sich der Weg über Erweiterungen an, die eigene HTTP Endpunkte aufrufen. Dahinter steht entweder Supergateway, das die Pods über SSE oder klassische HTTP Zugriffe erreichbar macht, oder LiteLLM als Proxy, das die Funktionen auslöst und die passende Fähigkeit ausführt. In beiden Fällen werden Autorisierungsheader durchgereicht, Gruppenrechte und Kontingente zentral über LiteLLM durchgesetzt, und das Team erhält dieselben Fähigkeiten in der IDE wie im Web Client.
Grenzen und Risiken
So viel Potenzial die Architektur bietet, sie erfordert zugleich klare Leitplanken.
Ein zentrales Risiko ist Prompt Injection, also die gezielte Manipulation von Eingaben, um Modelle dazu zu bringen, interne Informationen preiszugeben oder unerwartete Aktionen auszuführen. LiteLLM kann hier über Rollen, Zugangskontrolle und Validierungsschichten Schutz bieten, ersetzt aber keine Sicherheitsprüfung auf der Tool Ebene.
Auch der Datenschutz bleibt kritisch: Wenn Fähigkeiten über MCP Pods spontan auf Unternehmenssysteme zugreifen, dürfen keine adhoc Verbindungen entstehen, die personenbezogene Daten außerhalb ihres festgelegten Verarbeitungszwecks nutzen. Governance Mechanismen und Audit Trails sind daher Voraussetzung, um DSGVO konform zu bleiben.
Fazit & Ausblick
LiteLLM, MCP und Supergateway ergeben zusammen ein klares Muster für produktive KI Arbeit. Fähigkeiten werden als eigenständige Pods bereitgestellt, Supergateway macht sie einfach erreichbar und LiteLLM führt alles unter einer zentralen Steuerung zusammen. So bleiben Tools stabil, Modelle austauschbar und Clients wie Open WebUI oder GitHub Copilot bekommen ein konsistentes Erlebnis, ohne dass Transportdetails oder Integrationslogik in jede Anwendung wandern.
Der unmittelbare Ausblick ist pragmatisch. Ein lokaler Durchstich zeigt schnell, was mit MCP und Supergateway erreichbar ist. Danach folgen die ersten Policies in LiteLLM für Gruppen, Rechte und Kosten, sowie die Anbindung von Open WebUI über ein zentrales Gateway. Mit einer kleinen Copilot Erweiterung kommen dieselben Fähigkeiten in die IDE.
Langfristig wächst die Landschaft über weitere Pods, getrennte Umgebungen und klarere Verantwortlichkeiten pro Fähigkeit. Wo Abläufe mehrstufig und verzweigt werden, kann ein Orchestrator ergänzen und Reihenfolgen sowie Budgets dynamisch steuern. Das Zielbild ist eine skalierbare und auditierbare Architektur, in der Werkzeuge zentral verwaltet und sicher verteilt werden, während Nutzer:innen in Web und IDE dieselben Fähigkeiten erhalten und produktiv nutzen.
Möchten Sie intelligente Tools gezielt in Ihrem Unternehmen einsetzen?
Wir unterstützen Sie dabei, passende Lösungen zu konzipieren, sicher zu integrieren und produktiv nutzbar zu machen. So entstehen Systeme, in denen künstliche Intelligenz und bestehende Anwendungen sinnvoll zusammenarbeiten.
Wir beraten Sie gerne zu Ihren Möglichkeiten.
