de en es ja ko ru zh

Obsidian MCP Server

Name: Obsidian MCP Server
Author: pmmvr

by pmmvr

Overview Schema Source Related Servers Discussions Admin

Python

Local

Obsidian MCP サーバー

AI エージェントがローカル REST API プラグインを通じて Obsidian Vault 全体で高度な知識の検出と分析を実行できるようにする MCP (モデルコンテキストプロトコル) サーバー。

これがなぜ重要なのか

このサーバーは、Obsidian Vault を AI エージェントの強力な知識ベースに変換し、次のような複雑な複数ステップのワークフローを可能にします。

「4月1日以降に作成された、タイトルに「ロードマップ」または「タイムライン」を含む「プロジェクト/計画」フォルダからメモを取得し、ブロックや依存関係を分析し、ソースメモへの参照を含む統合リスク評価を提示します。」
「先月の「調査」または「分析」のタグが付けられたすべてのメモを検索し、その内容を調べて未完了のセクションや未解決の質問を探し、「チーム/専門知識」のメモと相互参照して、各ギャップの解決に役立つ同僚を提案してください。」
「『リーダーシップ/四半期』から『予算』や『人員』を含む会議メモの完全な内容を取得し、自分の部門に割り当てられたアクション項目を分析し、ソースメモの参照を含む時系列タイムラインを作成します。」

サーバーの高度なフィルタリング、正規表現のサポート、完全なコンテンツ取得機能により、エージェントは手動では何時間もかかる微妙な知識作業を実行できます。

Related MCP server: Obsidian Local REST API MCP Server

前提条件

Obsidian VaultにObsidian Local REST APIプラグインをインストールします
Obsidianの設定でプラグインを設定して有効化する
API URL（デフォルト： https://localhost:27124 ）とAPIキー（設定している場合）をメモします。

インストール

PyPIから（推奨）

# Install from PyPI
pip install obsidian-api-mcp-server

# Or with uv
uv pip install obsidian-api-mcp-server

MCP構成に追加

MCP クライアント構成 (例: Claude Desktop) に追加します。

{
  "mcpServers": {
    "obsidian-api-mcp-server": {
      "command": "uvx",
      "args": [
        "--from",
        "obsidian-api-mcp-server>=1.0.1",
        "obsidian-api-mcp"
      ],
      "env": {
        "OBSIDIAN_API_URL": "https://localhost:27124",
        "OBSIDIAN_API_KEY": "your-api-key-here"
      }
    }
  }
}

ソースから（開発）

# Clone the repository
git clone https://github.com/pmmvr/obsidian-api-mcp-server
cd obsidian-api-mcp-server

# Install with uv
uv pip install -e .

# Or with pip
pip install -e .

構成

Obsidian API の環境変数を設定します。

# Required: Obsidian API URL (HTTPS by default)
export OBSIDIAN_API_URL="https://localhost:27124"  # Default

# Optional: API key if you've configured authentication
export OBSIDIAN_API_KEY="your-api-key-here"

重要なセキュリティ上の注意： OBSIDIAN_API_KEYをスクリプトに直接ハードコードしたり、バージョン管理にコミットしたりすることは避けてください。API キーの管理には、 .envファイル（このプロジェクトの.gitignoreに含まれています）とpython-dotenvなどのライブラリを使用するか、オペレーティングシステムまたはシェルで管理されている環境変数を使用することを検討してください。

注：サーバーはデフォルトでHTTPSを使用し、ローカルObsidianインスタンスで一般的に使用される自己署名証明書のSSL証明書検証を無効にします。HTTP接続の場合は、 OBSIDIAN_API_URL="http://localhost:27123"を設定してください。

使用法

MCP サーバーを実行します。

obsidian-mcp

利用可能なツール

サーバーは 3 つの強力なツールを提供します。

search_vault - 柔軟なフィルターと完全なコンテンツ取得を備えた高度な検索:
- query - ノートの内容全体にわたるテキストまたは正規表現の検索（オプション）
- query_type - 検索タイプ:「テキスト」(デフォルト) または「正規表現」
- search_in_path - 特定のフォルダパスに検索を制限する
- title_contains - ノートタイトルのテキストでフィルタリングします（文字列、配列、または JSON 文字列）
- title_match_mode - 複数の用語を一致させる方法:「いずれか」(OR) または「すべて」(AND)
- tag - タグでフィルタリング（文字列、配列、または JSON 文字列 - フロントマターとインライン #tags を検索）
- tag_match_mode - 複数のタグを一致させる方法:「いずれか」(OR) または「すべて」(AND)
- context_length - 返されるコンテンツの量（完全なコンテンツの場合は高く設定）
- include_content - 一致するすべてのノートの完全なコンテンツを取得するためのブール値
- created_since/until - 作成日でフィルタリング
- modified_since/until - 変更日でフィルタリング
- page_size - ページあたりの結果数
- max_matches_per_file - ノートごとの一致数を制限する
主な特徴:
- queryが指定されていない場合は、フィルターのみの検索で完全なコンテンツを自動的に返します。
- include_content=Trueすべての検索で完全なコンテンツ取得を強制します。
- 複雑なテキストマッチングのための正規表現パターンをサポートします (OR 条件、大文字と小文字を区別しない検索など)
get_note_content - パスで特定のノートの完全なコンテンツとメタデータを取得します
browse_vault_structure - ボールトのディレクトリ構造を効率的にナビゲートします。
- path - 参照するディレクトリ（デフォルトは Vault ルート）
- include_files - ファイルを含めるかどうかのブール値（デフォルト: False、速度のためにフォルダーのみ）
- recursive - ネストされたすべてのディレクトリを参照するためのブール値

