Skip to main content
Înapoi la blog
ObsidianClaudeMCPAutomationAI

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ă.

Publicat 3 mai 20269 min de citit

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.md

VaultForge a arătat un dry run: "1 fișier va fi redenumit, 3 link-uri vor fi actualizate". Am executat pe bune.

Link typeBeforeAfter
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:

Terminal
curl -fsSL https://github.com/blacksmithers/vaultforge/releases/latest/download/vaultforge.mcpb \
  -o /tmp/vaultforge.mcpb && open /tmp/vaultforge.mcpb

Pasul 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/MyVault

Pasul 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.