obsidian-mcp-server 是一个 MCP 服务器，允许 AI 智能体查询、搜索和总结 Obsidian Vault 中的 Markdown 文档。
本项目不仅限于读取文档，还提供了基于 transformers.js 的本地混合搜索功能，并包含一个可以在终端直接与 Vault 对话的交互式 CLI AI Agent UI。
🔍 混合搜索： 结合关键词搜索与语义（向量）搜索，并通过 RRF (Reciprocal Rank Fusion) 和重排序 (Reranking) 提供最优结果。
🚀 零依赖本地 AI： 使用 @huggingface/transformers 在 Node.js 进程内直接运行嵌入和重排序模型（无需外部 API 服务器）。
💬 内置 CLI 智能体： 提供基于终端的 UI，利用 MCP 工具针对 Vault 内容进行提问并获取回答。查看详情
📦 Token 优化： 提供多种压缩模式和输出限制功能，以控制 AI 智能体的 Token 使用量。
Related MCP server: Obsidian MCP
综合搜索 (vault, action="search")：同时执行关键词和语义搜索，探索相关性最高的文档。
文档查阅 (vault, action="read")：查询特定笔记的正文及元数据。
全量列表及状态 (vault, action="list_all"|"stats")：查看 Vault 的整体状态和文件列表。
上下文收集 (vault, action="collect_context")：生成与特定主题相关的高密度知识包。
加载知识 (vault, action="load_memory")：调用已保存的内存快照。
Frontmatter 管理 (generate_property|write_property)：基于 AI 生成并应用元数据。
附件整理 (organize_attachments)：自动将文档内的图片移动到专用文件夹并更新链接。
Node.js: v22.0.0 或更高版本
Obsidian Vault: 必须知道其绝对路径。
要启用语义搜索和重排序功能，必须通过以下命令下载所需的本地模型。
# 로컬 임베딩 및 리랭킹 모델 설치
npx @sunub/obsidian-mcp-server setup或者如果已经安装了包：
obsidian-mcp-server setup此命令将下载 Xenova/paraphrase-multilingual-MiniLM-L12-v2（嵌入）和 Xenova/bge-reranker-base（重排序）模型并保存到本地缓存中。
环境变量 | 默认值 | 作用 | 是否必需 |
| — | Obsidian Vault 绝对路径 | 必需 |
|
| CLI UI 聊天模型 API 端点 | 使用 CLI 时必需 |
|
| 聊天使用的模型名称 | 使用 CLI 时必需 |
|
| 日志级别 ( | 可选 |
请在各客户端配置中将 env.VAULT_DIR_PATH 修改为您自己的 Vault 路径。
{
"mcpServers": {
"obsidian": {
"command": "npx",
"args": ["-y", "@sunub/obsidian-mcp-server@latest"],
"env": {
"VAULT_DIR_PATH": "/Users/username/Documents/MyVault"
}
}
}
}为了捕捉仅靠传统关键词搜索难以发现的语义关联，系统采用了以下流水线：
关键词搜索 (Keyword Search)：通过内部 Indexer 提取精确的单词匹配结果。
向量搜索 (Vector Search)：使用 LanceDB 和 transformers.js 嵌入技术搜索语义相似的块。
RRF 融合 (RRF Fusion)：使用 Reciprocal Rank Fusion 算法合并两种搜索结果的排名。
本地重排序 (Local Reranking)：使用 BGE Reranker 模型对合并后的前几名结果进行重新评估，确定最终排名。
如果未安装模型，系统将自动以纯关键词模式运行，并在终端显示建议执行 npx @sunub/obsidian-mcp-server setup 的提示。
本项目内置了针对 Obsidian Vault 优化的终端 AI 聊天界面。
RAG 集成：提问时自动从 Vault 收集相关上下文并传递给 LLM。
实时流式传输：实时渲染 LLM 的回答及“思考过程()”。
斜杠命令：支持在 CLI 中直接通过 /search、/read、/index 等命令调用 MCP 工具。
多 MCP 管理：监控所有已连接 MCP 服务器的状态和工具列表。
启动聊天模型服务器：启动一个兼容 OpenAI 协议的服务器，如 llama.cpp 或 Ollama。
例如：llama-server -m models/gemma-2-9b-it.Q4_K_M.gguf --port 8080
运行 CLI：
# 환경변수와 함께 실행
VAULT_DIR_PATH="/your/vault" LLM_API_URL="http://localhost:8080" npx @sunub/obsidian-mcp-server/search <keyword>: 执行混合搜索
/read "filename": 读取特定文档
/stats: 查看 Vault 状态
/index: 强制执行向量数据库重新索引
/tools: 查看所有可用的 MCP 工具列表
/help: 查看帮助
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
