Obsidian MCP Server
The Obsidian MCP Server enables AI agents to perform advanced knowledge discovery and analysis across an Obsidian vault through three main tools:
Search Obsidian Vault: Advanced search functionality with filters for text/regex queries, tags (AND/OR logic), titles (AND/OR logic), dates (creation/modification), folder paths, and pagination options. Retrieve full content or contextual snippets.
Get Obsidian Note Content: Fetch the complete content and metadata of a specific note by its file path.
Browse Obsidian Vault Structure: Explore the directory structure of the vault, with options to include files and enable recursive directory listing.
These capabilities can be combined for complex workflows like gap analysis, risk assessment, action item tracking, and cross-referencing knowledge.
Suggested for securely managing API keys and environment variables without hardcoding them into scripts or committing them to version control.
Enables AI agents to perform knowledge discovery and analysis across an Obsidian vault, offering powerful search capabilities with filtering by path, title, tags, dates, and regex patterns, as well as the ability to retrieve full note content and browse vault structure.
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 Serversearch my vault for notes tagged 'research' from the last week and include full content"
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
An MCP (Model Context Protocol) server that enables AI agents to perform sophisticated knowledge discovery and analysis across your Obsidian vault through the Local REST API plugin.
Why This Matters
This server transforms your Obsidian vault into a powerful knowledge base for AI agents, enabling complex multi-step workflows like:
"Retrieve notes from my 'Projects/Planning' folder containing 'roadmap' or 'timeline' in titles, created after April 1st, then analyze them for any blockers or dependencies and present a consolidated risk assessment with references to the source notes"
"Find all notes tagged with 'research' or 'analysis' from the last month, scan their content for incomplete sections or open questions, then cross-reference with my 'Team/Expertise' notes to suggest which colleagues could help address each gap"
"Get the complete content of meeting notes from 'Leadership/Quarterly' containing 'budget' or 'headcount', analyze them for action items assigned to my department, and create a chronological timeline with source note references"
The server's advanced filtering, regex support, and full content retrieval capabilities allow agents to perform nuanced knowledge work that would take hours manually.
Related MCP server: Obsidian Local REST API MCP Server
Prerequisites
Install the Obsidian Local REST API plugin in your Obsidian vault
Configure and enable the plugin in Obsidian settings
Note the API URL (default:
https://localhost:27124) and API key if you've set one
Installation
From PyPI (Recommended)
# Install from PyPI
pip install obsidian-api-mcp-server
# Or with uv
uv pip install obsidian-api-mcp-serverAdd to MCP Configuration
Add to your MCP client configuration (e.g., 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"
}
}
}
}From Source (Development)
# 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 .Configuration
Set environment variables for the 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"Important Security Note: Avoid hardcoding your OBSIDIAN_API_KEY directly into scripts or committing it to version control. Consider using a .env file (which is included in the .gitignore of this project) and a library like python-dotenv to manage your API key, or use environment variables managed by your operating system or shell.
Note: The server defaults to HTTPS and disables SSL certificate verification for self-signed certificates commonly used with local Obsidian instances. For HTTP connections, set OBSIDIAN_API_URL="http://localhost:27123".
Usage
Run the MCP server:
obsidian-mcpAvailable Tools
The server provides three powerful tools:
search_vault- Advanced search with flexible filters and full content retrieval:query- Text or regex search across note content (optional)query_type- Search type: "text" (default) or "regex"search_in_path- Limit search to specific folder pathtitle_contains- Filter by text in note titles (string, array, or JSON string)title_match_mode- How to match multiple terms: "any" (OR) or "all" (AND)tag- Filter by tag (string, array, or JSON string - searches frontmatter and inline #tags)tag_match_mode- How to match multiple tags: "any" (OR) or "all" (AND)context_length- Amount of content to return (set high for full content)include_content- Boolean to retrieve complete content of all matching notescreated_since/until- Filter by creation datemodified_since/until- Filter by modification datepage_size- Results per pagemax_matches_per_file- Limit matches per note
Key Features:
When no
queryis provided, automatically returns full content for filter-only searchesinclude_content=Trueforces full content retrieval for any searchSupports regex patterns for complex text matching (OR conditions, case-insensitive search, etc.)
get_note_content- Retrieve complete content and metadata of a specific note by pathbrowse_vault_structure- Navigate vault directory structure efficiently:path- Directory to browse (defaults to vault root)include_files- Boolean to include files (default: False, folders only for speed)recursive- Boolean to browse all nested directories
Example Use Cases
Basic Searches
Find notes by title in a specific folder:
search_vault( search_in_path="Work/Projects/", title_contains="meeting" )Find notes with multiple title terms (OR logic):
search_vault( title_contains=["foo", "bar", "fizz", "buzz"], title_match_mode="any" # Default )Find notes with ALL title terms (AND logic):
search_vault( title_contains=["project", "2024"], title_match_mode="all" )Get all recent notes with full content:
search_vault( modified_since="2025-05-20", include_content=True )Text search with context:
search_vault( query="API documentation", search_in_path="Engineering/", context_length=500 )Search by tag:
search_vault( tag="project" )Regex search for OR conditions:
search_vault( query="foo|bar", query_type="regex", search_in_path="Projects/" )Regex search for tasks assigned to specific people:
search_vault( query="(TODO|FIXME|ACTION).*@(alice|bob)", query_type="regex", search_in_path="Work/Meetings/" )
Advanced Multi-Step Workflows
These examples demonstrate how agents can chain together sophisticated knowledge discovery tasks:
Strategic Project Analysis:
# 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 )Agent can then analyze dependencies, identify risks, and recommend resource allocation
Meeting Action Item Mining:
# 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
)Agent scans content for action items, extracts assignments, and creates chronological tracking
Research Gap Analysis:
# 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
)Agent identifies knowledge gaps and suggests team members who could help
Vault Structure Exploration:
# Quick organizational overview
browse_vault_structure(recursive=True)
# Deep dive into specific areas
browse_vault_structure(
path="Projects/CurrentSprint/",
include_files=True,
recursive=True
)Tag-Based Knowledge Mapping:
# 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"
)Development
# 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.pyLicense
This project is licensed under the MIT License - see the LICENSE file for details.
Available Tools
3 toolsbrowse_vault_structureARead-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
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.
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.
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.
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.
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.
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_contentARead-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
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.
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.
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.
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.
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.
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_vaultARead-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 | Description | 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
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.
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.
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.
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.
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.
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. Dates show when Glama detected each change.
3 tool updates
v1.0.0- First observed
browse_vault_structure - First observed
get_note_content - First observed
search_vault
TDQS
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.
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.
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.
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
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Connect AI assistants to your GitHub-hosted Obsidian vault to seamlessly access, search, and analy…
Search your Obsidian vault to quickly find notes by title or keyword, summarize related content, a…
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
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.
Related MCP Servers
- AlicenseBqualityFmaintenanceA 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.52636MIT
- AlicenseAqualityBmaintenanceA 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.13549MIT
- AlicenseAqualityDmaintenanceEmpowers 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.1619MIT
- AlicenseNot gradedqualityDmaintenanceA 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.5MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/pmmvr/obsidian-api-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server