Linux MCP Server

Der Linux MCP Server verbindet KI-Assistenten wie Claude Code, Cursor oder Claude Desktop mit Linux-Systemen, damit sie dort Fehler eingrenzen können. Statt Befehle einzeln zu tippen und die Ausgabe von Hand in den Chat zu kopieren, fragen Sie den Assistenten etwa: „Warum ist der Webserver auf diesem Host langsam?“ oder „Welche Dienste sind fehlgeschlagen?“. Der Assistent ruft dann Werkzeuge des Servers auf, liest Systeminformationen, Dienststatus, Prozesse, Logs, Netzwerk und Speicher und fasst die Befunde zusammen. Das Projekt gehört zu rhel-lightspeed von Red Hat und steht laut Repository unter der Apache-2.0-Lizenz.

Was ist der Linux MCP Server?

MCP, das Model Context Protocol, ist ein offenes Protokoll, mit dem KI-Assistenten Werkzeuge externer Dienste aufrufen. Der Linux MCP Server ist ein solcher Dienst für die Systemadministration. Laut Projektseite und Paketbeschreibung ist er auf lesende Diagnose und Fehlersuche ausgelegt und für Red Hat Enterprise Linux, Fedora, CentOS Stream und andere systemd-basierte Distributionen gedacht. Red Hat führt ihn in den Release Notes zu RHEL 9.8 als Developer Preview, also als Vorschau ohne den vollen Supportumfang eines regulären Produktmerkmals. Wer ihn produktiv einsetzt, sollte das wissen.

Welche Werkzeuge gibt es?

Die Dokumentation gliedert die Werkzeuge in Bereiche: Systeminformationen, Dienste, Prozesse, Logs, Netzwerk, Speicher, Performance Co-Pilot und Skriptausführung. Damit lassen sich zum Beispiel Systemzustand und Hardware ansehen, Dienste und Prozesse prüfen, Journal- und Logdateien lesen, Netzwerkverbindungen anschauen und Speicherbelegung auswerten. Über Performance Co-Pilot sind Leistungsdaten erreichbar. Mehrere Hosts können in einer Sitzung angesprochen werden, sodass sich ein Problem über mehrere Server hinweg vergleichen lässt.

Wofür ist er besonders nützlich?

Der größte Nutzen liegt in der Störungsanalyse. Wer Linux-Server betreut, kennt das Muster: Ein Dienst startet nicht, die Ursache steht irgendwo im Journal, und der Weg dorthin führt über mehrere Befehle. Der Assistent übernimmt diese Abfolge, kennt die gängigen Fehlerbilder und erklärt, was er sieht. Gegenüber einer allgemeinen Shell-Anbindung ist der Zugriff enger zugeschnitten, weil die Standardwerkzeuge laut Dokumentation nur lesen. Das macht den Einsatz auf Produktivsystemen überschaubarer, ersetzt aber keine Prüfung der Rechte des verwendeten Kontos.

Einrichtung

Voraussetzung ist ein Python-Werkzeug-Manager: Laut Projektseite installieren Sie zunächst uv und dann den Server mit uv tool install linux-mcp-server. Danach tragen Sie ihn in der MCP-Konfiguration Ihres Clients ein, bei Claude Code in ~/.claude.json, bei Cursor in ~/.cursor/mcp.json. Als Befehl dient der Pfad zum installierten Programm, als Umgebungsvariable zum Beispiel LINUX_MCP_USER für den SSH-Benutzer. Alternativ gibt es laut Dokumentation ein Container-Image für Podman oder Docker. Verbindungen zu entfernten Hosts laufen über SSH mit Schlüsselauthentifizierung, Passwörter sind nicht vorgesehen.

Sicherheit und Grenzen

Der Server handelt mit den Rechten des SSH-Kontos auf dem Zielsystem; verwenden Sie deshalb ein Konto mit möglichst wenigen Rechten. Der Zugriff auf Logdateien wird über die Umgebungsvariable LINUX_MCP_ALLOWED_LOG_PATHS auf eine Liste erlaubter Pfade begrenzt, ohne diese Variable kann das Werkzeug keine Dateien lesen. Die Prüfung der Host-Schlüssel ist standardmäßig aktiv und sollte es bleiben. Die Dokumentation warnt, dass der HTTP-Transport keine Authentifizierung bietet und nicht in Produktion oder in unsicheren Netzen laufen sollte; der Standard ist stdio. Das Werkzeugset zur Skriptausführung ist abweichend vom lesenden Standard und wird nur mit der Startoption --toolset run-script oder --toolset both aktiviert. Es kann laut Dokumentation den Systemzustand ändern und nutzt eine Validierung sowie eine Bestätigung. Lassen Sie es ausgeschaltet, wenn Sie nur diagnostizieren wollen. Was Logs und Befehlsausgaben enthalten, gelangt in den Kontext des KI-Clients und damit zum Modellanbieter; die Dokumentation beschreibt dazu keine eigene Datenhaltung.

Kosten

Das Projekt ist quelloffen und kostenlos nutzbar. Ob für die Nutzung mit RHEL eine Subscription nötig ist und welcher Supportumfang gilt, geht aus den abrufbaren Seiten nicht hervor; maßgeblich ist die Dokumentation von Red Hat. Kosten Ihres KI-Clients und des Modellanbieters kommen getrennt hinzu.

