Wie man Claude Desktop mit Obsidian verbindet — Eine Reise durch 4 MCP-Server
Eine echte Geschichte über die Suche nach einem stabilen Weg, das Obsidian-Vault-Refactoring über Claude zu automatisieren. Was kaputt ging, was funktionierte, und warum VaultForge die einzige funktionierende Option war.
Stellen Sie sich vor: Sie haben über 400 Notizen in Obsidian, über Jahre angesammelt. Alles liegt verstreut im Vault-Root, Konzepte vermischt mit technischen Notizen, es gibt Duplikate (ideas.md und ein ideas/-Ordner mit 13 Dateien darin), kein System. Sie wollen Ordnung schaffen — eine vernünftige Ordnerarchitektur aufbauen, MOC-Dateien hinzufügen, Tags organisieren. Manuell ist das mühsam und langsam. Der logische Gedanke: Claude über MCP mit Obsidian verbinden, die KI soll das Refactoring übernehmen. Es stellt sich heraus — das ist ein Weg durch ein Minenfeld. Hier ist, was ich durchmachen musste, um zu einer funktionierenden Lösung zu gelangen.
Was ist MCP und warum es nicht so einfach ist
MCP (Model Context Protocol) ist ein offenes Protokoll von Anthropic, das Claude erlaubt, sich mit externen Werkzeugen und Daten zu verbinden. Das Prinzip ist einfach: Ein lokaler Server läuft, stellt "Tools" bereit, und Claude ruft sie während der Konversation auf.
Für Obsidian gibt es theoretisch reichlich MCP-Server. In der Praxis — jeder hat seine eigenen Probleme.
Das Hauptproblem des Obsidian-Ökosystems: Obsidian ist eine geschlossene Anwendung ohne offizielles MCP. Die Community hat die Lücke gefüllt, aber jede Implementierung geht ihren eigenen Weg, und keine hat einen "offiziellen Segen".
Versuch 1: MarkusPfundstein/mcp-obsidian
Das erste Tool, das bei der Suche auftaucht. 3.400 Sterne auf GitHub, in jedem Tutorial. Scheint eine sichere Wahl.
Wie es funktioniert: Python-Server basierend auf dem Local REST API Plugin in Obsidian. Der Server kommuniziert mit dem Plugin über HTTPS, das Plugin führt Operationen über die Obsidian API aus.
Was schiefging
- Seit 17 Monaten nicht aktualisiert
- 85 offene Issues
- Kein
move/rename— nur read, write, append, delete - Local REST API hat einen dokumentierten Data-Loss-Bug: POST-Endpoint kann eine Datei beim Append stillschweigend überschreiben
Für Refactoring ungeeignet — wir müssen Dateien verschieben und Links bewahren. Weiter.
Versuch 2: aaronsb/obsidian-mcp-plugin
Eine Option gefunden, die als natives Obsidian-Plugin funktioniert. Das bedeutet direkten Zugriff auf Obsidians interne API — Backlinks, Dataview, Linkgraph. Move über die native API aktualisiert alle Wiki-Links automatisch, weil Obsidian das selbst handhabt.
Schwierigkeiten bei der Einrichtung
- Plugin ist nicht im offiziellen Obsidian-Katalog (PR hängt mit Validierungsfehlern)
- Installation über BRAT (Beta Reviewers Auto-update Tool) erforderlich
- Claude Desktop akzeptiert Bearer Token nicht direkt über die UI — erzwang die Aktivierung von HTTPS im Plugin
- Self-signed Zertifikat für localhost verursacht Vertrauensprobleme
Durch all diese Workarounds schließlich verbunden. Basistest — vault.move schreibt tatsächlich [[wikilinks]] um, funktioniert wie erwartet.
Was im Einsatz schiefging
Als ich mit dem Massen-Refactoring begann (Drag-and-Drop dutzender Ordner in Obsidian + gleichzeitige MCP-Operationen), hing der Server 4+ Minuten. Warum: Das Plugin läuft innerhalb von Obsidian. Wenn Obsidian tausende Dateien nach einer massiven Strukturänderung neu indiziert, blockiert das Plugin mit.
Fazit: Die Abhängigkeit von einer geöffneten Obsidian-Instanz und ihrem Index ist fatal für Massenoperationen.
Versuch 3: @bitbonsai/mcpvault
Logisch — wir brauchen einen Server, der nicht von Obsidian abhängt. Arbeitet direkt mit Dateien auf der Festplatte. @bitbonsai/mcpvault — in vielen Reviews empfohlen. Direkter Dateisystemzugriff, einfaches Setup (npx @bitbonsai/mcpvault@latest /path/to/vault), 14 Tools. Obsidian muss nicht einmal geöffnet sein.
Vor der Installation habe ich einen kritischen Punkt überprüft — ob Wiki-Links beim Move aktualisiert werden. Ein Nutzerbericht:
Der Filesystem-Connector weiß nicht, dass er in Obsidian ist — er sieht einen Ordner mit <code>.md</code>-Dateien und das war's. Weiß nicht, dass Dateinamen semantisches Gewicht tragen, dass jeder <code>[[wikilink]]</code> im Moment des Umbenennens oder Verschiebens kaputt geht. Auto-Update Links funktioniert nur, wenn das Umbenennen innerhalb der App passiert. Ich erfuhr das, nachdem ich Claude gebeten hatte, Dateinamen aufzuräumen, und zu einem Dashboard mit halb kaputten Links zurückkehrte.
Bestätigt in mcpvaults eigener Dokumentation: PR #101 (Wiki Link Resolution) ist in Review, nicht gemergt. Also würde Move über mcpvault die Hälfte des Vaults kaputt machen. Ungeeignet.
Versuch 4: VaultForge (Finale)
blacksmithers/vaultforge — speziell für KI-Agenten gebaut, die Refactoring durchführen.
Architektonisch korrekt
- Direktes Dateisystem — keine Abhängigkeit von Obsidian
- Eigene Wikilink-Engine — implementiert
[[wikilink]]-Auflösungslogik, die alle Formen aktualisiert (Stem, vollständiger Pfad, Alias, Embed) - Dry Run standardmäßig bei allen destruktiven Operationen — zeigt erst, was sich ändert, dann bestätigst du
- 27 Tools vs. 8–14 bei Konkurrenten: batch_rename, update_links, backlinks (Impact-Analyse), prune_empty_dirs, frontmatter, smart_search (BM25), vault_themes (TF-IDF Clustering)
- MIT-Lizenz, TypeScript, zero Sub-Dependencies
- Installation in 30 Sekunden über
.mcpb(One-Click-Erweiterung für Claude Desktop)
Sicherheitstest an isolierten Dateien
4 Testdateien mit Querverweisen erstellt — Stem-Links, Links mit Alias, Links mit vollem Pfad. Eine Datei in einen Unterordner verschoben:
delta.md → subfolder/delta-renamed.mdVaultForge zeigte einen Dry Run: "1 Datei wird umbenannt, 3 Links werden aktualisiert". Tatsächlich ausgeführt.
| Link type | Before | After |
|---|---|---|
| Stem | [[delta]] | [[delta-renamed]] |
| Alias | [[delta|D]] | [[delta-renamed|D]] |
| Full path + alias | [[_vf-test/delta|D]] | [[_vf-test/subfolder/delta-renamed|D]] |
Danach überprüft — alle drei Linktypen korrekt aktualisiert. Genau das fehlte allen vorherigen Tools.
Wie man VaultForge installiert — Finale Anleitung
Wenn Sie macOS und Claude Desktop haben:
Schritt 1
Laden Sie die .mcpb-Datei herunter:
curl -fsSL https://github.com/blacksmithers/vaultforge/releases/latest/download/vaultforge.mcpb \
-o /tmp/vaultforge.mcpb && open /tmp/vaultforge.mcpbSchritt 2
Claude Desktop öffnet den Erweiterungsinstallationsdialog. Geben Sie den absoluten Pfad zu Ihrem Vault ein — keine Backslashes, normale Leerzeichen:
/Users/yourname/Library/Mobile Documents/iCloud~md~obsidian/Documents/MyVaultSchritt 3
Klicken Sie auf Save. Claude Desktop fügt die Erweiterung automatisch zur Konfiguration hinzu. Kein Neustart nötig — .mcpb-Erweiterungen werden automatisch erkannt.
Schritt 4
Überprüfen: In einem neuen Chat fragen Sie: "What is the status of my Obsidian vault?" — sollte etwas wie totalFiles: 416, totalDirs: 135, ... zurückgeben
Was ich über das Obsidian-MCP-Ökosystem gelernt habe
Erstens: "Am beliebtesten" heißt nicht "funktioniert". MarkusPfundstein/mcp-obsidian hat 3.400 Sterne und ist die Standard-Empfehlung, aber es ist veraltet und es fehlen wichtige Operationen.
Zweitens: Ein natives Plugin hat versteckte Kosten. Das aaronsb Plugin sah ideal aus — Graph, Dataview, natives Move. Aber die Abhängigkeit von einer laufenden Obsidian-Instanz und ihrem Index macht es für ernsthafte Massenoperationen ungeeignet.
Drittens: Direktes Dateisystem ohne Link-Engine ist eine Falle. Mcpvault ist schnell und einfach, aber "einfach Dateien verschieben" zerstört die Vault-Struktur. Links tragen aufgezwungene Semantik, von der das Dateisystem nichts weiß. Ohne eigene Wikilink-Logik-Implementierung wird das Tool zur Landmine.
Viertens: An isolierten Daten testen. Bevor Sie einem Tool Massen-Refactoring anvertrauen — erstellen Sie einen Testordner mit 4–5 Dateien mit Querverweisen und sehen Sie, was passiert. 5 Minuten Testen sparen Stunden der Wiederherstellung aus Backups.
Fünftens: Halten Sie ein Git-Backup Ihres Vaults. Das Wichtigste von allem. Ein einziges git init innerhalb des Vaults und regelmäßige Commits — das ist die Versicherung gegen jeden Fehler eines KI-Agenten oder Tools. Wenn etwas kaputtgeht — git reset --hard bringt alles zurück.
Fazit
Der Weg dauerte mehrere Stunden und drei gescheiterte Versuche. Die finale Architektur sieht so aus:
- VaultForge — das Haupt-Arbeitswerkzeug. Direktes Dateisystem + eigene Wikilink-Engine + 27 Tools = stabiles Refactoring in jedem Maßstab.
- Git — Vault-Versionierung. Kostenloser Rollback für jeden Fehler.
Jetzt kann ich tun, wofür das alles begonnen wurde: Claude bitten, 400 Notizen in eine ordentliche PARA-Architektur zu sortieren, Duplikate zusammenführen, Frontmatter hinzufügen, MOC-Karten erstellen. Jede Operation ist sicher, Links bleiben erhalten, Dry Run zeigt was passiert, bevor sich etwas ändert.
Wenn Sie auch auf Ihr zugemülltes Obsidian schauen und einen KI-Assistenten wollen — fangen Sie direkt mit VaultForge an. Wiederholen Sie nicht meinen Weg durch tote Projekte, Beta-Plugins und Dateisystem-Server ohne Link-Logik.