Nach der Bestellung: Wie ein KI-Agent seinen VPS per MCP selbst betreibt

Die meisten Demos, in denen ein Agent einen Server kauft, enden im Moment der Bestellung. Das ist der langweiligste Moment. Der Server existiert, der Agent hat eine ID wie 47HZ7YF, und niemand hat gesagt, was danach passiert.

Danach kommt alles, was ein Admin ohne nachzudenken tut: warten, bis SSH wirklich antwortet, das Passwort finden, bemerken, dass die Platte vollläuft, nach einem Kernel-Update neu starten, verlängern, bevor der Monat um ist, den Support fragen, wenn etwas seltsam aussieht. Wenn ein Agent Infrastruktur besitzen soll, muss er auch diesen Teil übernehmen. So sieht das über unseren MCP-Server aus. Jeden Schritt haben wir in unserer Testumgebung durchgespielt, bevor wir ihn aufgeschrieben haben.

Falls Sie noch keinen Client verbunden haben, beginnen Sie mit Claude Code und Codex oder Claude Desktop und Cursor.

Minute eins: „active“ heißt nicht „bereit“

order_vps antwortet, sobald die Bestellung aus dem Guthaben bezahlt ist. Der Server wird im Hintergrund erstellt, meist in etwa einer Minute. Der nächste Aufruf des Agenten ist get_vps_status, und er sollte ihn wiederholen: Das Tool liest nur und darf beliebig oft abgefragt werden.

Zwei Felder zählen. status wird active, sobald die Maschine existiert. In access steht, was der Agent zum Anmelden braucht: Host, Port und ein fertiger SSH-Befehl. Bei Tarifen mit eigener IPv4 ist der Port 22. Bei NAT-Tarifen ist es ein persönlicher weitergeleiteter Port, und die Antwort sagt das ausdrücklich, samt Warnung, sich nicht mit einer Firewall auszusperren, die nur den äußeren Port erlaubt.

Zwischen diesen beiden Momenten liegt eine Lücke, über die man stolpert. Der erste Start installiert OS-Updates, das kann einige Minuten dauern, und SSH kann in dieser Zeit Verbindungen ablehnen. Ein umsichtiger Agent wartet auf access.ssh_ready, statt auf Port 22 einzuhämmern.

Wurde ohne SSH-Schlüssel bestellt, wartet das Root-Passwort. reveal_password gibt es genau einmal heraus und erst, wenn die VM fertig gebootet hat. Wer zu früh fragt, bekommt password_pending, ohne die einmalige Anzeige zu verbrauchen. Wir haben das so gebaut, nachdem Agenten immer wieder ein Passwort abholten, das die noch bootende VM nicht übernommen hatte. Ehrlich gesagt: Geben Sie bei der Bestellung einen ssh_key mit und sparen Sie sich diesen Schritt.

Tag zwei: im Blick behalten

get_vps_metrics liefert CPU, Speicher, Netzwerk und Platte als Zeitreihen für die letzte Stunde, den Tag, die Woche oder den Monat. Ein Agent, der einmal am Tag hineinschaut, erkennt das Muster, das kleine Server umbringt: Der Speicher kriecht nach oben, bis der OOM-Killer ein Opfer wählt. Von außen kann er die Ursache nicht beheben, aber er kann es Ihnen sagen oder sich per SSH anmelden und nachsehen.

power_vps kann start, stop und reboot. Ein Detail aus den Tests: Ist der Server nicht aktiv (wird noch erstellt oder ist wegen unbezahlter Verlängerung gesperrt), antwortet das Tool mit 409 und dem Hinweis, zuerst den Status zu prüfen. Ein Agent, der jedes Nicht-200 endlos wiederholt, dreht sich hier im Kreis. Die Fehlermeldung sagt ihm, was stattdessen zu tun ist, denn unsere Fehlertexte sind für Agenten genauso geschrieben wie für Menschen.

set_hostname benennt die Maschine über den Gast-Agenten in ihr um, unter Linux also ohne Neustart. Entfernen Sie qemu-guest-agent, und das Tool funktioniert nicht mehr: Es meldet agent_unavailable und ändert nichts.

Tag dreißig: Geld

Hier stirbt agenteneigene Infrastruktur meistens. Die Verlängerung steht in jemandes Kalender, dieser Jemand ist beschäftigt, der Server wird gesperrt.

