obsidian-mcp-server es un servidor MCP que permite a los agentes de IA consultar, buscar y resumir documentos Markdown de una bóveda de Obsidian.
Este proyecto va más allá de la simple lectura de documentos; ofrece búsqueda híbrida local utilizando transformers.js e incluye una interfaz de usuario de agente de IA CLI interactiva para conversar directamente con la bóveda desde la terminal.
🔍 Búsqueda híbrida: Combina búsqueda por palabras clave y búsqueda semántica (vectorial), proporcionando resultados óptimos mediante RRF (Reciprocal Rank Fusion) y Reranking.
🚀 IA local sin dependencias: Utiliza @huggingface/transformers para ejecutar modelos de incrustación (embedding) y reordenamiento (reranking) directamente dentro del proceso de Node.js (no requiere servidor API externo).
💬 Agente CLI integrado: Proporciona una interfaz basada en terminal para hacer preguntas sobre el contenido de la bóveda y recibir respuestas utilizando herramientas MCP. Ver detalles
📦 Optimización de tokens: Ofrece varios modos de compresión y límites de salida para controlar el consumo de tokens del agente de IA.
Related MCP server: Obsidian MCP
Búsqueda integrada (vault, action="search"): Realiza búsquedas por palabras clave y por significado simultáneamente para explorar documentos relevantes.
Lectura de documentos (vault, action="read"): Consulta el cuerpo y los metadatos de una nota específica.
Lista completa y estado (vault, action="list_all"|"stats"): Verifica el estado general y la lista de archivos de la bóveda.
Recopilación de contexto (vault, action="collect_context"): Genera paquetes de conocimiento de alta densidad relacionados con un tema específico.
Carga de conocimiento (vault, action="load_memory"): Invoca instantáneas de memoria guardadas.
Gestión de Frontmatter (generate_property|write_property): Generación y aplicación de metadatos basados en IA.
Organización de archivos adjuntos (organize_attachments): Mueve automáticamente las imágenes dentro de los documentos a una carpeta dedicada y actualiza los enlaces.
Node.js: v22.0.0 o superior
Bóveda de Obsidian: Debes conocer la ruta absoluta.
Para habilitar las funciones de búsqueda semántica y reordenamiento, debes descargar los modelos locales necesarios mediante el siguiente comando:
# 로컬 임베딩 및 리랭킹 모델 설치
npx @sunub/obsidian-mcp-server setupO si ya tienes instalado el paquete:
obsidian-mcp-server setupEste comando descarga los modelos Xenova/paraphrase-multilingual-MiniLM-L12-v2 (incrustación) y Xenova/bge-reranker-base (reordenamiento) y los guarda en la caché local.
Variable de entorno | Valor predeterminado | Rol | ¿Obligatorio? |
| — | Ruta absoluta de la bóveda de Obsidian | Sí |
|
| Punto final de la API del modelo de chat para la CLI UI | Sí, al usar CLI |
|
| Nombre del modelo a usar para el chat | Sí, al usar CLI |
|
| Nivel de registro ( | Opcional |
En la configuración de cada cliente, modifica env.VAULT_DIR_PATH con la ruta de tu propia bóveda.
{
"mcpServers": {
"obsidian": {
"command": "npx",
"args": ["-y", "@sunub/obsidian-mcp-server@latest"],
"env": {
"VAULT_DIR_PATH": "/Users/username/Documents/MyVault"
}
}
}
}Para capturar la relevancia semántica que es difícil de encontrar solo con la búsqueda por palabras clave, se sigue el siguiente proceso:
Búsqueda por palabras clave: Extrae resultados de coincidencia exacta mediante el Indexer interno.
Búsqueda vectorial: Utiliza LanceDB y las incrustaciones de transformers.js para buscar fragmentos semánticamente similares.
Fusión RRF: Combina las clasificaciones de ambos resultados de búsqueda mediante el algoritmo Reciprocal Rank Fusion.
Reordenamiento local: Evalúa nuevamente los resultados superiores combinados con el modelo BGE Reranker para determinar la clasificación final.
Si el modelo no está instalado, funcionará automáticamente en modo exclusivo de palabras clave y mostrará un mensaje recomendando ejecutar npx @sunub/obsidian-mcp-server setup en la terminal.
Este proyecto incluye una interfaz de chat de IA basada en terminal optimizada para la bóveda de Obsidian.
Integración RAG: Al hacer una pregunta, recopila automáticamente el contexto relevante de la bóveda y lo envía al LLM.
Streaming en tiempo real: Renderiza la respuesta del LLM y el "proceso de pensamiento ()" en tiempo real.
Comandos de barra diagonal: Permite invocar herramientas MCP directamente desde la CLI, como /search, /read, /index.
Gestión multi-MCP: Monitorea el estado y la lista de herramientas de todos los servidores MCP conectados.
Ejecutar el servidor del modelo de chat: Inicia un servidor como llama.cpp u Ollama en modo compatible con OpenAI.
Ejemplo: llama-server -m models/gemma-2-9b-it.Q4_K_M.gguf --port 8080
Ejecutar CLI:
# 환경변수와 함께 실행
VAULT_DIR_PATH="/your/vault" LLM_API_URL="http://localhost:8080" npx @sunub/obsidian-mcp-server/search <palabra clave>: Ejecuta búsqueda híbrida
/read "nombre de archivo": Leer un documento específico
/stats: Verificar el estado de la bóveda
/index: Forzar la reindexación de la base de datos vectorial
/tools: Ver la lista de todas las herramientas MCP disponibles
/help: Ver ayuda
Apache-2.0
Starts and completes a two-step workflow for AI-generated frontmatter properties.
Step 1: Call this tool with sourcePath (and optional outputPath). It returns a structured instruction payload and a content preview for AI analysis. Step 2: Call this same tool again with aiGeneratedProperties. The tool then writes those properties by executing the same write logic used by the 'write_property' tool.
Use this tool when an AI agent should orchestrate analysis and write in a consistent workflow.
| Name | Required | Description | Default |
|---|---|---|---|
| quiet | No | If true, the final write operation will return a minimal success message. | |
| overwrite | No | If set to true, existing properties will be overwritten by the AI-generated content. Default: false. | |
| outputPath | No | The path where the processed file with properties will be saved. If not provided, the source file will be updated in place. | |
| sourcePath | Yes | The path to the source markdown file to read and analyze (e.g., "draft/my-article.md") | |
| aiGeneratedProperties | No | AI-generated properties based on content analysis. If provided, these will be used instead of internal analysis. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include openWorldHint: true, indicating side effects. The description details the two-step workflow, including that it writes properties using the same logic as write_property. It adds context beyond annotations by explaining the workflow and return of structured payload.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: first sentence states purpose, then numbered steps, then usage guidance. No wasted words, each sentence contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has moderate complexity (5 params, nested objects, workflow). The description covers the workflow and parameter roles adequately. No output schema, but it mentions the return format implicitly. Slightly incomplete on return specifics but acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, providing baseline 3. The description adds value by explaining parameter roles in the workflow, such as sourcePath for reading and aiGeneratedProperties for the second call, going beyond schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool's purpose: starting and completing a two-step workflow for AI-generated frontmatter properties. It clearly distinguishes from sibling tools like write_property and generate_property by describing a compound workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises when to use the tool: when an AI agent should orchestrate analysis and write in a consistent workflow. It implies but does not explicitly state when not to use it or mention alternatives, though it references the same write logic as write_property.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reads a target markdown document and returns an AI-facing payload for generating frontmatter properties.
This tool does not write to disk. It returns content_preview and a target output schema so an AI can produce a valid property object.
Use Cases:
After completing a draft, when you need property suggestions from content.
When missing frontmatter fields (title, tags, summary, slug, date, category, completed) should be generated.
To apply generated properties to a file, call 'write_property' with the resulting JSON.
| Name | Required | Description | Default |
|---|---|---|---|
| filename | Yes | The name or path of the file to analyze and add properties to (e.g., "my-first-post.md") | |
| overwrite | No | If set to true, existing properties will be overwritten by the AI-generated content. Default: false. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are sparse (only openWorldHint=true), but the description compensates by explicitly stating 'This tool does not write to disk' and describing the return payload (content_preview and target output schema). This provides sufficient behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two paragraphs with bullet points for use cases. It is concise and front-loaded with the core function. The extra sentences about use cases and linking to write_property earn their place, though the overwrite default contradiction adds unnecessary confusion.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains the return structure adequately. It covers use cases and references to sibling tools. However, it fails to mention the potential side effect of overwrite when combined with write_property, and the default value inconsistency hurts completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
While schema coverage is 100%, the description contains a contradiction: it states 'Default: false' for the 'overwrite' parameter, but the input schema shows 'default': true. This inconsistency could mislead the agent. The description does add the context of overwriting existing properties, but the error reduces reliability.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Reads a target markdown document and returns an AI-facing payload for generating frontmatter properties.' The verb 'reads' and resource 'markdown document' are specific, and the distinction from the sibling 'write_property' is clear because it explicitly says this tool does not write to disk.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit use cases: 'After completing a draft, when you need property suggestions from content' and 'When missing frontmatter fields should be generated.' It also advises to use 'write_property' to apply the generated properties. However, it does not compare against all siblings like 'create_document_with_properties', which might have overlapping functionality.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scans a specified markdown file for linked images (or other attachments), moves them to a dedicated folder named after the document's title, and updates the links within the markdown file automatically.
Use Cases:
When a post is finalized and you want to clean up all associated images into a neat folder.
To automatically organize attachments for better vault management.
Example Workflow:
Specify 'my-awesome-post.md' as the fileName.
The tool finds the 'title' property in the frontmatter (e.g., "My Awesome Post").
It finds all image links like ![[my-image.png]].
It creates a folder at '{vault}/images/My Awesome Post/'.
It moves 'my-image.png' into that new folder.
It updates the link in the markdown file to ![[images/My Awesome Post/my-image.png]].
| Name | Required | Description | Default |
|---|---|---|---|
| quiet | No | If true, returns a minimal success message. | |
| keyword | Yes | A keyword to search for the markdown file within the vault. | |
| destination | No | The base folder to move attachments into. Defaults to "images". | images |
| useTitleAsFolderName | No | If true, creates a subfolder named after the document title. Defaults to true. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description openly describes the tool's actions: scanning a file, moving attachments to a new folder, and updating links. This discloses its mutating behavior, aligning with the openWorldHint annotation. It doesn't elaborate on reversibility or permissions, but the core behavior is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, starting with a clear action, followed by use cases and an example workflow. Every sentence adds meaningful information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, no output schema), the description covers the process thoroughly, including the steps and file organization. It does not explain return values or error handling, but this is acceptable since there is no output schema. The example workflow compensates for minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All four parameters have descriptions in the input schema, and the description adds value through an example workflow that illustrates how keyword, destination, and useTitleAsFolderName are used. The quiet parameter is not elaborated in the description beyond the schema, so the description adds limited additional semantics beyond the schema's descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool scans a markdown file for attachments, moves them to a dedicated folder, and updates links. It includes specific use cases and an example workflow, making the purpose unmistakable and distinct from sibling tools like create_document_with_properties or vault.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear use cases, such as when a post is finalized and you want to clean up attachments. However, it does not explicitly state when not to use the tool or mention alternatives, though the sibling tools are sufficiently different to avoid confusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieves and searches the content of Markdown (.md, .mdx) documents stored in an Obsidian vault. Use this tool to find notes related to a specific topic or keyword and understand their core content.
When to use:
When you need to find a specific note by its title or a keyword to check its content.
When you want to synthesize and summarize information scattered across multiple notes.
When looking for answers to questions based on your saved records, such as "What was the project deadline?"
To discover connections by finding all notes that link to a specific note.
When you need to retrieve a list of unfinished tasks (- [ ]) from daily notes or meeting minutes.
Use "index_vault_to_vectordb" to manually trigger a full re-indexing of the vault for the vector database.
Returns the content of the most relevant document(s) in text format. It can also include metadata such as the document's title, tags, and creation date.
Requirements: The user's Obsidian Vault path must be correctly configured in an environment variable or a similar setting. For searches, use the exact filename or include core keywords for content-based queries.
IMPORTANT INSTRUCTION FOR AI: If the tool response includes a 'diagnostic_message' (usually found at the beginning of the text or in a tag), you MUST relay this information to the user exactly once. It contains essential advice on how to improve search quality by running a local setup script via 'npx @sunub/obsidian-mcp-server setup'. Do not ignore it.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results to return (default: 10 for search, unlimited for others) | |
| query | No | Natural language query for filtering content paragraphs using the local reranker (optional for read action) | |
| quiet | No | If true, suppresses non-error output messages. Default is false. | |
| scope | No | Scope for collect_context. topic: collect docs relevant to topic, all: collect from the entire vault. | topic |
| topic | No | Topic to collect contextual memory for (collect_context action) | |
| action | Yes | The action to perform: search documents, read specific file, list all content, get stats, collect contextual memory packets, load stored memory, or trigger indexing | |
| keyword | No | Keyword to search for in documents (required for search action) | |
| maxDocs | No | Maximum number of documents to process for collect_context | |
| filename | No | Specific filename to read (required for read action) | |
| memoryMode | No | Memory output mode for collect_context. response_only: return packet only, vault_note: save to vault note only, both: return and save. | response_only |
| memoryPath | No | Path to a stored memory note for load_memory (default: memory/context_memory_snapshot.v1.md) | |
| excerptLength | No | Length of content excerpt to include in search results (default: 500) | |
| includeContent | No | Whether to include document content in search results (default: true) | |
| maxCharsPerDoc | No | Maximum number of characters extracted per document for collect_context | |
| maxOutputChars | No | Optional hard cap for output size in characters. Helps control token cost in long responses. | |
| compressionMode | No | Compression strategy for tool output. summary: lightest TOC & document summary only (default), aggressive: smallest output, balanced: moderate size, none: keep as much original content as possible. | summary |
| continuationToken | No | Continuation token to resume a previous collect_context batch operation | |
| includeFrontmatter | No | Whether to include frontmatter metadata in results (default: false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only provide openWorldHint. The description adds behavioral details: returns content and metadata, and includes crucial instruction about relaying diagnostic messages. This goes beyond annotations by disclosing expected output and a user interaction requirement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (purpose, when to use, return info, requirements, important instruction). It is front-loaded with the primary purpose. Though slightly verbose, every section adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (18 parameters, enums, no output schema), the description covers usage scenarios, return format, requirements, and a critical instruction. It provides sufficient context for an AI agent to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so all parameters are described in the schema. The description adds contextual usage hints (e.g., 'use exact filename or core keywords for searches'), which enhances understanding beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves and searches Markdown documents in an Obsidian vault, specifying verb (retrieves, searches) and resource (Markdown documents). It implicitly distinguishes from sibling tools (which are for writing/properties) by focusing on reading/searching.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a detailed 'When to use' section with specific scenarios (find note, synthesize info, find answers, etc.) and mentions triggering re-indexing. However, it does not explicitly state when not to use the tool or compare with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Description: Adds or updates properties within the frontmatter section at the top of a specified Obsidian markdown file. This tool is primarily used to apply metadata generated by the 'generate_property' tool to an actual file.
Parameters:
filePath (string, required): The path to the target markdown file to which properties will be added or updated. Example: "my-first-post.md"
properties (object, required): A JSON object containing the key-value pairs to be written to the file's frontmatter. If a property with the same key already exists in the file, it will be overwritten with the new value.
Example:
JSON { "title": "Optimizing I/O Handling in a Serverless Environment", "date": "2025-04-03", "tags": ["serverless", "optimization"], "summary": "A case study on optimizing I/O in a serverless environment by benchmarking Promise.all and Workers.", "completed": true }
Return Value:
Upon successful execution, it returns a JSON object containing the status, a confirmation message, and the property object that was applied to the file.
Example:
JSON { "status": "success", "message": "Successfully updated properties for my-first-post.md", "properties": { "title": "Optimizing I/O Handling in a Serverless Environment", "date": "2025-04-03", "tags": ["serverless", "optimization"], "summary": "A case study on optimizing I/O in a serverless environment by benchmarking Promise.all and Workers.", "completed": true } }
Dependencies & Requirements:
Input Data: The properties parameter should typically be the JSON object output from the 'generate_property' tool.
Environment Setup: The absolute path to the user's Obsidian Vault must be correctly set as an environment variable.
| Name | Required | Description | Default |
|---|---|---|---|
| quiet | No | If true, suppresses non-error output messages. Default is false. | |
| filePath | Yes | Path to the target markdown file within the Obsidian vault | |
| properties | Yes | Key-value pairs to be written to the file's frontmatter |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains overwrite behavior for existing properties and provides return value format. With only openWorldHint annotation, it adds meaningful transparency beyond what annotations offer. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with sections for overview, parameters, return value, and dependencies. Examples are helpful but slightly verbose. Front-loaded with purpose, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers usage, dependencies, and return value. No output schema, but description provides example. Could explicitly differentiate from siblings like 'create_document_with_properties', but overall sufficiently complete for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds value with examples and overwrite behavior for the properties object, but omits the 'quiet' parameter entirely, and schema default (true) contradicts description's implied default (false) if quiet were mentioned. This reduces score slightly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool adds/updates properties in Obsidian frontmatter, explicitly linking it to the 'generate_property' tool for applying metadata. It distinguishes from siblings like 'create_document_with_properties' by focusing on existing files.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates primary use case (apply metadata from generate_property) and prerequisites (vault path environment variable). It lacks explicit when-not-to-use instructions but provides sufficient context for appropriate invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.3.30vault3 fields changedInput schema / properties / compressionMode / defaultPrevious value: -"balanced"New value: +"summary"Input schema / properties / compressionMode / descriptionPrevious value: -"Compression strategy for tool output. aggressive: smallest output, balanced: default, none: keep as much original content as possible."New value: +"Compression strategy for tool output. summary: lightest TOC & document summary only (default), aggressive: smallest output, balanced: moderate size, none: keep as much original content as possible."Input schema / properties / compressionMode / enumPrevious value: -[
- "aggressive",
- "balanced",
- "none"
-]New value: +[
+ "summary",
+ "aggressive",
+ "balanced",
+ "none"
+]v0.3.29vault3 fields changedInput schema / properties / action / descriptionPrevious value: -"The action to perform: search documents, read specific file, list all content, get stats, collect contextual memory packets, load stored memory, semantic search, or trigger indexing"New value: +"The action to perform: search documents, read specific file, list all content, get stats, collect contextual memory packets, load stored memory, or trigger indexing"Input schema / properties / action / enumPrevious value: -[
- "search",
- "read",
- "list_all",
- "stats",
- "collect_context",
- "load_memory",
- "search_vault_by_semantic",
- "index_vault_to_vectordb"
-]New value: +[
+ "search",
+ "read",
+ "list_all",
+ "stats",
+ "collect_context",
+ "load_memory",
+ "index_vault_to_vectordb"
+]Input schema / properties / query / descriptionPrevious value: -"Natural language query for semantic search (required for search_vault_by_semantic action)"New value: +"Natural language query for filtering content paragraphs using the local reranker (optional for read action)"v0.3.20vault12 fields changedInput schema / properties / action / descriptionPrevious value: -"The action to perform: search documents, read specific file, list all content, or get stats"New value: +"The action to perform: search documents, read specific file, list all content, get stats, collect contextual memory packets, load stored memory, semantic search, or trigger indexing"Input schema / properties / action / enumPrevious value: -[
- "search",
- "read",
- "list_all",
- "stats"
-]New value: +[
+ "search",
+ "read",
+ "list_all",
+ "stats",
+ "collect_context",
+ "load_memory",
+ "search_vault_by_semantic",
+ "index_vault_to_vectordb"
+]Input schema / properties / compressionModeAdded value: +{
+ "default": "balanced",
+ "description": "Compression strategy for tool output. aggressive: smallest output, balanced: default, none: keep as much original content as possible.",
+ "enum": [
+ "aggressive",
+ "balanced",
+ "none"
+ ],
+ "type": "string"
+}Input schema / properties / continuationTokenAdded value: +{
+ "description": "Continuation token to resume a previous collect_context batch operation",
+ "minLength": 1,
+ "type": "string"
+}Input schema / properties / maxCharsPerDocAdded value: +{
+ "default": 1800,
+ "description": "Maximum number of characters extracted per document for collect_context",
+ "maximum": 8000,
+ "minimum": 200,
+ "type": "integer"
+}Input schema / properties / maxDocsAdded value: +{
+ "default": 20,
+ "description": "Maximum number of documents to process for collect_context",
+ "maximum": 100,
+ "minimum": 1,
+ "type": "integer"
+}Input schema / properties / maxOutputCharsAdded value: +{
+ "description": "Optional hard cap for output size in characters. Helps control token cost in long responses.",
+ "maximum": 12000,
+ "minimum": 500,
+ "type": "number"
+}Input schema / properties / memoryModeAdded value: +{
+ "default": "response_only",
+ "description": "Memory output mode for collect_context. response_only: return packet only, vault_note: save to vault note only, both: return and save.",
+ "enum": [
+ "response_only",
+ "vault_note",
+ "both"
+ ],
+ "type": "string"
+}Input schema / properties / memoryPathAdded value: +{
+ "description": "Path to a stored memory note for load_memory (default: memory/context_memory_snapshot.v1.md)",
+ "type": "string"
+}Input schema / properties / queryAdded value: +{
+ "description": "Natural language query for semantic search (required for search_vault_by_semantic action)",
+ "type": "string"
+}Input schema / properties / scopeAdded value: +{
+ "default": "topic",
+ "description": "Scope for collect_context. topic: collect docs relevant to topic, all: collect from the entire vault.",
+ "enum": [
+ "topic",
+ "all"
+ ],
+ "type": "string"
+}Input schema / properties / topicAdded value: +{
+ "description": "Topic to collect contextual memory for (collect_context action)",
+ "minLength": 1,
+ "type": "string"
+}create_document_with_propertiesgenerate_propertyorganize_attachmentsvaultwrite_propertyEach tool has a clearly distinct purpose: vault for searching/reading, generate_property for reading and suggesting properties, write_property for writing properties, create_document_with_properties for a two-step workflow, and organize_attachments for file management. No significant overlap.
Most tools follow a verb_noun pattern (generate_property, write_property, organize_attachments), but create_document_with_properties is a longer phrase and vault is a single noun without a verb, breaking consistency.
5 tools is well-scoped for an Obsidian vault management server, covering essential operations without being too few or too many.
Core workflows (reading, property generation/application, attachment organization) are covered. Minor gaps like lacking a delete property or blank document creation are acceptable given the server's focus.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Search and reason over your Obsidian-style Markdown vault, right from ChatGPT.
Connect AI assistants to your GitHub-hosted Obsidian vault to seamlessly access, search, and analy…
Persistent memory and knowledge management for AI agents with semantic search and 50+ tools.
Persistent docs and memory for AI agents — read, write, organize & search a shared workspace.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/sunub/obsidian-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
