Netdata bringt seit Version 2.6 einen eigenen MCP-Server mit — ganz ohne Zusatzinstallation. Wer eine kleine Infrastruktur mit ein paar Nodes betreibt, hat in gut 15 Minuten ein vollständiges Monitoring mit Hunderten Metriken pro Sekunde, plus einen KI-Assistenten, der die Daten tatsächlich versteht: Claude fragt "Warum ist der Server langsam?" nicht mehr rhetorisch, sondern zieht sich die echten Zahlen. Installation, erste Ansicht, MCP-Anbindung, eine Beispielfrage — und ein Hinweis, worauf zu achten ist, sobald man das Ganze von außerhalb des eigenen Netzes erreichbar machen will.
Netdata installieren, das Dashboard einmal ansehen, Claude als MCP-Client anschließen. Fertig. Kein Cloud-Konto nötig, keine Konfigurationsdatei, die erst verstanden werden muss.
Netdatas eigene Oberfläche ist absichtlich umfangreich: Hunderte Metriken, Dutzende Ansichten, für tiefe Analyse die richtige Wahl. Für den täglichen Blick reicht das oft zu viel. Das folgende Dashboard hat Claude für diesen Fall gebaut, als eigenes, schlankes Layout. Es fasst die wichtigsten Zahlen aus Netdata auf einen Blick zusammen, ohne Umweg durch die volle Netdata-Oberfläche.
Für die meisten kleinen Infrastrukturen (ein Server, ein NAS, ein paar Raspberry Pis, vielleicht eine Handvoll Container) ist professionelles Monitoring bisher an zwei Dingen gescheitert. Entweder brauchte es eine eigene Prometheus/Grafana-Installation, für die am Wochenende die Zeit fehlt. Oder es war eine der leichteren Lösungen, die dann doch nur eine Handvoll Kennzahlen zeigen. Netdata liegt dazwischen und bringt seit Kurzem etwas mit, das den Unterschied macht: einen eingebauten MCP-Server. Über ihn kann ein KI-Assistent wie Claude direkt auf die Live-Metriken zugreifen.
Installation: ein Befehl
Netdata hat ein offizielles Installationsskript, das auf so gut wie jeder gängigen Linux-Distribution funktioniert (Debian, Ubuntu, Raspberry Pi OS, Fedora, Arch, auch auf ARM, also problemlos auf einem Raspberry Pi):
curl -Ss https://get.netdata.cloud/kickstart.sh | bash
Das Skript erkennt die Distribution selbst, installiert die passenden Pakete und startet den Netdata-Dienst direkt im Anschluss. Nach ein bis zwei Minuten ist das Dashboard erreichbar:
http://<deine-server-ip>:19999
Dabei ist kein Login und kein Cloud-Konto nötig. Das Dashboard funktioniert vollständig lokal. Es zeigt sofort an, was gerade passiert: CPU pro Kern, Arbeitsspeicher, Netzwerkdurchsatz, Festplatten-I/O, laufende Prozesse. Bei den meisten Distributionen werden automatisch auch Docker-Container, laufende Datenbanken oder Webserver erkannt, falls welche installiert sind.
Die erste Ansicht
Das Dashboard sammelt ab der ersten Sekunde und aktualisiert sich laufend, pro Sekunde. Die meisten klassischen Lösungen arbeiten mit Intervallen von fünf Minuten. Den Unterschied merkt man sofort, wenn ein kurzer CPU-Spike auftaucht: Er ist als einzelner Zacken sichtbar. Eine geglättete Linie, die den eigentlichen Moment verschluckt, gibt es hier nicht.
Netdata bringt außerdem von Haus aus rund 300 vordefinierte Alarme mit: Festplatte fast voll, Swap-Nutzung zu hoch, ein Dienst nicht erreichbar, und so weiter. Die muss man nicht selbst konfigurieren; sie laufen von Anfang an mit und tauchen im Reiter „Alerts" auf, sobald einer davon anschlägt.
Claude als MCP-Client anschließen
Das ist der Teil, der den Unterschied macht. Ab Netdata Agent Version 2.6.0 läuft automatisch ein MCP-Server mit — ohne jede Zusatzinstallation, ohne eigenen Prozess, ohne Konfigurationsdatei. Erreichbar ist er unter:
http://<deine-server-ip>:19999/mcp
In Claude Desktop (oder Claude Code) trägt man diesen Endpunkt als benutzerdefinierten Connector ein:
- Einstellungen → Connectors → Benutzerdefinierten Connector hinzufügen
- URL:
http://<deine-server-ip>:19999/mcp - Authentifizierung: Keine Anmeldung — solange Claude im selben Netz läuft wie der Server, ist kein zusätzliches Passwort nötig
Nach dem Verbinden stehen Claude gut ein Dutzend Werkzeuge zur Verfügung: Metriken durchsuchen, Anomalien der letzten Stunden finden, Alarme auflisten, Knoten-Details abrufen, laufende Prozesse einsehen. Alles live, alles echte Daten vom eigenen Server.
Eine Beispielfrage
Statt selbst durchs Dashboard zu klicken, kann man jetzt einfach fragen:
„Warum war mein Server heute Nachmittag zwischen 14 und 16 Uhr langsam?"
Claude sucht sich über die MCP-Werkzeuge selbstständig zusammen, welche Metriken in diesem Zeitraum ungewöhnlich waren, ob es einen CPU- oder Speicher-Ausreißer gab, und ob ein Alarm ausgelöst wurde — und antwortet mit der tatsächlichen Ursache statt mit einer allgemeinen Vermutung. Das Dashboard bleibt trotzdem da — für den Blick aufs große Bild ist die grafische Ansicht weiterhin die bessere Wahl, für die gezielte Nachfrage danach ist der MCP-Server der schnellere Weg.
Wenn's über das eigene Netz hinausgehen soll
Für eine kleine Infrastruktur mit Claude auf demselben Rechner oder im selben WLAN reicht das oben Beschriebene komplett aus. Sobald der MCP-Server aber von claude.ai oder der Claude-Desktop-App aus erreichbar sein soll, ändert sich eine Sache grundlegend: Der Verbindungsversuch kommt dann nicht mehr vom eigenen Gerät. Er kommt aus der Cloud-Infrastruktur von Anthropic. Eine Adresse, die nur im eigenen (V)LAN oder VPN erreichbar ist, funktioniert von dort aus nicht, egal wie korrekt sie sonst konfiguriert ist. Für diesen Fall braucht es einen öffentlich erreichbaren HTTPS-Endpunkt. Außerdem muss ein echter Zugriffsschutz (Token oder OAuth) davorstehen. Das sprengt für unter fünf Nodes den Rahmen dieses Artikels. Hier muss man aber aufpassen. Sonst wundert man sich, warum die Verbindung "einfach nicht geht", obwohl lokal alles funktioniert.
Vom Lesen zum Handeln: ein eigener MCP-Server mit Schreibzugriff mit MFA
PowerShell usw.
Netdatas eingebauter MCP-Server ist bewusst nur lesend — Claude kann Metriken abfragen, aber nichts am System verändern, und das soll auch so bleiben: Lesen und Handeln sind zwei völlig unterschiedliche Risikostufen, die Netdata absichtlich trennt. Der Rest dieses Abschnitts war entsprechend zunächst nur ein Fahrplan, keine fertige Lösung — das war Phase 1. Inzwischen ist daraus ein echter, laufender, schreibfähiger MCP-Server mit eigenen Tools geworden, MFA inklusive: Teil II dieser Reihe zeigt ihn in Betrieb.
Für den Wunschtraum vieler Betreiber kleiner Infrastrukturen reicht das rein lesende Netdata-Tool allerdings nicht. Die Idee dahinter: „Sag mir per Sprachbefehl, ob das Backup heute Nacht geklappt hat, und wenn nicht, stoß es neu an." Das will man, während man im Auto sitzt und keine Hand frei hat, um selbst nachzuschauen.
Wer wirklich handeln lassen will — einen Dienst neu starten, ein Backup-Skript anstoßen, einen Alarm quittieren —, braucht dafür einen eigenen, zusätzlichen MCP-Server, den man selbst baut und selbst absichert. Grober Fahrplan, wie das in der Praxis aussieht (Stand vor Teil II):
- Eigene Tools statt Netdata-Tools: ein kleiner, selbst geschriebener MCP-Server (z. B. mit dem offiziellen Python- oder TypeScript-SDK) mit gezielten, benannten Funktionen wie
backup_jetzt_starten()oderdienst_neu_starten(name)— keine generische „Shell-Befehl ausführen"-Funktion, die alles und damit auch zu viel könnte. - Echte Authentifizierung, nicht nur ein Token: sobald ein Werkzeug etwas verändert, reicht „im selben Netz" als Zugriffsschutz nicht mehr. OAuth mit einem echten Identitätsanbieter (Microsoft Entra ID, Google, Authentik o. Ä.) plus Multi-Faktor-Anmeldung ist hier die Grundvoraussetzung, kein optionales Extra.
- Bestätigung vor Ausführung bei heiklen Aktionen: ein Neustart oder ein Backup-Anstoß sollte einen expliziten Bestätigungsschritt verlangen (Claude fragt zurück, bevor es ausführt), statt beim ersten Missverständnis gleich zu handeln — gerade bei einer Sprachanfrage im Auto, wo Spracherkennungsfehler realistisch sind.
- Ein Protokoll, das mitschreibt: jede ausgeführte Aktion landet mit Zeitstempel in einem eigenen Audit-Log — nicht, weil man niemandem vertraut, sondern weil man hinterher genau nachvollziehen können muss, was wann warum passiert ist.
Das ist mehr Aufwand als Netdatas eingebauter Read-only-Server — aber genau der Aufwand, der den Unterschied ausmacht zwischen „ich kann meine Daten abfragen" und „ich kann von unterwegs auch per Voice Steuerung eingreifen.
Zusammengefasst
Ein Installationsbefehl, zwei Minuten Wartezeit, ein Connector-Eintrag in Claude. Fertig. Eine kleine Infrastruktur mit weniger als fünf Nodes hat damit ein vollständiges, sekundengenaues Monitoring samt KI-Assistent. Einem Assistenten, der die eigenen Metriken versteht. Kein Grafana-Stack, kein Yaml, kein Cloud-Zwang.
Recherche und Entwurf KI-gestützt, geprüft und freigegeben von Andreas Brauckmann · So arbeitet die Redaktion
Änderungshistorie
- — Sprache professionalisiert ("Homelab" → "kleine Infrastruktur"), Abschnitt zum schreibfähigen MCP-Server wieder hervorgehoben, Verweis auf Teil II ergänzt.
- — Quadratisches Vorschaubild für die Startseite ergänzt.
- — Artikel veröffentlicht.