Wenn die KI die Infrastruktur steuert: drei Lektionen für einen produktionsreifen MCP-Server

Ein KI-Chat-Agent, dem man in normaler Sprache sagt „klone die Test-VM, behalte SSH-Keys und Passwort, gib ihr nur einen neuen Namen und eine neue IP" — und es passiert einfach: Das ist der Moment, in dem Model Context Protocol (MCP) von einer Spielerei zu einem echten Betriebswerkzeug wird. In der Live-Demo wirkt das wie Magie.

Produktiv wird daraus erst durch die Arbeit, die man in der Demo nicht sieht. Wir haben einen MCP-Server für die Verwaltung eines Proxmox-Clusters gebaut, gehärtet und in einen Chat-Agenten eingebunden. Hier sind die drei Lektionen, die den Unterschied zwischen „funktioniert im Vorführmodus" und „läuft im Alltag" ausmachen.

Die Killer-Funktion: duplizieren statt neu aufsetzen

Der wertvollste Befehl ist nicht „erstelle eine neue VM", sondern „dupliziere diese hier". Der Grund ist banal und entscheidend zugleich: Eine bekannte, funktionierende Maschine zu klonen ist der sicherste Weg, sofort ein lauffähiges System zu bekommen. SSH-Keys, Passwörter, installierte Pakete, Konfiguration — alles bleibt 1:1 erhalten. Es ändern sich nur Hostname und IP.

Der technische Kniff dahinter ist ein Full-Clone, kein Linked-Clone: Die Kopie ist vollständig unabhängig vom Original. Läuft der Quell-Container gerade, wird zuerst ein Snapshot gezogen und daraus geklont, damit der Betrieb ungestört bleibt. Danach werden nur die Netzwerk-Parameter neu geschrieben und die Maschine gestartet. Weil die Provisionierung wegfällt, entfallen auch ihre klassischen Fehlerquellen — kein „Passwort vergessen", kein „Key nicht hinterlegt", kein halb konfiguriertes System.

Lektion 1: Sicherheit — Profile statt Vollzugriff

Ein Sprachmodell, das direkt an einer Infrastruktur-API hängt, ist mächtig — und genau deshalb gefährlich. Die naive Umsetzung gibt dem Agenten alle Tools und dem Token alle Rechte. Das ist die Einladung zum Unfall.

Wir arbeiten stattdessen mit Berechtigungsprofilen:

Das Standardprofil ist operator. Destruktive Werkzeuge — löschen, zerstören, zurückrollen, Backups löschen — sind darin gar nicht erst sichtbar. Sie tauchen selbst dann nicht auf, wenn das Modell explizit danach sucht. Erst im Profil full werden sie freigeschaltet, und dort verlangt ein separates Bestätigungs-Gate einen ausdrücklichen confirm-Parameter, bevor irgendetwas Unwiderrufliches passiert.

Die zweite Verteidigungslinie liegt außerhalb des Modells: Das API-Token bekommt nur die Rechte, die der Anwendungsfall braucht. Ein Token, das klonen und Snapshots anlegen darf, aber weder eine Shell im Gast öffnen noch Knoten-Einstellungen ändern kann, richtet selbst bei einem kompromittierten Prompt kaum Schaden an. Least Privilege ist kein Bürokratie-Ritual — es ist die Schicht, die auch dann noch trägt, wenn die erste versagt.

Lektion 2: Skalierung — semantisches Tool-Routing

Ein vollständiger Infrastruktur-MCP hat schnell fast 300 Werkzeuge. Hängt man die alle gleichzeitig an das Modell, passiert zweierlei: Der Kontext quillt über, und die Trefferquote sinkt — das Modell verliert sich in Varianten und ruft das falsche Tool auf.

Die Lösung ist ein Routing über Embeddings. Statt 300 Definitionen sieht das Modell nur drei Meta-Werkzeuge:

