Meine KI konnte meine Dateien nicht sehen – ich habe einen MCP-Server ohne Abhängigkeiten gebaut

Meine KI konnte meine Dateien nicht sehen — ich habe einen MCP-Server ohne Abhängigkeiten gebaut

Meine KI konnte meine Dateien nicht sehen — ich habe einen MCP-Server ohne Abhängigkeiten gebaut

Monatelang fühlte sich mein lokales Sprachmodell wie ein brillanter Kollege an, der in einem schalldichten Raum eingesperrt war. Ich hatte eine schnelle Mistral-basierte Instanz, die über Ollama auf meiner Workstation lief, und eine wachsende Sammlung von Skripten und Notebooks, die über mein Home-Verzeichnis verstreut waren. Das Modell konnte logisch schlussfolgern, Code schreiben und Snippets debuggen, die ich in das Chat-Fenster einfügte — aber es hatte keine Ahnung, was zwei Verzeichnisse weiter saß. Wenn ich wollte, dass es eine Konfigurationsdatei überprüft, die Logs von gestern zusammenfasst oder prüft, ob eine Funktion bereits in einem anderen Modul implementiert ist, musste ich kopieren, einfügen und darauf hoffen, dass das Kontextfenster nicht überlief. Die Reibung war zuerst subtil, dann mörderisch. Ich betrieb KI lokal, um Daten privat und Workflows schnell zu halten, und dennoch fungierte ich als manuelle Kopieren-Einfügen-Brücke zwischen meinem Dateisystem und meinem Modell.

Ich brauchte etwas, das zwischen meiner Festplatte und meinem LLM sitzen konnte: einen leichtgewichtigen Übersetzer, der sowohl Dateisystem als auch KI sprach. Das Model Context Protocol (MCP) hatte als Möglichkeit, Tools und Ressourcen standardisiert für Assistenten verfügbar zu machen, an Zugkraft gewonnen — aber die meisten Referenzimplementierungen, die ich fand, bauten auf schweren Abhängigkeitsketten auf: Node.js-Server mit Hunderten von npm-Paketen oder Python-Umgebungen, die Conda verlangten, nur um eine Textdatei zu lesen. Das fühlte sich im Widerspruch zur lokalen, minimalen Vertrauensphilosophie zu stehen, die mich zu Ollama und Open-Weight-Modellen geführt hatte. Also beschloss ich, meinen eigenen MCP-Server von Grund auf zu bauen, ohne externe Abhängigkeiten, und meiner KI beizubringen zu sehen.

Die blinde Stelle lokaler LLMs

Lokale Modelle zu betreiben, löst zwei große Probleme: Datenschutz und Latenz. Wenn die Gewichte auf der eigenen GPU leben und die Prompts die Maschine nie verlassen, eliminiert man Netzwerk-Roundtrips und Bedenken zur Datenverwaltung durch Dritte. Communities um offene Modelle, einschließlich derer, die auf Hugging Face veröffentlichen und lokale Inferenz-Stacks optimieren, haben es trivial gemacht, ein Mistral-, Llama- oder Qwen-Modell herunterzuladen und loszuschwatzen. Ollama im Besonderen hat lokale Inferenz zu einer Ein-Befehl-Erfahrung gemacht. Das Modell ist da, hilfsbereit und völlig unwissend über die Welt außerhalb seiner Prozessgrenze.

Das Problem ist architektonisch. Ein lokaler LLM-Prozess liest von der Standardeingabe oder einer API-Nutzlast, berechnet eine Antwort und schreibt auf die Standardausgabe. Er durchforstet keine Verzeichnisse, öffnet keine Tabellenkalkulationen oder verfolgt Logs — es sei denn, die hostende Anwendung füttert diese Daten explizit in den Prompt. Dieses Design ist ein Feature für Sicherheit — es verhindert, dass ein Modell versehentlich Dateien löscht — aber es wird zum Bug für Produktivität. Man endet mit einer leistungsstarken Schlussfolgerungsmaschine, die kein persistentes Gedächtnis des eigenen Projekts hat und keine Sinnesorgane für die Umgebung. Man selbst ist der Sensor. Jeder Dateizugriff, jedes Verzeichnislisting, jede grep-Operation muss von einem selbst ausgeführt, in einen Prompt destilliert und durch ein Kontextfenster gequetscht werden, das, obwohl wachsend, immer noch endlich ist.

Ich wollte, dass das Modell Informationen auf Abruf anfordern kann. Wenn ich fragte: „Warum ist der Build fehlgeschlagen?", sollte die KI selbst in der Lage sein, das Makefile anzusehen, die Umgebungsdatei zu prüfen und das Fehlerlog zu scannen. Das erfordert ein Protokoll.

Das Model Context Protocol betritt die Bühne

