MCP es la pieza que falta entre Claude Code y tu vault de Obsidian

En 2026, conectar un agente de código a un vault de Obsidian ya no es una idea exótica. Es, probablemente, el setup de gestión de conocimiento más subestimado que existe ahora mismo. Y sin embargo casi todo el mundo que lo hace se queda en el primer escalón: apuntar Claude Code a una carpeta y dejar que lea y escriba markdown. Funciona. Pero es solo el principio, y entender por qué importa el siguiente paso, MCP, requiere primero entender bien qué es lo que ya tenemos y dónde se rompe.

Lo que ya es posible sin MCP

Cuando Claude Code apunta directamente a un vault, opera como cualquier agente con acceso a sistema de archivos: lee la estructura de carpetas, aplica grep y glob para localizar contenido relevante, y escribe o edita archivos markdown respetando las convenciones que le hayas dado (frontmatter YAML, wikilinks, una jerarquía de carpetas por tipo de contenido). No hay plugin, no hay base de datos, no hay API: solo texto plano y un agente que sabe leerlo y escribirlo con criterio.

El resultado, cuando el sistema está bien diseñado, es más potente de lo que parece. Como referencia real, no hipotética: un vault que sigo de cerca ha pasado, con exactamente este método, de 78 fuentes en bruto (papers, artículos, documentación) a 180 páginas de wiki interconectadas (83 de ellas páginas de conceptos, el resto herramientas, personas, comparaciones y resúmenes de fuente), todas con referencias cruzadas que el propio agente mantiene actualizadas cada vez que entra contenido nuevo. Sin que nadie escriba una sola página a mano.

El techo del acceso directo a archivos

Pero este modelo tiene un límite estructural, no solo una limitación de rendimiento. Claude Code necesita saber de antemano cómo está organizado tu vault: qué carpeta es inmutable, cuál es la convención de frontmatter, dónde viven los conceptos frente a las herramientas. Cada vault nuevo es, en la práctica, una integración distinta que hay que volver a explicar desde cero en el system prompt.

Además, el agente no puede preguntar "¿qué eres capaz de hacer?" a un vault. Solo puede leer lo que ya existe y ejecutar operaciones genéricas de archivo (leer, escribir, buscar por texto). No hay forma de exponerle una operación derivada (dame el grafo de backlinks de esta nota, corre esta consulta de Dataview, dime qué páginas quedaron huérfanas) sin que el propio agente reconstruya esa lógica desde cero cada vez, gastando contexto y margen de error en el camino.

Qué resuelve MCP, en profundidad

MCP (Model Context Protocol) es el estándar abierto que Anthropic lanzó en noviembre de 2024 para resolver exactamente este problema: la integración entre modelos de IA y sistemas externos. Antes de MCP, si N asistentes de IA necesitaban conectarse a M herramientas o fuentes de datos distintas, hacían falta N×M integraciones a medida: cuando una aplicación quería soportar Notion, lo construía desde cero; cuando otra quería lo mismo, lo volvía a construir desde cero. MCP convierte ese N×M en N+M: se construyen clientes genéricos (uno por aplicación) y servidores genéricos (uno por sistema), y cualquier cliente habla con cualquier servidor sin integración a medida.

La analogía correcta es USB-C: antes, cada periférico tenía su propio conector; con USB-C, el dispositivo solo necesita hablar el protocolo, sin que le importe si está conectado a un Mac o a un PC.

La arquitectura tiene tres capas. El host es la aplicación de cara al usuario (Claude Code, Claude Desktop, o un agente propio) que interpreta lo que se le pide y decide si necesita datos o herramientas externas. El client vive dentro del host y gestiona una conexión 1:1 con cada servidor, traduciendo peticiones abstractas a mensajes MCP concretos y gestionando el ciclo de vida de la sesión. El server conecta el protocolo con un sistema real, en este caso un vault de Obsidian, traduciendo peticiones MCP a operaciones nativas.