• route_tools — beschreibe in natürlicher Sprache, was du tun willst, und bekomme die passenden Tools zurück
• call_routed_tool — rufe ein gefundenes Tool mit Argumenten auf
• proxmox_api_raw — Notausgang für alles, was kein spezifisches Tool hat

Beim Start bettet ein kleines, CPU-schnelles Modell (bge-small via fastembed) jede Tool-Beschreibung in einen Vektor ein. Eine Anfrage wie „LXC-Container auf einem Knoten auflisten" wird ebenfalls eingebettet, und per Kosinus-Ähnlichkeit fallen in Millisekunden die relevanten Werkzeuge heraus. Das Modell arbeitet mit einer Handvoll passender Tools statt mit einem unübersichtlichen Katalog — schneller, günstiger, treffsicherer.

Ein Detail, das wir teuer gelernt haben: Das Routing muss so gebaut sein, dass ein Aufruf auch dann funktioniert, wenn das Modell die Suche übersprungen hat. Ein Werkzeug, das nur nach einem exakten, unmittelbar vorangegangenen Suchlauf aufrufbar ist, produziert genau die verwirrenden „Tool nicht gefunden"-Schleifen, die man vermeiden wollte.

Lektion 3: Zuverlässigkeit — die Verbindung, die stirbt

Die dritte Lektion ist die unspektakulärste und zugleich die wichtigste: Die Demo scheitert nie am Happy Path — sie scheitert an den Fehlerfällen.

Chat-Plattformen halten pro Nutzer eine eigene Verbindung zu jedem MCP-Backend. Solange das Backend läuft, ist alles gut. Startet man das Backend aber neu — etwa nach einem Update — verliert diese Verbindung ihre Sitzung. Viele Clients versuchen dann zwei-, dreimal einen Reconnect, geben auf und hinterlassen eine Zombie-Verbindung: technisch verbunden, aber ohne einen einzigen Werkzeug-Eintrag. Der Agent meldet dann „Tool nicht verfügbar" — obwohl Server und Code völlig gesund sind.

Der Fehler liegt nicht im Code, sondern im Verbindungs-Lebenszyklus. Die passende Antwort ist deshalb operativ, nicht programmatisch: ein selbstheilender Wächter. Ein kleiner Dienst beobachtet das Log der Chat-Plattform und reagiert auf genau die Zeile, die den Zombie-Zustand markiert. Sobald sie auftaucht, stößt er automatisch eine saubere Neu-Initialisierung an — Verbindung trennen, frisch aufbauen, Tools neu laden. In unseren Tests war die Verbindung nach einem Backend-Neustart binnen zwei Sekunden ohne jedes Zutun wieder da.

Das ist die eigentliche Reifeprüfung eines Agentensystems: nicht, ob es im besten Fall funktioniert, sondern ob es sich nach einem Neustart, einem Timeout oder einem Netzwerk-Aussetzer selbst wieder einfängt.

Was man mitnimmt

• Duplizieren schlägt Provisionieren. Ein Full-Clone einer bekannten Maschine ist der sicherste Weg zu einem sofort lauffähigen System.
• Sicherheit in Schichten. Berechtigungsprofile im Server, ein Bestätigungs-Gate für Destruktives und ein Token mit minimalen Rechten — jede Schicht fängt ab, was die vorige durchlässt.
• Weniger ist mehr am Kontext. Semantisches Routing kollabiert Hunderte Tools auf drei und macht das Modell schneller und treffsicherer.
• Der Fehlerfall ist das Produkt. Selbstheilung nach Neustarts ist kein Bonus, sondern die Bedingung dafür, dass ein Agent im Alltag verlässlich bleibt.

Wer diese vier Punkte ernst nimmt, kommt von der beeindruckenden Demo zu einem Werkzeug, dem man tatsächlich die eigene Infrastruktur anvertraut. Genau dort liegt die Grenze zwischen Spielzeug und Betriebsmittel.