llmwiki: eine selbst gepflegte Wiki aus eigenen Quellen, angetrieben von Claude über MCP

Welches Problem llmwiki löst und für wen es gedacht ist

Die meisten Wissenssammlungen scheitern nicht am Sammeln, sondern am Pflegen. Man legt PDFs, Notizen und Ausschnitte aus Webseiten ab, und nach einigen Monaten liegt ein Haufen Dateien herum, aus dem niemand mehr eine zusammenhängende Antwort zieht. llmwiki setzt genau dort an: Ein Ordner mit Quelldateien wird indexiert, und ein Sprachmodell schreibt daraus Wiki-Seiten mit Querverweisen und Zitaten. Das README beschreibt das Ziel als selbst pflegende persönliche Wikipedia und nennt drei Adressaten: den Einzelnen, der zurücklesen will, was er gelesen hat; das Modell selbst, das die eigenen Denkmuster als Kontextschicht bekommt; und Organisationen, deren Wissen laut README vor allem in den Köpfen der Mitarbeiter liegt. Der dritte Punkt ist eher als Hoffnung formuliert denn als ausgebautes Produktmerkmal, und die Beispiele im Rest des Dokuments bleiben persönlich. Wer eine einzelne Person mit einem gewachsenen Dokumentenordner ist, passt am besten zur beschriebenen Mechanik.

Ordner, Index und MCP: der tatsächliche Datenfluss

Die Architektur besteht aus drei Teilen, die sich aus dem Repository-Aufbau ablesen lassen: einer Python-API unter api/, einem MCP-Server unter mcp/ und einer Next.js-Oberfläche unter web/. Der Nutzer zeigt auf einen Ordner, der ausdrücklich außerhalb des Repositorys liegen soll. llmwiki indiziert diesen Ordner in einen lokalen Suchindex, damit die Dateien in der App auftauchen und Claude sie lesen kann. Nach Angaben des README verschiebt, verändert oder lädt das Werkzeug die Quelldateien nicht hoch; hinzu kommen lediglich ein wiki/-Verzeichnis für die erzeugten Seiten und ein verstecktes .llmwiki/-Verzeichnis für den Index. Der Schreibvorgang läuft also nicht über die Quelldateien, sondern über die generierte Schicht daneben. Claude greift über MCP zu, das heißt der MCP-Server ist die Schnittstelle, über die das Modell lesen, schreiben und suchen kann. Ein Workspace entspricht einem MCP-Servereintrag, weshalb das README empfiehlt, pro Ordner einen Eintrag anzulegen. Diese Eins-zu-eins-Zuordnung ist die wichtigste Strukturentscheidung des Projekts: Sie hält die Trennung zwischen mehreren Sammlungen sauber, bedeutet aber auch, dass ein übergreifender Zugriff auf mehrere Ordner hinweg nicht vorgesehen ist.

Installation: zwei Befehle, die den Rest erledigen

Die Einrichtung beginnt mit einem Klon und zwei Paketinstallationen. Unter macOS und Linux lauten die Schritte laut README:

git clone https://github.com/lucasastorian/llmwiki.git cd llmwiki python -m venv .venv && source .venv/bin/activate pip install -r api/requirements.txt -r mcp/requirements.txt cd web && npm install && cd ..

Unter Windows wird die virtuelle Umgebung mit .venv\Scripts\Activate.ps1 aktiviert. Falls die Execution Policy die Aktivierung blockiert, nennt das README zwei Auswege: einmalig Set-ExecutionPolicy -Scope CurrentUser RemoteSigned ausführen oder die Aktivierung überspringen und statt python den Pfad .venv\Scripts\python verwenden. Danach folgt der eigentliche Start:

./llmwiki open ~/research

Dieser Aufruf initialisiert den Workspace, indiziert den Ordner, startet API und Web-App und öffnet localhost:3000. Der lokale Modus ist bewusst auf Loopback beschränkt: Die API hört auf 127.0.0.1 und unterstützt laut README weder LAN- noch Remote-Bindung. Wer die Wiki im Heimnetz freigeben will, muss also auf den Selbsthosting-Modus der Remote-Variante ausweichen. Für die Anbindung an Claude folgt:

./llmwiki mcp-config ~/research

