obsidian-mcp-serverは、AIエージェントがObsidian VaultのMarkdownドキュメントを照会、検索、要約できるようにするMCPサーバーです。
このプロジェクトは単にドキュメントを読み取るだけでなく、transformers.jsを活用したローカルハイブリッド検索機能を提供し、ターミナルから即座にVaultと対話できる対話型CLI AI Agent UIを内蔵しています。
🔍 ハイブリッド検索: キーワード検索とセマンティック（ベクトル）検索を組み合わせ、RRF（Reciprocal Rank Fusion）とリランキングを通じて最適な結果を提供。
🚀 Zero-Dependency ローカルAI: @huggingface/transformersを使用して、埋め込みおよびリランキングモデルをNode.jsプロセス内で直接実行（外部APIサーバー不要）。
💬 内蔵CLIエージェント: MCPツールを活用してVaultの内容について質問し、回答を得られるターミナルベースのUIを提供。詳細を見る
📦 トークン最適化: AIエージェントのトークン使用量を制御するための多様な圧縮モードと出力制限機能を提供。
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 Fusion: 2つの検索結果の順位をReciprocal Rank Fusionアルゴリズムで統合。
Local Reranking: 統合された上位結果を BGE Reranker モデルで再評価し、最終順位を決定。
モデルがインストールされていない場合は自動的にキーワード専用モードで動作し、ターミナルに npx @sunub/obsidian-mcp-server setup の実行を推奨するメッセージを表示します。
このプロジェクトには、Obsidian Vaultに最適化されたターミナルベースのAIチャットインターフェースが内蔵されています。
RAG統合: 質問時に自動的にVaultから関連コンテキストを収集し、LLMに伝達します。
リアルタイムストリーミング: LLMの回答と「思考プロセス()」をリアルタイムでレンダリングします。
スラッシュコマンド: /search, /read, /index などのMCPツールをCLIから直接コマンドとして呼び出し可能。
マルチMCP管理: 接続されたすべてのMCPサーバーの状態とツールリストを監視します。
チャットモデルサーバーの起動: llama.cpp や Ollama などのサーバーをOpenAI互換モードで起動します。
例: 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: ベクトルDBの再インデックスを強制実行
/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