使用例

基本検索

特定のフォルダー内のタイトルでノートを検索します。

search_vault(
  search_in_path="Work/Projects/",
  title_contains="meeting"
)

複数のタイトル用語を含むノートを検索します (OR ロジック):

search_vault(
  title_contains=["foo", "bar", "fizz", "buzz"],
  title_match_mode="any"  # Default
)

すべてのタイトル用語を含むノートを検索します (AND ロジック):
```
search_vault(
  title_contains=["project", "2024"],
  title_match_mode="all"
)
```

完全な内容を含む最近のメモをすべて取得します。

search_vault(
  modified_since="2025-05-20",
  include_content=True
)

コンテキストによるテキスト検索:

search_vault(
  query="API documentation",
  search_in_path="Engineering/",
  context_length=500
)

タグで検索:
```
search_vault(
  tag="project"
)
```

OR条件の正規表現検索:

search_vault(
  query="foo|bar",
  query_type="regex",
  search_in_path="Projects/"
)

特定の人に割り当てられたタスクの正規表現検索:

search_vault(
  query="(TODO|FIXME|ACTION).*@(alice|bob)",
  query_type="regex",
  search_in_path="Work/Meetings/"
)

高度なマルチステップワークフロー

これらの例は、エージェントが高度な知識発見タスクを連鎖させる方法を示しています。

戦略プロジェクト分析:

# Step 1: Get all project documentation
search_vault(
  search_in_path="Projects/Infrastructure/",
  title_contains=["planning", "requirements", "architecture"],
  title_match_mode="any",
  include_content=True
)

# Step 2: Find related technical discussions
search_vault(
  tag=["infrastructure", "technical-debt"],
  tag_match_mode="any",
  modified_since="2025-04-01",
  include_content=True
)

エージェントは依存関係を分析し、リスクを特定し、リソースの割り当てを推奨することができます。

会議のアクションアイテムマイニング:

# Get all recent meeting notes with full content
search_vault(
  search_in_path="Meetings/",
  title_contains=["standup", "planning", "retrospective"],
  title_match_mode="any",
  created_since="2025-05-01",
  include_content=True
)

エージェントはコンテンツをスキャンしてアクション項目を探し、割り当てを抽出し、時系列の追跡を作成します。

研究ギャップ分析:

# Find research notes with questions or gaps
search_vault(
  query="(TODO|QUESTION|INVESTIGATE|UNCLEAR)",
  query_type="regex",
  tag=["research", "analysis"],
  tag_match_mode="any",
  include_content=True
)

# Cross-reference with team expertise
search_vault(
  search_in_path="Team/",
  tag=["expertise", "skills"],
  tag_match_mode="any",
  include_content=True
)

エージェントは知識のギャップを特定し、支援できるチームメンバーを提案します

金庫構造の探索:

# Quick organizational overview
browse_vault_structure(recursive=True)

# Deep dive into specific areas
browse_vault_structure(
  path="Projects/CurrentSprint/",
  include_files=True,
  recursive=True
)

タグベースの知識マッピング:

# Find notes with multiple tags (AND logic)
search_vault(
  tag=["project", "urgent"],
  tag_match_mode="all",
  include_content=True
)

# Find notes with any relevant tags (OR logic)
search_vault(
  tag=["architecture", "design", "implementation"],
  tag_match_mode="any",
  modified_since="2025-04-15"
)

発達

# Install with test dependencies
uv pip install -e ".[test]"

# Run the server
python -m obsidian_mcp.server

# Run tests
uv run behave features/blackbox_tests.feature
# Or use the test runner
python run_tests.py

ライセンス

このプロジェクトは MIT ライセンスに基づいてライセンスされています - 詳細についてはLICENSEファイルを参照してください。

Available Tools

3 tools

browse_vault_structureA

Read-only

Browse vault directory structure.

Args:
    path: Path to browse from (defaults to vault root)
    include_files: Include files in listing (default: False, folders only)
    recursive: List nested contents recursively

