Filesystem MCP

Wofür Filesystem MCP gedacht ist

Filesystem MCP ist ein offizieller Referenzserver des Model-Context-Protocol-Projekts für lokale Dateioperationen. Gepflegt wird er im Repository modelcontextprotocol/servers; das npm-Paket heißt @modelcontextprotocol/server-filesystem. Sein Mehrwert liegt nicht darin, spektakuläre Spezialfunktionen zu liefern, sondern einen der wichtigsten Grundbausteine für KI-Agenten sauber zu kapseln: kontrollierten Zugriff auf Dateien und Verzeichnisse. Ein Agent kann damit Projektdateien lesen, mehrere Dateien vergleichen, neue Dateien anlegen, bestehende Texte gezielt bearbeiten, Verzeichnisbäume inspizieren und Metadaten abrufen, ohne dass der Nutzer jede einzelne Datei manuell in den Chat kopieren muss.

Funktionen und praktische Einsatzbereiche

Laut offizieller README unterstützt der Server unter anderem read_text_file, read_media_file, read_multiple_files, write_file, edit_file, create_directory, list_directory, directory_tree, move_file, search_files, get_file_info und list_allowed_directories. Diese Werkzeugliste macht Filesystem MCP besonders interessant für Coding-Agenten, technische Redaktion, Dokumentationspflege und lokale Wissensbasen. In einem Entwicklungsprojekt kann ein Assistent damit beispielsweise Konfigurationsdateien lesen, eine Dokumentation anpassen, Tests suchen oder kleine Refactorings vorbereiten. In redaktionellen Workflows kann derselbe Server lokale Markdown- oder Textbestände erschließen.

Die Stärke des Servers ist gleichzeitig seine größte Verantwortung: Er arbeitet auf dem lokalen Dateisystem. Dadurch ist er deutlich mächtiger als ein reines Suchwerkzeug, aber auch riskanter. Schreibwerkzeuge können Dateien erstellen, überschreiben, verschieben oder verändern. Für produktive Arbeit ist das nützlich, weil ein Agent nicht nur Vorschläge machen, sondern konkrete Änderungen vorbereiten kann. Für ungeprüfte Experimente oder Ordner mit sensiblen Daten sollte man ihn aber nicht breit freigeben.

Zugriffskontrolle über Verzeichnisse und Roots

Filesystem MCP begrenzt Zugriffe laut Dokumentation auf erlaubte Verzeichnisse. Diese können beim Start als Kommandozeilenargumente angegeben werden oder dynamisch über das MCP-Roots-Protokoll vom Client kommen. Unterstützt der Client Roots, kann er die erlaubten Verzeichnisse beim Verbindungsaufbau melden und später über roots/list_changed aktualisieren. Die vom Client gelieferten Roots ersetzen dabei die serverseitig gesetzten Verzeichnisse vollständig. Startet der Server ohne Argumente und liefert der Client keine Roots, bricht die Initialisierung laut README mit einem Fehler ab.

Für die Praxis ist das wichtig: Nicht das Home-Verzeichnis, nicht die gesamte Festplatte und schon gar nicht Ordner mit SSH-Schlüsseln, Browserprofilen oder Produktionskonfigurationen freigeben. Sinnvoll sind eng begrenzte Projektordner, idealerweise mit Versionskontrolle. Wer Docker nutzt, kann Mounts zusätzlich read-only setzen und so Schreiboperationen technisch einschränken. Das list_allowed_directories-Werkzeug hilft, die aktuell freigegebenen Pfade transparent zu prüfen.

Installation und Betrieb

Der typische Start erfolgt laut Dokumentation über npx, zum Beispiel npx -y @modelcontextprotocol/server-filesystem /pfad/zum/projekt. Alternativ kann der Server mit Docker betrieben werden. In MCP-Clients wird er als stdio-Server registriert; die freizugebenden Pfade stehen in der args-Liste oder kommen über Roots. Der Server selbst benötigt keine Anmeldung bei einem externen Dienst und verursacht keine Lizenzkosten. Entscheidend sind die Rechte des lokalen Betriebssystemkontos: Was dieses Konto im erlaubten Ordner lesen oder schreiben darf, kann grundsätzlich auch über das Werkzeug erreicht werden.

Für wen lohnt sich Filesystem MCP?

Filesystem MCP lohnt sich für Nutzer, die KI-Agenten bewusst an lokale Dateien lassen wollen, ohne ihnen unbegrenzten Systemzugriff zu geben. Häufige Fragen lauten: Ist der Server kostenlos? Ja, laut Projekt ist er quelloffen; Kosten entstehen nur durch die eigene Laufzeitumgebung. Ist er sicher? Nur mit engen Roots, Backups und Review-Prozess. Kann er Dateien zerstören? Ja, Schreib- und Move-Werkzeuge können reale Änderungen ausführen. Der beste Einsatz ist deshalb ein klar abgegrenztes Arbeitsverzeichnis, in dem der Agent helfen darf und Änderungen nachvollziehbar versioniert werden.

Ein MCP-Client sowie Node.js mit npx oder alternativ Docker. Beim Start muss mindestens ein erlaubtes Verzeichnis als Argument angegeben werden, sofern der Client keine MCP-Roots bereitstellt.

Den Server über npx starten und alle freizugebenden Verzeichnisse als eigene Argumente anhängen. Der Client kann die Verzeichnisse alternativ dynamisch über MCP Roots setzen; übermittelte Roots ersetzen die beim Start angegebenen Verzeichnisse vollständig.

Bei Docker müssen freigegebene Pfade in den Container eingehängt werden. Für reinen Lesezugriff die Mounts mit ro kennzeichnen.

npx -y @modelcontextprotocol/server-filesystem /pfad/zum/verzeichnis

Keine separate Anmeldung. Der Server läuft lokal über stdio. Maßgeblich sind die Rechte des Betriebssystemkontos sowie die beim Start oder per MCP Roots erlaubten Verzeichnisse.

Lese- und standardmäßig auch Schreibrechte des ausführenden Kontos innerhalb der freigegebenen Verzeichnisse. Die Werkzeuge können Dateien lesen, erstellen, überschreiben, bearbeiten, verschieben und Verzeichnisse anlegen. Mit schreibgeschützten Docker-Mounts lässt sich der Zugriff auf Lesen begrenzen.

Dateiinhalte, Dateinamen, Pfade, Verzeichnisbäume und Metadaten aus den erlaubten Verzeichnissen werden an den MCP-Client und damit gegebenenfalls an dessen Sprachmodell übermittelt. Schreiboperationen verändern oder speichern Daten direkt im lokalen Dateisystem. Der Server selbst sendet keine Dateien an einen eigenen externen Dienst.

Zu breit gewählte Roots können vertrauliche Dateien offenlegen. Schreibwerkzeuge können Inhalte überschreiben, verschieben oder neu anlegen; die offizielle Tool-Kennzeichnung stuft mehrere Operationen ausdrücklich als potenziell destruktiv ein. Nur eng begrenzte Projektordner freigeben, sensible Pfade ausschließen, Schreibzugriff nur bei Bedarf erlauben und Änderungen versionieren oder sichern.