Die ausgegebene JSON-Struktur wird in claude_desktop_config.json für Claude Desktop oder in .claude/settings.json für Claude Code eingefügt. Für die Onboarding-Oberfläche gibt es einen Entwicklungsmodus: cd web, dann NEXT_PUBLIC_ONBOARDING_PREVIEW=true npm run dev und localhost:3000/onboarding aufrufen. Das README weist darauf hin, dass der Entwicklungsserver nach Änderung dieses Flags neu gestartet werden muss und dass die Vorschau Erstellung und Abschluss nur im Speicher simuliert, ohne eine Wiki anzulegen.

Der nächtliche Lauf und die Grenzen der Automatik

Der eigentliche Reiz liegt im Claude Routine genannten Ablauf. Ein Routine ist laut README ein geplanter Prompt, der selbstständig läuft. Der vorgeschlagene Prompt verlangt, alles Neue seit dem letzten Lauf zu finden, jede Quelle zu lesen und die Wiki entsprechend zu aktualisieren: neue Seiten schreiben, Material in bestehende Seiten einfügen, Querverweise und Zitate korrigieren. Geplant wird das nächtlich, entweder über Claude Code Routines auf der Infrastruktur von Anthropic, sodass der Lauf auch bei geschlossenem Laptop stattfindet, oder als geplante Aufgabe auf dem eigenen Rechner. Hier liegt die wichtigste Einschränkung, und das README benennt sie nicht als solche: Die Automatik hängt an einem Anthropic-Konto und an der Verfügbarkeit dieser Planungsfunktionen. Wer Claude nicht nutzt oder in einer Umgebung arbeitet, in der ein externer Dienst die eigenen Dokumente nicht verarbeiten darf, verliert den Kern des Versprechens. Auch die Qualität der Seiten ist nicht überprüfbar, solange man die Läufe nicht selbst liest. Das Modell entscheidet, wann eine neue Seite gerechtfertigt ist und wann Material eingefügt wird; das README liefert dafür keine Konventionen, keine Seitenschablone und keine Regel, wie Konflikte zwischen zwei Quellen aufgelöst werden. Die Kuratierung der Quellen bleibt beim Nutzer, die Struktur der Ausgabe liegt beim Modell. Für eine Sammlung, in der Widersprüche zwischen Quellen häufig sind, ist das ein offenes Risiko.

Dateiformate, Clipper und die Frage der Extraktion

Als Eingabe nennt das README Markdown, PDF, Word, PowerPoint, Excel und Bilder. Die Verarbeitung ist nicht für alle Formate gleich: LibreOffice wird als optionale Abhängigkeit aufgeführt, um Word- und PowerPoint-Dateien zu extrahieren, und ein MISTRAL_API_KEY wird für eine höhere OCR-Qualität bei PDFs empfohlen. Ohne diese beiden Zusätze funktioniert das Einlesen laut README weiterhin, die Qualität der Texterkennung bei gescannten PDFs und die Extraktion aus Office-Formaten dürften aber schwächer ausfallen. Wer viele gescannte Dokumente verarbeitet, sollte den Schlüssel also einplanen, und wer Word- oder PowerPoint-Dateien ablegt, sollte LibreOffice installieren, bevor er sich über leere Seiten wundert. Neben dem Dateiordner gibt es einen zweiten Eingabekanal: eine Chrome-Erweiterung, mit der sich Webseiten und PDFs beim Lesen erfassen lassen. Markierungen und Kommentare werden laut README zusammen mit der Quelle gespeichert und sind über MCP für Claude sichtbar. Das ist der inhaltlich interessanteste Teil des Projekts, weil damit nicht nur festgehalten wird, was gelesen wurde, sondern auch, was der Leser dazu gedacht hat. Allerdings beschreibt das README die Erweiterung nur; wo sie zu beziehen ist und wie sie installiert wird, geht aus dem vorliegenden Text nicht hervor.

Was die Oberfläche zeigt und was das Repository nicht verrät

Die Web-App ist als Next.js-Anwendung beschrieben und dient dazu, die eigene Wikipedia zu durchsuchen und die zugrunde liegenden Quellen anzusehen. Genannt werden native Querverweise zwischen Seiten und zurück zu den Quellen, ein Graph, der Beziehungen zwischen Konzepten und Entitäten sichtbar macht, sowie Visualisierungen einschließlich SVGs und Mermaid-Diagrammen. Der Screenshot im README zeigt eine kompilierte Seite mit Inhaltsverzeichnis und Zitaten. Das ist eine plausible Aufzählung, aber sie sagt nichts über die Bedienung: Wie eine Seite manuell korrigiert wird, ob es eine Versionshistorie gibt und wie man eine misslungene Generierung zurücknimmt, steht nicht im Material. Ein weiterer Punkt, der vor einer Adoption zu klären ist: Das Repository verzeichnet keine Releases. Es gibt also keine Versionsnummern, keine Changelogs und keine benannten Stände, an denen man sich orientieren könnte. Für ein Werkzeug, das regelmäßig in den eigenen Dokumentenbestand schreibt, ist das ein praktisches Problem, weil ein Update nicht gegen eine feste Version abgewogen werden kann. Wer es einsetzt, sollte den geklonten Stand selbst festhalten.