Name	Required	Description	Default
`include_files`	No
`path`	No
`recursive`	No

TDQS

A3.8/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already provide readOnlyHint=true and openWorldHint=false, indicating this is a safe read operation with deterministic results. The description adds valuable context about default behaviors (browsing from vault root, folders-only by default) and the recursive option, which goes beyond what annotations provide. No contradictions with annotations exist.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is perfectly structured: a clear purpose statement followed by a bullet-point style explanation of each parameter. Every sentence earns its place, with no wasted words. The information is front-loaded with the core purpose first.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a directory browsing tool with 3 parameters, no output schema, and good annotations, the description covers the essential behavior and parameters adequately. However, it doesn't describe the return format (e.g., what structure is returned, error conditions), which would be helpful given the lack of output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description carries full burden for parameter meaning. It successfully explains all three parameters: 'path' (starting location with default), 'include_files' (files inclusion toggle with default), and 'recursive' (nested listing). This compensates well for the schema's lack of descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb ('Browse') and resource ('vault directory structure'), making the purpose immediately understandable. It distinguishes from sibling tools like 'get_note_content' (which retrieves content) and 'search_vault' (which searches), but doesn't explicitly mention these distinctions in the description itself.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for exploring directory structure rather than retrieving content or searching, but doesn't provide explicit guidance on when to use this tool versus alternatives like 'search_vault'. The parameter descriptions suggest default behaviors (folders only, non-recursive), which gives some contextual hints.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_note_contentA

Read-only

Get the full content and metadata of a specific note by path.

Args:
    path: Full path to the note within the vault

Name	Required	Description	Default
`path`	Yes

TDQS

A3.6/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations provide readOnlyHint=true and openWorldHint=false, indicating a safe, read-only operation with a closed world. The description adds context by specifying 'full content and metadata,' which hints at the return format, but doesn't detail aspects like error handling, rate limits, or auth needs. No contradiction with annotations exists.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core purpose in the first sentence, followed by a concise parameter explanation. Every sentence earns its place with no wasted words, making it efficient and easy to parse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's low complexity (1 parameter, no output schema), annotations cover safety, and the description adds parameter semantics and purpose. However, it lacks details on return values, error cases, or how it differs from siblings, leaving some gaps for an AI agent to infer usage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage and 1 parameter, the description compensates by explaining 'path: Full path to the note within the vault,' adding meaning beyond the bare schema. It clarifies the parameter's purpose and format, though it could provide more examples or constraints.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Get the full content and metadata of a specific note by path.' It specifies the verb ('Get'), resource ('note'), and scope ('full content and metadata'), though it doesn't explicitly differentiate from sibling tools like 'browse_vault_structure' or 'search_vault' beyond the 'specific note by path' aspect.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage by specifying 'by path,' suggesting it's for retrieving a known note, but it doesn't provide explicit guidance on when to use this tool versus alternatives like 'search_vault' for unknown notes or 'browse_vault_structure' for exploring. No exclusions or prerequisites are mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_vaultA

Read-only

Search Obsidian vault for notes matching criteria.

Args:
    query: Text or regex pattern to search for
    query_type: "text" or "regex" 
    search_in_path: Limit search to specific folder
    title_contains: Filter by title (string or array)
    title_match_mode: "any" or "all" for multiple title terms
    tag: Filter by tag (string, array, or JSON string like title_contains)
    tag_match_mode: "any" or "all" for multiple tag terms
    context_length: Characters of context around matches
    include_content: Return full note content
    modified_since/until: Filter by modification date (YYYY-MM-DD)
    created_since/until: Filter by creation date (YYYY-MM-DD)
    page_size/page: Pagination controls
    max_matches_per_file: Limit matches per file

Name	Required	Default
`context_length`	No
`created_since`	No
`created_until`	No
`include_content`	No
`max_matches_per_file`	No
`modified_since`	No
`modified_until`	No
`page`	No
`page_size`	No
`query`	No
`query_type`	No	text
`search_in_path`	No
`tag`	No
`tag_match_mode`	No	any
`title_contains`	No
`title_match_mode`	No	any

TDQS

