The Obsidian MCP Server enables AI agents to interact with an Obsidian Vault's Markdown documents, supporting search, retrieval, metadata management, semantic search via local LLMs, and file organization.
Search notes (vault → search): Keyword-based search with configurable result limits and content excerpts
Read specific notes (vault → read): Retrieve full content of a markdown file by filename
List all documents (vault → list_all): Get a complete list of all documents in the vault
Get vault stats (vault → stats): Retrieve file count, initialization state, and vault path
Collect context (vault → collect_context): Aggregate and synthesize content from multiple notes
Load memory (vault → load_memory): Load previously saved memory/context from the vault
Semantic (RAG) search (vault → search_vault_by_semantic): Vector-based semantic search using a local LLM embedding server
Index vault to vector DB (vault → index_vault_to_vectordb): Trigger full indexing into a LanceDB vector store, with automatic incremental indexing for file changes
Generate frontmatter properties (generate_property): Analyze document content and suggest metadata (title, tags, summary, slug, date, aliases, etc.)
Write frontmatter properties (write_property): Add or update key-value properties in a document's frontmatter
Create document with properties (create_document_with_properties): End-to-end workflow that reads a document, generates AI-based metadata, and writes it back
Organize attachments (organize_attachments): Scan a markdown file for linked images/attachments, move them to a structured folder (e.g., images/{Document Title}/), and update links in the document
Enables AI agents to explore and manage local Obsidian vault documents through tools for searching, reading, creating documents with auto-generated frontmatter properties, and organizing attachments by automatically moving linked files to appropriate folders.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Obsidian MCP Server search for notes about AI agents and knowledge bases"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
obsidian-mcp-server is an MCP server that allows AI agents to browse, search, and summarize Markdown documents in an Obsidian Vault.
Beyond simply reading documents, this project provides local hybrid search using transformers.js and includes an interactive CLI AI Agent UI that allows you to chat with your Vault directly from the terminal.
🔍 Hybrid Search: Combines keyword search with semantic (vector) search, providing optimal results through RRF (Reciprocal Rank Fusion) and Reranking.
🚀 Zero-Dependency Local AI: Uses @huggingface/transformers to run embedding and reranking models directly within the Node.js process (no external API server required).
💬 Built-in CLI Agent: Provides a terminal-based UI that uses MCP tools to ask questions about Vault content and receive answers. View Details
📦 Token Optimization: Offers various compression modes and output limits to control the AI agent's token usage.
Related MCP server: Obsidian MCP
Integrated Search (vault, action="search"): Performs keyword and semantic-based searches simultaneously to find highly relevant documents.
Read Document (vault, action="read"): Retrieves the content and metadata of a specific note.
List and Stats (vault, action="list_all"|"stats"): Checks the overall status and file list of the Vault.
Collect Context (vault, action="collect_context"): Generates high-density knowledge packets related to a specific topic.
Load Knowledge (vault, action="load_memory"): Recalls saved memory snapshots.
Frontmatter Management (generate_property|write_property): Generates and applies AI-based metadata.
Organize Attachments (organize_attachments): Automatically moves images within documents to a dedicated folder and updates links.
Node.js: v22.0.0 or higher
Obsidian Vault: You must know the absolute path.
To enable semantic search and reranking features, you must download the necessary local models using the command below:
# 로컬 임베딩 및 리랭킹 모델 설치
npx @sunub/obsidian-mcp-server setupOr, if you have already installed the package:
obsidian-mcp-server setupThis command downloads the Xenova/paraphrase-multilingual-MiniLM-L12-v2 (embedding) and Xenova/bge-reranker-base (reranking) models and saves them to the local cache.
Environment Variable | Default | Role | Required |
| — | Absolute path to the Obsidian Vault | Required |
|
| Chat model API endpoint for CLI UI | Required for CLI |
|
| Model name to use for chat | Required for CLI |
|
| Log level ( | Optional |
In each client configuration, modify env.VAULT_DIR_PATH to your own Vault path.
{
"mcpServers": {
"obsidian": {
"command": "npx",
"args": ["-y", "@sunub/obsidian-mcp-server@latest"],
"env": {
"VAULT_DIR_PATH": "/Users/username/Documents/MyVault"
}
}
}
}To capture semantic relationships that are difficult to find with traditional keyword search alone, it goes through the following pipeline:
Keyword Search: Extracts exact word matching results via the internal Indexer.
Vector Search: Searches for semantically similar chunks using LanceDB and transformers.js embeddings.
RRF Fusion: Merges the rankings of both search results using the Reciprocal Rank Fusion algorithm.
Local Reranking: Re-evaluates the merged top results with the BGE Reranker model to determine the final ranking.
If the models are not installed, it automatically operates in keyword-only mode and displays a message in the terminal recommending the execution of npx @sunub/obsidian-mcp-server setup.
This project includes a terminal-based AI chat interface optimized for Obsidian Vault.
RAG Integration: Automatically collects relevant context from the Vault when asked a question and passes it to the LLM.
Real-time Streaming: Renders the LLM's response and "thought process ()" in real-time.
Slash Commands: MCP tools such as /search, /read, and /index can be called directly as commands from the CLI.
Multi-MCP Management: Monitors the status and tool list of all connected MCP servers.
Run Chat Model Server: Start a server like llama.cpp or Ollama in OpenAI-compatible mode.
Example: llama-server -m models/gemma-2-9b-it.Q4_K_M.gguf --port 8080
Run CLI:
# 환경변수와 함께 실행
VAULT_DIR_PATH="/your/vault" LLM_API_URL="http://localhost:8080" npx @sunub/obsidian-mcp-server/search <keyword>: Execute hybrid search
/read "filename": Read a specific document
/stats: Check Vault status
/index: Force re-indexing of the vector DB
/tools: View a list of all available MCP tools
/help: View 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
