Skip to main content
← Volver al blog
ObsidianClaudeMCPAutomationAI

Cómo conectar Claude Desktop a Obsidian — Un viaje a través de 4 servidores MCP

Una historia real sobre la búsqueda de una forma estable de automatizar el refactoring del vault de Obsidian vía Claude. Qué se rompió, qué funcionó, y por qué VaultForge resultó ser la única opción funcional.

Publicado 3 de mayo de 20269 min de lectura

Imagina: tienes más de 400 notas en Obsidian, acumuladas durante años. Todo está disperso en la raíz del vault, conceptos mezclados con notas técnicas, hay duplicados (ideas.md y una carpeta ideas/ con 13 archivos dentro), sin sistema. Quieres poner orden — construir una arquitectura de carpetas adecuada, agregar archivos MOC, organizar etiquetas. Hacerlo manualmente es tedioso y lento. El pensamiento lógico: conectar Claude a Obsidian vía MCP, que la IA haga el refactoring. Resulta que — es un camino a través de un campo minado. Esto es lo que tuve que pasar para llegar a una solución funcional.

Qué es MCP y por qué no es tan simple

MCP (Model Context Protocol) es un protocolo abierto de Anthropic que permite a Claude conectarse a herramientas externas y datos. El principio es simple: se ejecuta un servidor local que expone "herramientas" (tools), y Claude las llama durante la conversación.

Para Obsidian hay teóricamente muchos servidores MCP. En la práctica — cada uno tiene sus propios problemas.

El problema principal del ecosistema Obsidian: Obsidian es una aplicación cerrada sin MCP oficial. La comunidad llenó el vacío, pero cada implementación va por su cuenta, y ninguna tiene "bendición oficial".

Intento 1: MarkusPfundstein/mcp-obsidian

La primera herramienta que aparece al buscar. 3.400 estrellas en GitHub, en todos los tutoriales. Parece una elección segura.

Cómo funciona: servidor Python basado en el plugin Local REST API de Obsidian. El servidor se comunica con el plugin vía HTTPS, el plugin ejecuta operaciones a través de la API de Obsidian.

Qué salió mal

  • Sin actualizar en 17 meses
  • 85 issues abiertas
  • Sin move/rename — solo read, write, append, delete
  • Local REST API tiene un bug documentado de pérdida de datos: el endpoint POST puede sobrescribir silenciosamente un archivo al hacer append

No apto para refactoring — necesitamos mover archivos y preservar enlaces. Seguimos adelante.

Intento 2: aaronsb/obsidian-mcp-plugin

Encontré una opción que funciona como plugin nativo de Obsidian. Esto significa acceso directo a la API interna de Obsidian — backlinks, Dataview, grafo de enlaces. Move a través de la API nativa actualiza todos los wiki-links automáticamente, porque Obsidian lo maneja internamente.

Dificultades de instalación

  • El plugin no está en el catálogo oficial de Obsidian (PR pendiente con errores de validación)
  • Hay que instalarlo vía BRAT (Beta Reviewers Auto-update Tool)
  • Claude Desktop no acepta Bearer token directamente por UI — obligó a habilitar HTTPS en el plugin
  • Certificado self-signed para localhost crea problemas de confianza

A través de todos estos workarounds finalmente lo conecté. Test básico — vault.move reescribe efectivamente [[wikilinks]], funciona como se espera.

Qué salió mal en producción

Cuando comencé el refactoring masivo (drag-and-drop de docenas de carpetas en Obsidian + operaciones MCP simultáneas), el servidor se colgó por 4+ minutos. Por qué: el plugin corre dentro de Obsidian. Cuando Obsidian reindexiza miles de archivos tras un cambio masivo de estructura, el plugin se bloquea con él.

Conclusión: la dependencia de una instancia abierta de Obsidian y su índice es fatal para operaciones masivas.

Intento 3: @bitbonsai/mcpvault

Lógicamente — necesitamos un servidor que no dependa de Obsidian. Trabaja directamente con archivos en disco. @bitbonsai/mcpvault — recomendado en muchas reseñas. Acceso directo al sistema de archivos, configuración simple (npx @bitbonsai/mcpvault@latest /path/to/vault), 14 herramientas. Obsidian ni siquiera necesita estar abierto.

Antes de instalar, verifiqué un punto crítico — si los wiki-links se actualizan al mover. Encontré una reseña de usuario:

El conector de filesystem no sabe que está en Obsidian — ve una carpeta de archivos <code>.md</code> y eso es todo. No sabe que los nombres de archivo llevan peso semántico, que cada <code>[[wikilink]]</code> se romperá en el momento del rename o move. Auto-update links solo funciona cuando el rename ocurre desde dentro de la app. Lo descubrí después de pedirle a Claude que limpiara nombres de archivos y volví a un dashboard con la mitad de los enlaces rotos.