A3.5/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and openWorldHint=false, indicating this is a safe read operation with limited scope. The description adds useful context about what gets searched ('notes') and the types of criteria available, but doesn't disclose behavioral aspects like performance characteristics, rate limits, or error conditions. With annotations covering the safety profile, this earns a baseline score.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a clear purpose statement followed by a comprehensive parameter list. Every sentence earns its place by providing essential information. It could be slightly more concise by grouping related parameters, but overall it's efficient and front-loaded with the core functionality.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex search tool with 16 parameters and no output schema, the description does a good job explaining inputs but has gaps. It doesn't describe the return format (what the search results look like), error conditions, or performance considerations. The parameter explanations are excellent, but without output information or behavioral context, completeness is limited.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage (titles only, no descriptions), the description carries the full burden of explaining parameters. It provides detailed semantic information for all 16 parameters, including data types, formats, and usage examples (e.g., 'YYYY-MM-DD' for dates, 'text' or 'regex' for query_type). This fully compensates for the schema's lack of descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Search Obsidian vault for notes matching criteria.' This specifies the verb ('search'), resource ('Obsidian vault'), and target ('notes matching criteria'). However, it doesn't explicitly differentiate from sibling tools like 'browse_vault_structure' or 'get_note_content', which prevents a perfect score.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. There's no mention of sibling tools like 'browse_vault_structure' (for exploring structure) or 'get_note_content' (for retrieving specific note content), nor any context about when search is appropriate versus other approaches.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

3 tool updatesv1.0.0Aug 15, 2025
- First observedbrowse_vault_structure
- First observedget_note_content
- First observedsearch_vault

Deploy Server

Context All Your Agents Can ShareAgents share what they learn, hand off work, and hold it when you switch models. Start with 5 GB free.fulcradynamics.comAd

TDQS

A3.7/5.0

Scored 2026-04-18 10:00 across 3 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: browse_vault_structure is for exploring the file hierarchy, get_note_content retrieves a specific note's details, and search_vault performs complex queries across the vault. There is no overlap in functionality, making it easy for an agent to select the right tool.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern with snake_case: browse_vault_structure, get_note_content, and search_vault. The naming is predictable and readable, with no deviations in style or convention.

Tool Count3/5

With only 3 tools, the server feels thin for managing an Obsidian vault, which typically involves operations like creating, updating, or deleting notes. While the tools cover browsing, reading, and searching, the lack of write operations limits the scope, making it borderline for the domain.

Completeness2/5

The tool set is severely incomplete for an Obsidian vault management server. There are no tools for creating, updating, or deleting notes, which are core CRUD operations. This creates significant gaps that will likely cause agent failures when trying to perform basic note management tasks.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

Related MCP Connectors

Hint-Services-obsidian-github-mcp
ai.smithery
Connect AI assistants to your GitHub-hosted Obsidian vault to seamlessly access, search, and analy…
Note Taking Version Control File Systems
210
https://server.smithery.ai/@Hint-Services/obsidian-github-mcp/mcp
sunub-obsidian-mcp-server
ai.smithery
Search your Obsidian vault to quickly find notes by title or keyword, summarize related content, a…
Note Taking Search Text Summarization
22
https://server.smithery.ai/@sunub/obsidian-mcp-server/mcp
Artificial Wit AIOAuth
com.artificialwit
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
ERP Systems CRM Knowledge & Memory
2
https://api.artificialwit.com/mcp
Remote MCP A
com.remote-mcp.mcp
The Remote MCP server acts as a standardized bridge between LLM applications (like Claude, ChatGPT, and Cursor) and external services, enabling AI agents to access external tools and resources. Its primary capability is providing a centralized search tool to discover other MCP servers and their respective tools. Unlike local implementations, it runs remotely with OAuth authentication and permission controls for security.
Developer Tools Search Agent Orchestration
13
https://mcp.remote-mcp.com

Related MCP Servers

Obsidian Semantic MCP Server
Developer Tools Note Taking Content Management Systems
aaronsb
A
license
B
quality
F
maintenance
A server that consolidates 21+ Obsidian tools into 5 intelligent operations (vault, edit, view, workflow, system) with contextual workflow hints to help AI agents effectively interact with Obsidian.
Updated a year ago (2025-07-12 02:18 UTC)
5
26 npm
36
MIT
Obsidian Local REST API MCP
Note Taking File Systems Documentation Access
j-shelfwood
A
license
A
quality
B
maintenance
A bridge server that allows LLM tools to interact with an Obsidian vault through a local REST API, enabling file operations, note management, and metadata access through natural language.
Updated 24 days ago (2026-10-04 12:02 UTC)
13
13 npm
9
MIT
Advanced Obsidian MCP Server
Note Taking File Systems Developer Tools
ToKiDoO
A
license
A
quality
D
maintenance
Empowers AI agents to deeply understand and interact with Obsidian vaults through the Local REST API, enabling advanced features like vault structure discovery, graph analysis, command execution, and batch file operations.
Updated a year ago (2025-10-17 01:29 UTC)
16
18
MIT
Obsidian MCP Server
Note Taking File Systems Developer Tools
duquesnay
A
license
Not graded
quality
D
maintenance
A high-performance TypeScript server that enables interaction with Obsidian vaults through the Local REST API community plugin. It provides comprehensive tool discovery, intelligent resource caching, and unified access to both markdown notes and binary vault files like images and PDFs.
Updated 7 months ago (2026-03-14 05:01 UTC)
5
MIT