Cum conectezi Claude Desktop la Obsidian — O călătorie prin 4 servere MCP
O poveste reală despre găsirea unei modalități stabile de a automatiza refactoring-ul vault-ului Obsidian prin Claude. Ce s-a stricat, ce a funcționat și de ce VaultForge s-a dovedit a fi singura opțiune funcțională.
Imaginează-ți: ai peste 400 de note în Obsidian, adunate de-a lungul anilor. Totul e împrăștiat prin rădăcina vault-ului, conceptele amestecate cu notele tehnice, există duplicate (ideas.md și un folder ideas/ cu 13 fișiere înăuntru), niciun sistem. Vrei să faci ordine — să construiești o arhitectură de foldere ca lumea, să adaugi fișiere MOC, să organizezi tag-urile. Manual e plictisitor și lent. Gândul firesc: conectezi Claude la Obsidian prin MCP și lași AI-ul să facă refactoring-ul. S-a dovedit — e un drum printr-un câmp minat. Iată prin ce a trebuit să trec ca să ajung la o soluție funcțională.
Ce este MCP și de ce nu e chiar atât de simplu
MCP (Model Context Protocol) este un protocol deschis de la Anthropic care îi permite lui Claude să se conecteze la instrumente și date externe. Principiul e simplu: rulează un server local care expune "instrumente" (tools), iar Claude le apelează în timpul conversației.
Pentru Obsidian există teoretic o grămadă de servere MCP. În practică — fiecare are problemele lui.
Problema principală a ecosistemului Obsidian: Obsidian este o aplicație închisă, fără MCP oficial. Comunitatea a umplut golul, dar fiecare implementare o ia pe drumul ei și niciuna nu are "binecuvântarea oficială".
Încercarea 1: MarkusPfundstein/mcp-obsidian
Primul instrument pe care îl găsești când cauți. 3.400 de stele pe GitHub, prezent în toate tutorialele. Pare o alegere sigură.
Cum funcționează: server Python bazat pe pluginul Local REST API din Obsidian. Serverul comunică cu pluginul prin HTTPS, iar pluginul execută operațiile prin Obsidian API.
Ce a mers prost
- Nu a mai fost actualizat de 17 luni
- 85 de issue-uri deschise
- Fără
move/rename— doar read, write, append, delete - Local REST API are un bug documentat de pierdere de date: endpoint-ul POST poate suprascrie în tăcere un fișier la append
Nu e potrivit pentru refactoring — avem nevoie să mutăm fișiere și să păstrăm link-urile. Mergem mai departe.
Încercarea 2: aaronsb/obsidian-mcp-plugin
Am găsit o variantă care funcționează ca plugin nativ de Obsidian. Asta înseamnă acces direct la API-ul intern al Obsidian — backlinks, Dataview, graful de legături. Move-ul prin API-ul nativ actualizează automat toate wiki-link-urile, pentru că Obsidian se ocupă singur de asta.
Dificultăți la configurare
- Pluginul nu se află în catalogul oficial Obsidian (PR-ul stă în așteptare, cu erori de validare)
- Trebuie instalat prin BRAT (Beta Reviewers Auto-update Tool)
- Claude Desktop nu acceptă Bearer token direct din UI — m-a obligat să activez HTTPS în plugin
- Certificatul self-signed pentru localhost creează probleme de încredere
Prin toate aceste soluții de compromis l-am conectat în cele din urmă. Test de bază — vault.move chiar rescrie [[wikilinks]], funcționează cum trebuie.
Ce a mers prost în producție
Când am început refactoringul în masă (drag-and-drop la zeci de foldere în Obsidian + operații MCP simultane), serverul s-a blocat 4+ minute. De ce: pluginul rulează în interiorul Obsidian. Când Obsidian reindexează mii de fișiere după o schimbare masivă de structură, pluginul se blochează odată cu el.
Concluzie: dependența de o instanță Obsidian deschisă și de indexul ei este fatală pentru operațiile în masă.
Încercarea 3: @bitbonsai/mcpvault
Logic — avem nevoie de un server care nu depinde de Obsidian. Lucrează direct cu fișierele de pe disc. @bitbonsai/mcpvault — recomandat în multe recenzii. Acces direct la sistemul de fișiere, configurare simplă (npx @bitbonsai/mcpvault@latest /path/to/vault), 14 instrumente. Obsidian nici măcar nu trebuie să fie deschis.
Înainte să instalez, am verificat un lucru critic — dacă wiki-link-urile se actualizează la move. Am găsit un review de la un utilizator:
Conectorul de sistem de fișiere nu știe că e în Obsidian — vede un folder cu fișiere <code>.md</code> și atât. Nu știe că numele fișierelor poartă greutate semantică, că fiecare <code>[[wikilink]]</code> se rupe în momentul în care redenumești sau muți. Auto-update links funcționează doar când redenumirea se face din interiorul aplicației. Am aflat asta după ce i-am cerut lui Claude să curețe numele fișierelor și m-am întors la un dashboard cu jumătate din link-uri rupte.
Confirmat în documentația proprie a mcpvault: PR #101 (wiki link resolution) este în review, nu a fost merge-uit. Deci un move prin mcpvault ar rupe jumătate din vault. Nu e potrivit.
Încercarea 4: VaultForge (finalul)
blacksmithers/vaultforge — construit special pentru agenți AI care fac refactoring.
Corect arhitectural
- Sistem de fișiere direct — nu depinde de Obsidian
- Motor propriu de wikilink — implementează logica de rezolvare a
[[wikilink]]care actualizează toate formele (stem, cale completă, alias, embed) - Dry run implicit la toate operațiile distructive — întâi arată ce se va schimba, apoi confirmi tu
- 27 de instrumente față de 8–14 la concurenți: batch_rename, update_links, backlinks (analiză de impact), prune_empty_dirs, frontmatter, smart_search (BM25), vault_themes (clustering TF-IDF)
- Licență MIT, TypeScript, zero sub-dependențe
- Instalare în 30 de secunde prin
.mcpb(extensie one-click pentru Claude Desktop)
Test de siguranță pe fișiere izolate
Am creat 4 fișiere de test cu link-uri încrucișate — link-uri stem, link-uri cu alias, link-uri cu cale completă. Mut un fișier într-un subfolder:
delta.md → subfolder/delta-renamed.mdVaultForge a arătat un dry run: "1 fișier va fi redenumit, 3 link-uri vor fi actualizate". Am executat pe bune.
| 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]] |
Am verificat după — toate cele trei tipuri de link-uri s-au actualizat corect. Exact asta le lipsea tuturor instrumentelor anterioare.
Cum instalezi VaultForge — instrucțiunea finală
Dacă ai macOS și Claude Desktop:
Pasul 1
Descarcă fișierul .mcpb:
curl -fsSL https://github.com/blacksmithers/vaultforge/releases/latest/download/vaultforge.mcpb \
-o /tmp/vaultforge.mcpb && open /tmp/vaultforge.mcpbPasul 2
Claude Desktop va deschide dialogul de instalare a extensiei. Introdu calea absolută către vault — fără backslash-uri, cu spații normale:
/Users/yourname/Library/Mobile Documents/iCloud~md~obsidian/Documents/MyVaultPasul 3
Apasă Save. Claude Desktop va adăuga extensia în config automat. Nu e nevoie de restart — extensiile .mcpb sunt preluate automat.
Pasul 4
Verifică: într-un chat nou întreabă: "What is the status of my Obsidian vault?" — ar trebui să returneze ceva de genul totalFiles: 416, totalDirs: 135, ...
Ce am învățat despre ecosistemul MCP al Obsidian
În primul rând, "cel mai popular" nu înseamnă "funcțional". MarkusPfundstein/mcp-obsidian are 3.400 de stele și e recomandarea implicită, dar e învechit și îi lipsesc operații esențiale.
În al doilea rând, un plugin nativ are un cost ascuns. Pluginul aaronsb părea ideal — graf, Dataview, move nativ. Dar dependența de o instanță Obsidian pornită și de indexul ei îl face nepotrivit pentru operații în masă serioase.
În al treilea rând, sistemul de fișiere direct fără un motor de link-uri este o capcană. Mcpvault e rapid și simplu, dar "doar mutarea fișierelor" distruge structura vault-ului. Link-urile poartă o semantică impusă pe care sistemul de fișiere nu o cunoaște. Fără o implementare proprie a logicii de wikilink, instrumentul devine o mină.
În al patrulea rând, testează pe date izolate. Înainte să încredințezi vreunui instrument un refactoring în masă — creează un folder de test cu 4–5 fișiere cu link-uri încrucișate și vezi ce se întâmplă. 5 minute de testare economisesc ore de recuperare din backup.
În al cincilea rând, ține un backup git al vault-ului. Cel mai important dintre toate. Un singur git init în interiorul vault-ului și commit-uri periodice — asta e asigurarea împotriva oricărei greșeli a unui agent AI sau instrument. Dacă se strică ceva — git reset --hard aduce totul înapoi.
Concluzie
Drumul a durat câteva ore și trei încercări eșuate. Arhitectura finală arată așa:
- VaultForge — instrumentul principal de lucru. Sistem de fișiere direct + motor propriu de wikilink + 27 de instrumente = refactoring stabil la orice scară.
- Git — versionarea vault-ului. Rollback gratuit pentru orice greșeală.
Acum pot face ceea ce a pornit totul: să-i cer lui Claude să organizeze 400 de note într-o arhitectură PARA ca lumea, să îmbine duplicatele, să adauge frontmatter, să construiască hărți MOC. Fiecare operație e sigură, link-urile se păstrează, iar dry run-ul arată ce se va întâmpla înainte să se schimbe ceva.
Dacă și tu te uiți la Obsidianul tău dezordonat și vrei un asistent AI — începe direct cu VaultForge. Nu repeta traseul meu prin proiecte moarte, plugin-uri beta și servere de sistem de fișiere fără logică de link-uri.