Bei uns hängt die Verlängerung nicht vom Gedächtnis des Agenten ab. Jeder Server verlängert sich monatlich aus dem vorausbezahlten Guthaben, und die Konto-E-Mail bekommt vor dem Termin Erinnerungen. Der Agent muss nur das Guthaben über der nächsten Abbuchung halten, und get_balance zeigt ihm, wie es steht.

Eine Schonfrist gibt es nicht: Reicht das Guthaben am Ende der Laufzeit nicht für die Verlängerung, wird der Server gesperrt und seine dedizierte IP geht zurück in den Pool.

Ist das Guthaben knapp, erzeugt topup_balance einen Krypto-Checkout-Link: USDT, USDC oder ETH auf Base, Ethereum oder Polygon. Das ist die erste Stelle, an der der Agent Sie braucht. Die Rechnung kann er erzeugen; eine Transaktion signieren kann er nur, wenn Sie ihm eine Wallet geben, und das würden wir uns gut überlegen. In der Praxis lädt man einmal für mehrere Monate auf und lässt den Agenten davon ausgeben. Blieb eine Bestellung oder Rechnung unbezahlt, weil das Guthaben nicht reichte, ruft der Agent nach Ihrer Aufladung pay_invoice auf, und sie wird aus dem Guthaben bezahlt.

Eine ehrliche Lücke: Die MCP-Tools verlängern einen Server nicht auf Zuruf mehrere Monate im Voraus. Die monatliche Verlängerung läuft automatisch, und 3, 6 oder 12 Monate im Voraus bezahlt man im Dashboard oder mit einem REST-Aufruf. Wer von Anfang an eine längere Laufzeit will: order_vps nimmt bei der Bestellung months von 1 bis 36 an.

Wachstum decken get_upgrade_options und change_plan ab. Der Tarif wechselt an Ort und Stelle, Dateien und OS bleiben, der Server startet einmal neu, und die Preisdifferenz für den Rest der Laufzeit wird vom Guthaben abgezogen. Der Agent muss confirm: true übergeben – unsere Art zu sagen: „Du gibst Geld aus, sei dir sicher.“

Wenn etwas schiefgeht

Destruktive Aktionen sind absichtlich umständlich. reinstall_vps und ein sofortiges cancel_service verlangen beide den exakten Hostnamen als confirm, und ihre Beschreibungen sagen dem Agenten, vorher einen Menschen zu fragen. Das ist die zweite Stelle, an der der Agent Sie braucht, und das ist gewollt.

Die sichere Kündigung, end_of_period, lässt den Server bis zum Ende der bezahlten Zeit laufen. undo_cancel nimmt sie zurück, und das ist wichtiger, als man denkt: Agenten ändern ihre Meinung mitten in einer Aufgabe genauso oft wie Menschen.

Steckt der Agent fest, eröffnet create_ticket ein Ticket zum Server, und reply_ticket setzt den Verlauf fort. Gelesen wird es von einem Menschen auf unserer Seite, nicht von einem Chatbot, der einem Chatbot antwortet.

Und wenn ein Mensch eingreifen muss, lädt delegate_service ihn per E-Mail als Operator genau dieses Servers ein. Er bekommt Strom, Konsole, Neuinstallation und Hostname. Abrechnung, Verlängerung und Kündigung bekommt er nicht, und das Token des Agenten sieht er nie.

Was der Agent weiterhin nicht kann

Damit keine Illusionen entstehen:

• Das Guthaben aufladen. Eine Aufladungsrechnung kann er erstellen und Rechnungen mit pay_invoice aus dem Guthaben bezahlen. Krypto aufs Guthaben bringen kann nur eine Wallet, also in der Regel Sie.
• Per MCP im Betriebssystem arbeiten. Pakete, Konfiguration und Deployments laufen über SSH. MCP verwaltet die Maschine von außen.
• Eine Sperre selbst aufheben. Ist ein Server wegen Missbrauchs gesperrt, ist das ein Gespräch mit einem Menschen, und so soll es sein.

Das macht die Tools nicht weniger nützlich. Es heißt nur, dass Sie die Schleife des Agenten um sie herum bauen sollten: Status abfragen, das Guthaben im Rahmen halten, per Ticket eskalieren und bei allem, was Daten löscht, auf Sie warten.

Ist die Arbeit des Agenten kurzlebig, ist ein ganzer Server vielleicht die falsche Einheit. VPS oder Sandbox? erklärt, wann eine microVM, die eine Minute lebt, besser passt. Ansonsten finden Sie die Tarife hier, und die MCP-Referenz listet jedes Tool mit seinen Parametern.