Confirmado en la documentación del propio mcpvault: PR #101 (wiki link resolution) está en review, no mergeado. Así que mover vía mcpvault rompería la mitad del vault. No sirve.

Intento 4: VaultForge (Final)

blacksmithers/vaultforge — construido específicamente para agentes de IA que hacen refactoring.

Arquitectónicamente correcto

  • Direct filesystem — no depende de Obsidian
  • Motor propio de wikilinks — implementa lógica de resolución de [[wikilink]] que actualiza todas las formas (stem, ruta completa, alias, embed)
  • Dry run por defecto en todas las operaciones destructivas — primero muestra qué cambiará, luego confirmas
  • 27 herramientas vs 8–14 en competidores: batch_rename, update_links, backlinks (impact analysis), prune_empty_dirs, frontmatter, smart_search (BM25), vault_themes (TF-IDF clustering)
  • Licencia MIT, TypeScript, zero sub-dependencies
  • Instalación en 30 segundos vía .mcpb (extensión one-click para Claude Desktop)

Test de seguridad en archivos aislados

Creé 4 archivos de prueba con enlaces cruzados — stem links, links con alias, links con ruta completa. Moviendo un archivo a una subcarpeta:

delta.md → subfolder/delta-renamed.md

VaultForge mostró un dry run: "1 archivo será renombrado, 3 enlaces serán actualizados". Ejecutó de verdad.

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]]

Verificado después — los tres tipos de enlaces se actualizaron correctamente. Esto es exactamente lo que faltaba en todas las herramientas anteriores.

Cómo instalar VaultForge — Instrucciones finales

Si tienes macOS y Claude Desktop:

Paso 1

Descarga el archivo .mcpb:

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

Paso 2

Claude Desktop abrirá el diálogo de instalación de extensión. Ingresa la ruta absoluta a tu vault — sin backslashes, con espacios normales:

/Users/yourname/Library/Mobile Documents/iCloud~md~obsidian/Documents/MyVault

Paso 3

Haz clic en Save. Claude Desktop agregará la extensión a la configuración automáticamente. No necesita reinicio — las extensiones .mcpb se detectan automáticamente.

Paso 4

Verifica: en un nuevo chat pregunta: "What is the status of my Obsidian vault?" — debería devolver algo como totalFiles: 416, totalDirs: 135, ...

Lo que aprendí sobre el ecosistema MCP de Obsidian

Primero, "más popular" no significa "funcional". MarkusPfundstein/mcp-obsidian tiene 3.400 estrellas y es la recomendación por defecto, pero está desactualizado y le faltan operaciones clave.

Segundo, un plugin nativo tiene un costo oculto. El plugin aaronsb parecía ideal — graph, Dataview, move nativo. Pero la dependencia de una instancia abierta de Obsidian y su índice lo hace inadecuado para operaciones masivas serias.

Tercero, filesystem directo sin link-engine es una trampa. Mcpvault es rápido y simple, pero "solo mover archivos" destruye la estructura del vault. Los enlaces llevan semántica impuesta que el filesystem no conoce. Sin su propia implementación de lógica wikilink, la herramienta se convierte en una mina.

Cuarto, prueba con datos aislados. Antes de confiar a cualquier herramienta un refactoring masivo — crea una carpeta de prueba con 4–5 archivos con enlaces cruzados y mira qué pasa. 5 minutos de prueba ahorran horas de recuperación desde backup.

Quinto, mantén un backup git de tu vault. Lo más importante de todo. Un solo git init dentro del vault y commits periódicos — eso es seguro contra cualquier error de un agente AI o herramienta. Si algo se rompe — git reset --hard lo devuelve todo.

Conclusión

El camino tomó varias horas y tres intentos fallidos. La arquitectura final se ve así:

  • VaultForge — la herramienta principal de trabajo. Direct filesystem + motor propio de wikilinks + 27 herramientas = refactoring estable a cualquier escala.
  • Git — versionado del vault. Rollback gratuito para cualquier error.

Ahora puedo hacer lo que motivó todo esto: pedirle a Claude que organice 400 notas en una arquitectura PARA adecuada, fusione duplicados, agregue frontmatter, construya mapas MOC. Cada operación es segura, los enlaces se preservan, el dry run muestra qué pasará antes de que algo cambie.

Si tú también miras tu Obsidian desordenado y quieres un asistente de IA — empieza directamente con VaultForge. No repitas mi ruta a través de proyectos muertos, plugins beta y servidores filesystem sin lógica de enlaces.