Für wen lohnt sich der Linux MCP Server?

Er lohnt sich für Administratorinnen, Administratoren und Entwicklungsteams, die Linux-Server betreiben und bei Störungen Zeit mit Logsuche verbringen. Wer ausschließlich Windows oder Container-Plattformen ohne SSH-Zugang betreibt, hat davon wenig. Wegen des Vorschaustatus eignet er sich zunächst für Test- und Entwicklungssysteme und für lesende Diagnose, bevor er in kritischen Umgebungen eingesetzt wird.

Python-Werkzeug-Manager uv (oder Container-Laufzeit), ein MCP-Client mit Unterstützung für lokale stdio-Server und für entfernte Hosts SSH-Zugang mit Schlüsselauthentifizierung.

Mit dem Linux MCP Server diagnostiziert ein KI-Assistent Linux-Systeme lesend: Dienste, Prozesse, Logs, Netzwerk und Speicher. Dieser Ratgeber führt von der Installation bis zur ersten Abfrage.

Schritt 1: Voraussetzungen prüfen

Sie benötigen den Python-Werkzeug-Manager uv, einen MCP-Client mit Unterstützung für lokale Server und für entfernte Hosts SSH-Zugang mit Schlüssel. Beachten Sie, dass Red Hat den Server als Developer Preview führt; nutzen Sie ihn zunächst auf Test- und Entwicklungssystemen.

Schritt 2: Installieren

Installieren Sie uv nach der Anleitung auf docs.astral.sh und danach den Server mit uv tool install linux-mcp-server. Der Befehl legt das Programm in der Regel unter ~/.local/bin/linux-mcp-server ab; diesen Pfad brauchen Sie gleich.

uv tool install linux-mcp-server

SSH vorbereiten

Verbindungen zu entfernten Hosts laufen über SSH mit Schlüssel, Passwörter sind nicht vorgesehen. Richten Sie einen Schlüssel ein und legen Sie in ~/.ssh/config fest, welche Hosts erreichbar sind. Lassen Sie die Prüfung der Host-Schlüssel eingeschaltet. Nehmen Sie ein Konto mit möglichst wenigen Rechten, denn der Server handelt mit dessen Berechtigungen.

Schritt 3: In Claude Code eintragen

Tragen Sie in ~/.claude.json unter mcpServers einen Eintrag linux-mcp-server ein: command ist der Pfad zum Programm, args bleibt leer, in env setzen Sie LINUX_MCP_USER auf Ihren SSH-Benutzernamen. Für Cursor gilt dieselbe Struktur in ~/.cursor/mcp.json, für Claude Desktop in der Datei claude_desktop_config.json; starten Sie Claude Desktop danach vollständig neu.

Logzugriff begrenzen

Setzen Sie in env die Variable LINUX_MCP_ALLOWED_LOG_PATHS, zum Beispiel auf /var/log/messages,/var/log/lastlog. Ohne diese Variable kann das Logwerkzeug laut Dokumentation keine Dateien lesen. Nennen Sie nur Pfade, die Sie wirklich brauchen.

Schritt 4: Erste Abfragen

Beginnen Sie lesend: „Zeige Systeminformationen von diesem Host.“, „Welche Dienste sind fehlgeschlagen?“ oder „Welche Prozesse verbrauchen am meisten Speicher?“. Nennen Sie den Host möglichst genau, wenn Sie mehrere konfiguriert haben.

Schritt 5: Skriptausführung bewusst entscheiden

Die Werkzeuge zur Skriptausführung sind standardmäßig aus und werden nur mit der Startoption --toolset run-script oder --toolset both aktiviert. Sie können laut Dokumentation den Systemzustand ändern. Lassen Sie sie ausgeschaltet, solange Sie nur diagnostizieren, und aktivieren Sie sie nur auf Systemen, auf denen Sie jede Bestätigung prüfen. Nutzen Sie den HTTP-Transport nicht in Produktion, er bietet keine Authentifizierung.

Passwortlose SSH-Schlüsselauthentifizierung gegenüber den Zielhosts; der Server selbst hat im Standardbetrieb (stdio) keine eigene Anmeldung. Der HTTP-Transport bietet laut Dokumentation keine Authentifizierung.

Lesender Zugriff auf Systeminformationen, Dienste, Prozesse, Logs (nur erlaubte Pfade), Netzwerk, Speicher und Performance-Daten im Rahmen der Rechte des SSH-Kontos; optional und nur auf Wunsch aktiviert: Skriptausführung, die das System ändern kann.

Der Server läuft lokal auf dem Rechner des Nutzers und verbindet sich per SSH mit den Zielsystemen. Ausgaben von Logs und Befehlen gelangen in den Kontext des KI-Clients und damit zum Modellanbieter. Eine eigene Datenhaltung beschreibt die Dokumentation nicht.

Zu weit gefasste Rechte des SSH-Kontos, Offenlegung sensibler Logs gegenüber dem Modellanbieter, ungeschützter HTTP-Transport, deaktivierte Host-Schlüsselprüfung und – falls aktiviert – Skriptausführung, die den Systemzustand verändern kann.