Praxis & Anwendung
Wie ich Claude direkt mit meinem Server verbunden habe — und was dann passierte
Ein MCP-Server auf einem Hetzner-VPS: von der Idee über den Crash bis zur funktionierenden Lösung
Was passiert, wenn man einen KI-Assistenten direkt mit dem eigenen Webserver verbindet? Ein Erfahrungsbericht über MCP, Bot-Stürme und die Frage, warum Authentifizierung keine optionale Zutat ist.
Ausgangslage
Für die Arbeit an qzen.ch nutze ich mehrere Tools parallel: VS Code mit Claude-Chat, Claude-Code und CLaude-CLI im Terminal für Server-Arbeit per SSH, das Claude Web-Interface für Strategie und Analyse, Claude Code und Claude-CLI für lokale Automation. Drei Tools, die jeweils nur einen Teil der Arbeit abdecken.
Die Frage war: Geht das einfacher? Kann Claude direkt auf den Server zugreifen — ohne Editor als Mittelsmann?
Die Idee: MCP als Brücke
Das Model Context Protocol (MCP) ist ein offener Standard, der KI-Assistenten mit externen Datenquellen verbindet. Claude unterstützt seit kurzem Custom Connectors — also die Möglichkeit, eigene MCP-Server im Web-Interface einzubinden.
Der Plan: Einen MCP-Server auf dem Webserver installieren, der Dateizugriff und Shell-Befehle bereitstellt. Claude bekommt damit direkten Zugriff auf das Kirby CMS — Dateien lesen, schreiben, Verzeichnisse listen, Befehle ausführen. Von jedem Gerät mit Browser oder Claude App, ohne SSH-Client, ohne Editor.
Umsetzung in einer Stunde
Die technische Umsetzung war überraschend kompakt:
- FastMCP (Python) als Server-Framework — wenige Dutzend Zeilen Code für sechs Tools: read_file, write_file, list_directory, delete_file, move_file, run_command
- systemd Service für automatischen Start
- nginx als Reverse Proxy mit TLS (Let’s Encrypt)
- Subdomain mcp.qzen.ch als Endpunkt
URL im Claude Web-Interface eintragen, verbinden, fertig. Claude konnte sofort Dateien auf dem Server lesen und die Verzeichnisstruktur anzeigen.
Dann wurde es interessant
Was ich nicht bedacht hatte: Ein öffentlich erreichbarer HTTP-Endpoint wird nicht erst nach Tagen entdeckt. Sondern nach Sekunden.
Was passierte
Innerhalb von etwa ca. 40 Secunden nach dem DNS-Eintrag begannen die ersten Scanner-Anfragen. Censys, Shodan und diverse Bot-Netzwerke hatten die neue Subdomain gefunden — über Certificate Transparency Logs. Das sind öffentlich einsehbare Verzeichnisse, in denen jedes TLS-Zertifikat registriert wird — eine Sicherheitsmaßnahme gegen Fälschungen. Aber diese Transparenz hat eine Kehrseite: Bot-Netzwerke überwachen diese Logs in Echtzeit wie eine Horde, die auf frische Beute wartet. Sobald ein neues Zertifikat auftaucht, kennen sie die Adresse — oft bevor der erste echte Besucher sie je gesehen hat.
Um 14:33 Uhr traf die erste koordinierte Welle ein: rund 30 gleichzeitige Anfragen in 20 Sekunden, von drei verschiedenen IPs eines einzelnen Scanning-Dienstes. Danach kamen weitere Bots dazu.
Die Auswirkung
Der kleine VPS ging in die Knie. CPU auf 150% (beide Kerne am Anschlag), Festplatten-Durchsatz über 1 GBps. SSH war nicht mehr erreichbar. Das Kirby-Panel reagierte nicht mehr. Selbst das Frontend wurde zur Geduldsprobe.
Die Lösung: DNS-Eintrag löschen und den Server über die Hetzner-Konsole neu starten. Danach normalisierte sich alles innerhalb von Minuten.
Die Lektion
Der MCP-Server war ohne Authentifizierung konfiguriert — authless, wie es die Beta-Dokumentation als einfachsten Einstieg vorschlägt. Technisch funktionierte alles. Sicherheitstechnisch war es eine Katastrophe.
Die eigentliche Erkenntnis ist nicht “man braucht Authentifizierung” — das wissen die meisten. Die Erkenntnis ist, wie brutal schnell ein ungeschützter Endpoint gefunden und belastet wird. Nicht nach Stunden. Nach Sekunden.
Das erinnert an eine Erfahrung aus einer anderen Ära: Windows 7 frisch installiert, ans Netz gehängt um Updates zu laden — und innerhalb kurzer Zeit mit Würmern infiziert. Das Muster ist identisch, nur die Angriffsvektoren haben sich geändert.
Die Reparatur
Zweiter Anlauf mit OAuth-Authentifizierung über GitHub. FastMCP bringt einen fertigen GitHub-Provider mit. Der Flow:
- Claude Web-Interface fragt Zugriff an
- Weiterleitung zu GitHub Login
- Token wird ausgestellt und persistent gespeichert
- Bots bekommen statt Dateizugriff eine OAuth-Hürde
Zusätzlich: Cloudflare Proxy aktiviert (echte Server-IP versteckt, Bot-Protection aktiv).
Ergebnis: Der Connector funktioniert. Claude kann Dateien lesen und schreiben, Verzeichnisse listen, Shell-Befehle ausführen. Bots prallen ab.
Was damit möglich ist
Die Verbindung ist mehr als nur Dateizugriff. Ein paar Beispiele aus der ersten Stunde produktiver Nutzung:
- Content-Bereinigung: Eine 36KB Kirby-Seite mit obsoleten Inhalten auf 4KB reduziert — direkt aus dem Chat heraus, mit Backup vorher
- Echtzeit-Notizbuch: Ein Session-Log auf dem Server, das Claude bei jeder Arbeitssitzung liest und aktualisiert. VS Code zeigt die Änderungen live an
- Server-Dokumentation lesen: Das Development-Log direkt vom Server abrufen, ohne es manuell hochzuladen
Das Besondere: Alles geräteunabhängig. Browser öffnen, Chat starten, arbeiten. Vom MacBook, vom iPhone, theoretisch aus dem Internetcafé.
Fazit
Die technische Hürde für einen eigenen MCP-Server ist niedrig. Python, ein paar Zeilen Code, ein systemd-Service. Die Erkenntnis aus diesem Experiment: Sicherheit ist nicht optional, sondern ein Muss. Außer man will mal sehen, wie Bot-Horden einen Server im Nu zum Liegen bringen.
Für Jeden, der daüber nachdenkt sowas zu implementieren, also “schnell mal KI einbinden”, ist diese Geschichte eine Warnung und eine Einladung zugleich: Es funktioniert, es ist ein Tool das ungeahnte Möglichkeiten eröffnet, aber man sollte wissen was man tut. Wie auch beim Autofahren gibt es hier Regel die der Sicherheit dienen.
Dieser Beitrag basiert auf einer realen Arbeitssitzung vom 14. März 2026. Die Cloudflare-Statistiken und Hetzner-Monitoring-Graphen sind echt. Der MCP-Server läuft produktiv.
Wie dieser Workflow in der Praxis aussieht — vom Tippfehler bis zur redaktionellen Grundsatzentscheidung, alles aus dem Chat heraus — zeigt der nächste Beitrag: Lektorat per Chat.