Das Model Context Protocol ist ein offener Standard, der darauf ausgelegt ist, KI-Assistenten strukturiert und sicher mit externen Systemen zu verbinden. Anstatt eine gesamte Codebasis in einen Prompt zu stopfen und das Beste zu hoffen, ermöglicht MCP einem Assistenten, Tools aufzurufen, Ressourcen zu lesen und nur die Daten abzurufen, die er braucht, genau wenn er sie braucht. Es verwandelt einen statischen Chat in eine interaktive Agentenschleife: Der Nutzer stellt eine Frage, das Modell schlussfolgert, welche Informationen fehlen, der Client führt einen Tool-Aufruf aus, und das Modell integriert das Ergebnis in seine finale Antwort.

Konzeptionell sitzt MCP auf derselben Ebene wie ältere Plugin-Architekturen, aber es ist granularer und standardisierter. Ein Server stellt Fähigkeiten bereit — vielleicht einen Dateileser, eine Datenbank-Abfrageschnittstelle oder einen Taschenrechner — und der Client wirbt diese Fähigkeiten beim Modell an. Das Modell selbst spricht kein HTTP oder JSON-RPC; es gibt natürlichsprachliche Anfragen aus, die der Client auf Protokollnachrichten abbildet. Diese Trennung der Belange bedeutet, dass das Modell portabel bleibt, während die Integrationsschicht explizit bleibt.

Für ein lokales Setup ist der einfachste Transport die Standardeingabe und die Standardausgabe. Ein vom Client gestarteter MCP-Server wird zu einem langlebigen Subprozess. Der Client schreibt JSON-RPC-Nachrichten in die Standardeingabe des Servers und liest Antworten von seiner Standardausgabe. Es gibt keine offenen Ports, keine TLS-Zertifikate zu verwalten und keine Firewall-Regeln, an denen herumzufummeln ist. Es ist eine elegante Passform für eine Maschine, auf der das Modell, der Client und die Daten alle auf derselben Kiste leben.

Warum Null-Abhängigkeiten wichtig sind

Als ich begann, bestehende MCP-Server zu recherchieren, fiel mir auf, wie schnell ein „einfacher" Dateileser zu einer vollständigen Software-Lieferkette anschwoll. Ein typischer Server könnte eine spezifische Node.js-Version, ein Dutzend npm-Pakete für Argument-Parsing und Logging und transitive Abhängigkeiten in der Größenordnung von Hunderten erfordern. Ein Python-Äquivalent zog oft FastAPI, Pydantic und ein Web-Framework rein, nur um eine einzelne Funktion bereitzustellen. Diese Stacks sind für Produktiv-SaaS in Ordnung, aber sie fühlten sich schwer an für ein Dienstprogramm, dessen einziger Job es war, Dateien vom eigenen Laptop zu lesen.

Null-Abhängigkeiten ist nicht Minimalismus um seiner selbst willen; es ist eine Sicherheits- und Wartungsstrategie. Jedes externe Paket ist ein potenzieller Punkt des Bruchs oder der Kompromittierung. Ein left-pad-artiges Verschwinden, ein kompromittiertes Maintainer-Konto oder eine ruhende Abhängigkeit mit einer frischen CVE können ein Tool unbrauchbar — oder schlimmer, unsicher machen. Wenn man eine Brücke zwischen einem KI-Agenten und seinen persönlichen Dateien baut, sollte man in der Lage sein, die gesamte Brücke zu auditieren, indem man eine einzelne Datei mit Quellcode liest.

Indem ich den Server in einer Systemsprache mit einer robusten Standardbibliothek schrieb — denke an Go, Rust oder Zig — konnte ich eine einzelne statische Binary kompilieren. Diese Binary hat keinen Laufzeit-Interpreter zu installieren, keinen Paketmanager aufzurufen und keine virtuelle Umgebung zu aktivieren. Ich kann sie auf die Maschine eines Kollegen kopieren, auf einen CI-Runner werfen oder in einem Git-Repository verstauen und erwarten, dass sie sich identisch verhält. Diese Portabilität passt perfekt zur Ethos lokaler KI-Tools, die von Communities um Ollama und offene Modellgewichte vertreten wird. Wenn das Modell in sich geschlossen ist, sollte das Tool, das es füttert, auch in sich geschlossen sein.

Architektur eines Dateisystem-MCP-Servers

Ich entschied mich für ein Design mit drei beweglichen Teilen: der Transportschicht, der Tool-Registry und dem Dateisystem-Sandbox. Der Transport spricht JSON-RPC 2.0 über stdio. Beim Start gibt der Server einen Initialisierungs-Handshake aus, dann betritt er eine Schleife, die Zeile für Zeile von der Standardeingabe liest.