Dos propiedades hacen que esto sea más que una capa de abstracción cosmética. La primera es el descubrimiento dinámico de capacidades: al conectar, el cliente pregunta al servidor qué es capaz de hacer, y el servidor responde en tiempo real. Si el servidor añade una función nueva mañana, el cliente no necesita ser reprogramado para usarla. La segunda es el desacoplamiento entre inteligencia y datos: quien construye el servidor MCP para Obsidian no necesita saber qué modelo lo va a usar, y quien construye el agente no necesita reconstruir su integración cada vez que cambia de modelo.

Un servidor MCP expone tres tipos de primitivas. Los resources son datos que el modelo puede leer pero no modificar: el contenido de una nota, los resultados de una búsqueda, el grafo de backlinks. Las tools son acciones que el modelo puede invocar activamente: crear una nota, actualizar un tag, ejecutar una consulta estructurada. Los prompts son plantillas de instrucción reutilizables y parametrizables, por ejemplo "resume esta fuente y genera la página de wiki correspondiente" como una operación con nombre, no como texto libre que hay que reescribir cada vez.

Aplicado a Obsidian, en concreto

Ya existen servidores MCP construidos específicamente para Obsidian dentro de su ecosistema de código abierto, normalmente apoyados en el plugin de API REST local del propio Obsidian, que exponen operaciones como búsqueda semántica sobre el vault, creación y edición de notas, gestión de tags y metadatos, o lectura del grafo de enlaces, sin que el agente necesite conocer de antemano la estructura exacta de carpetas.

Lo que cambia en la práctica es sutil pero importante: sin MCP, Claude Code administra tu vault, con reglas que tú le explicaste una por una. Con MCP, tu vault se convierte en una herramienta que Claude Code puede operar exactamente igual que operaría una API o una base de datos, descubriendo sus capacidades en el momento de conectar, no memorizándolas de antemano. Y esa misma conexión sirve para cualquier otro cliente MCP, no solo para Claude Code: el mismo servidor podría alimentar un agente distinto, en otra aplicación, sin tocar una línea de código del lado de Obsidian.

Marco práctico: tres niveles de madurez

Para situar dónde está tu propio setup, este es el marco que uso:

Nivel 0: copiar y pegar contexto a mano. Cada conversación empieza de cero; el usuario pega fragmentos relevantes de sus notas en el chat. Funciona para tareas puntuales, no escala.

Nivel 1: agente con acceso directo a archivos. Es donde está la mayoría de los setups Claude Code + Obsidian hoy, incluido el ejemplo de 78→180 páginas de este artículo. El agente lee y escribe el vault directamente, siguiendo convenciones explicadas en un archivo de instrucciones. Ya es sustancialmente más potente que el nivel 0, y para un solo vault gestionado por un solo agente, puede ser suficiente durante mucho tiempo.

Nivel 2: agente conectado vía MCP. El vault se expone como servidor con capacidades descubribles dinámicamente, reutilizables entre modelos y aplicaciones distintas. Tiene sentido en cuanto entra en juego más de un agente, más de un vault, o la necesidad de exponer operaciones que van más allá de leer y escribir archivo por archivo.

No hace falta saltar directamente al nivel 2 para sacarle partido a un vault gestionado por IA. El nivel 1 ya es un salto real frente a no tener ningún sistema. Pero entender qué resuelve MCP es entender hacia dónde va esto: de "mi IA puede leer mis notas" a "mi conocimiento es un sistema que cualquier IA puede operar".

¿En qué nivel está tu propio setup ahora mismo? Cuéntamelo en los comentarios. Si hay suficiente interés, la próxima pieza es un paso a paso de cómo montar tu primer servidor MCP para Obsidian.

Y si esto te ha sido útil, sígueme @chesny

Esto es solo el primer artículo de una serie sobre agentes que dejan de leer sistemas y empiezan a operarlos.