Alternative: RAG-Werkzeuge mit anderem Grundmodell

Der naheliegende Vergleich sind Retrieval-Systeme wie LlamaIndex oder Haystack, die ebenfalls einen Dokumentenordner indexieren und ein Modell darauf antworten lassen. Der Unterschied liegt nicht in der Indexierung, sondern im Ausgabeartefakt. Ein RAG-System beantwortet eine Frage und vergisst die Antwort; llmwiki materialisiert das Ergebnis als Dateien im wiki/-Verzeichnis, die man lesen, verlinken und versionieren kann. Das ist der eigentliche Bruch mit dem üblichen Muster: Die Generierung ist nicht flüchtig, sondern ein Bestandteil des Repositories. Der Preis dafür ist ein zweiter Pflegezyklus. Bei einem RAG-System altert der Index mit den Quelldateien, bei llmwiki altern die generierten Seiten zusätzlich, und sie können veralten, ohne dass die Quelle sich ändert, etwa wenn das Modell eine Seite anders strukturiert. Hinzu kommt die Bindung an Claude über MCP. Ein RAG-System lässt sich mit einem lokal laufenden Modell betreiben; llmwiki ist laut README auf MCP-kompatible Anwendungen ausgelegt und nennt Claude.ai, Claude Cowork, Claude Code und Codex. Für Umgebungen ohne diese Anbindung ist es schlicht das falsche Werkzeug.

Wartung, Lizenz und was vor dem Start zu prüfen ist

Der Wartungsaufwand verteilt sich auf drei Stellen: die Python-Abhängigkeiten aus api/requirements.txt, die des MCP-Servers aus mcp/requirements.txt und die Node-Pakete unter web/. Ohne Releases gibt es keinen Hinweis darauf, in welchem Rhythmus sich diese Abhängigkeiten ändern, sodass ein Update auf gut Glück erfolgt. Dazu kommen die externen Voraussetzungen: LibreOffice und der Mistral-Schlüssel für die Extraktion, ein Anthropic-Konto für die eigentliche Generierung, und im selbst gehosteten Betrieb die Datenbank, die das Thema Supabase im Repository nahelegt. Die Lizenz ist Apache-2.0, also eine permissive Lizenz mit Patentgewährung und der Pflicht, Änderungen zu kennzeichnen und den Lizenztext beizulegen. Das ist keine Rechtsberatung, aber für die meisten internen Nutzungen unproblematisch. Zu klären bleibt vor dem ersten Lauf, ob das Repository nach dem Klonen tatsächlich die Datei llmwiki im Wurzelverzeichnis enthält, denn alle Befehle im README setzen sie voraus, und ob die Chrome-Erweiterung außerhalb des Repositorys bezogen werden muss. Beides lässt sich in wenigen Minuten prüfen, bevor man einen Ordner mit echten Dokumenten indizieren lässt. Wer diese Prüfung scheut, sollte den gehosteten Dienst unter llmwiki.app ausprobieren, statt selbst zu installieren.

Redaktionelles Fazit

Wer einen Ordner mit PDFs, Notizen und Web-Clippings besitzt und Claude bereits nutzt, findet hier einen nachvollziehbaren Weg zu einer wachsenden Wissensbasis. Wer ohne Anthropic-Konto arbeitet, eine fertige Team-Lösung sucht oder Releases mit Versionsnummern erwartet, ist hier falsch. Vor dem ersten echten Lauf sollte man klären, ob das Repository nach dem Klonen tatsächlich die Datei llmwiki im Wurzelverzeichnis enthält, wie der Chrome-Clipper installiert wird und ob die Lizenz Apache-2.0 für die geplante Nutzung ausreicht.

Offizielle Quellen

1. Issues
2. License: Apache-2.0
3. lucasastorian/llmwiki on GitHub
4. Project website
5. README