Obsidian Scoped-write MCP

Servicio MCP que accede a un Vault de Obsidian especificado. Todo el Vault es legible; la creación y actualización de Markdown solo está permitida en dos directorios exclusivos de ChatGPT:

• 00-ChatGPT系统入口

• 01-ChatGPT策略主脑

No se ofrecen herramientas de eliminación, movimiento, renombrado ni escritura de archivos que no sean Markdown.

Herramientas

• list_directory: Enumera directorios.

• read_markdown: Lee Markdown.

• search_markdown: Busca en Markdown.

• get_file_info: Muestra tamaño, fecha de modificación, SHA-256 y estado de escritura.

• create_directory: Crea una subcarpeta normal de un nivel dentro de los directorios permitidos; el directorio padre debe existir.

• create_markdown: Crea un archivo nuevo en un directorio permitido; no se permite sobrescribir.

• update_markdown: Actualiza un archivo existente usando el SHA-256 esperado y hace una copia de seguridad fuera del Vault antes de actualizar.

Related MCP server: Obsidian MCP Local

Verificación local

npm ci
npm test

Las pruebas crean por defecto un Vault temporal y un directorio de respaldo temporal, sin tocar los datos personales de Obsidian. Cuando se pasa una ruta real de Vault, solo se ejecutan pruebas de lectura, sin realizar escrituras.

Límites de seguridad

• Los directorios de escritura están controlados por una lista blanca fija en el servidor; los parámetros de las herramientas no pueden ampliar el alcance.

• La creación de carpetas solo permite operaciones de un nivel; se rechazan nombres duplicados, directorios ocultos, directorios padre inexistentes, rutas fuera de rango y escapes por enlaces simbólicos.

• Se rechaza si el destino de creación ya existe.

• Antes de actualizar, llama a get_file_info y usa el sha256 devuelto como expected_sha256; si el archivo cambió, la actualización se rechaza.

• Antes de actualizar, se hace una copia de seguridad en el directorio de datos de aplicación local del usuario actual de Windows; la copia no está en el Vault ni en el repositorio Git.

• Se rechazan rutas absolutas, rutas fuera de rango, escapes por enlaces simbólicos y archivos que no sean Markdown.

Flujo de desarrollo

• main siempre permanece publicable.

• Todos los cambios del repositorio usan ramas de corta duración y Pull Requests.

• Solo se puede fusionar después de que pase la CI; por defecto se usa squash merge.

• Arquitectura, límites de seguridad, formato de datos, dependencias a largo plazo o funciones grandes con múltiples PR independientes: Issue principal, Sub-issues, ADR, PR, CI y registro de reversión.

• Parches pequeños: un solo Issue o PR, cambios mínimos, pruebas mínimas e instrucciones de reversión.

Aceptación de parches ligeros

• Aceptación: ejecutar npm test y fusionar después de que pase la verificación de CI del Pull Request.

• Reversión: restaurar el squash commit correspondiente en GitHub.