Obsidian Omnisearch MCP Server
Provides searchable access to Obsidian vault notes through the Omnisearch plugin, returning absolute file paths to matching notes based on search queries
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 Omnisearch MCP Serversearch for meeting notes about Q3 planning"
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.
MCP Server Obsidian Omnisearch
A FastMCP-based server that provides Obsidian vault search functionality through a REST API interface.
Overview
This project implements a search service that allows you to search through Obsidian vault notes programmatically. It uses FastMCP to expose the search functionality as a tool that can be integrated with other services.
Related MCP server: Obsidian MCP Server
Features
Search through Obsidian vault notes
REST API integration
Returns absolute paths to matching notes
Easy integration with FastMCP tools
Prerequisites
Python 3.x
Obsidian with Omnisearch plugin installed and running
FastMCP library
Active Obsidian vault
Installation
Installing via Smithery
To install MCP Server Obsidian Omnisearch for Claude Desktop automatically via Smithery:
npx -y @smithery/cli install @anpigon/mcp-server-obsidian-omnisearch --client claudeManual Installation
Clone the repository:
git clone https://github.com/anpigon/mcp-server-obsidian-omnisearch.git
cd mcp-server-obsidian-omnisearchInstall dependencies:
uv installConfiguration
The Obsidian vault path is now provided as a command line argument when running the server:
python server.py /path/to/your/obsidian/vaultUsage
Obsidian Omnisearch API
You need the Obsidian Omnisearch community plugin running: https://publish.obsidian.md/omnisearch/Inject+Omnisearch+results+into+your+search+engine
Claude Desktop
On MacOS: ~/Library/Application\ Support/Claude/claude_desktop_config.json
On Windows: %APPDATA%/Claude/claude_desktop_config.json
{
"mcpServers": {
"obsidian-omnisearch": {
"command": "uv",
"args": [
"--directory",
"<dir_to>/mcp-server-obsidian-omnisearch",
"run",
"mcp-server-obsidian-omnisearch",
"/path/to/your/obsidian/vault"
]
}
}
}{
"mcpServers": {
"obsidian-omnisearch": {
"command": "uvx",
"args": [
"mcp-server-obsidian-omnisearch",
"/path/to/your/obsidian/vault"
]
}
}
}API Reference
Search Notes
Function:
obsidian_notes_search(query: str)Description: Searches Obsidian notes and returns absolute paths to matching notes
Parameters:
query: Search query string
Returns: List of absolute paths to matching notes
Development
Building and Publishing
To prepare the package for distribution:
Sync dependencies and update lockfile:
uv syncBuild package distributions:
uv buildThis will create source and wheel distributions in the dist/ directory.
Publish to PyPI:
uv publishNote: You'll need to set PyPI credentials via environment variables or command flags:
Token:
--tokenorUV_PUBLISH_TOKENOr username/password:
--username/UV_PUBLISH_USERNAMEand--password/UV_PUBLISH_PASSWORD
Debugging
Since MCP servers run over stdio, debugging can be challenging. For the best debugging experience, we strongly recommend using the MCP Inspector.
You can launch the MCP Inspector via npm with this command:
npx @modelcontextprotocol/inspector uv --directory /path/to/mcp-server-obsidian-omnisearch run mcp-server-obsidian-omnisearchUpon launching, the Inspector will display a URL that you can access in your browser to begin debugging.
You can also watch the server logs with this command:
tail -n 20 -f ~/Library/Logs/Claude/mcp-server-mcp-server-obsidian-omnisearch.logDependencies
FastMCP
requests
urllib
License
This project is licensed under the MIT License - see the LICENSE file for details.
Contributing
Contributions are welcome! Please feel free to submit a Pull Request.
Available Tools
2 toolsobsidian_notes_searchB
Search Obsidian(옵시디언) notes and return absolute paths to the matching notes. The returned paths can be used with the read_note tool to view the note contents.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It describes the action (search) and output (absolute paths), but lacks details on behavioral traits such as search scope (e.g., full-text, metadata), performance (e.g., speed, limits), error handling, or authentication needs. This is a significant gap for a tool with no annotation coverage.
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 appropriately sized and front-loaded: two sentences that directly state the tool's purpose and usage. Every sentence earns its place by providing essential information without waste, making it efficient and easy to understand.
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 (a search tool with no output schema and no annotations), the description is incomplete. It explains the basic purpose and output format but lacks critical context such as search behavior, result limitations, error cases, or integration details with the sibling tool. This leaves gaps for an AI agent to understand how to use it 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?
The input schema has 1 parameter ('query') with 0% description coverage, meaning the schema provides no details about it. The description does not add any semantic information about the 'query' parameter, such as its format, syntax, or examples. This leaves the parameter largely undocumented, failing to compensate for the low schema coverage.
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 notes and return absolute paths to the matching notes.' It specifies the verb (search), resource (Obsidian notes), and output (absolute paths). However, it does not explicitly differentiate from its sibling 'read_note' beyond mentioning that the returned paths can be used with it, which is more of a usage hint than a distinction.
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 context for usage: 'The returned paths can be used with the read_note tool to view the note contents.' This indicates when to use this tool (to find notes) versus its sibling (to read them). However, it lacks explicit exclusions or alternatives, such as when not to use it or if there are other search methods.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
read_noteC
Read and return the contents of an Obsidian note file.
| Name | Required | Description | Default |
|---|---|---|---|
| filepath | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions reading and returning contents, which implies a read-only operation, but doesn't specify error handling (e.g., what happens if the file doesn't exist), permissions required, or format of returned data. This leaves significant gaps for a tool with no annotation coverage.
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 a single, efficient sentence that directly states the tool's function without unnecessary words. It's appropriately sized and front-loaded, making it easy to parse quickly.
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 lack of annotations and output schema, the description is insufficient for a tool that reads files. It doesn't cover error cases, return format, or parameter details, leaving the agent with incomplete information to use the tool effectively in a real-world context.
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?
The schema description coverage is 0%, and the description doesn't explain the 'filepath' parameter beyond what's implied by the tool name. It doesn't specify the expected format (e.g., relative vs absolute path, file extension requirements) or provide examples, failing to compensate for the lack of schema documentation.
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 action ('Read and return the contents') and resource ('an Obsidian note file'), making the tool's purpose immediately understandable. However, it doesn't differentiate from the sibling tool 'obsidian_notes_search', which likely serves a different purpose (searching vs reading specific 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 provides no guidance on when to use this tool versus alternatives like 'obsidian_notes_search', nor does it mention any prerequisites or contextual constraints. It merely states what the tool does without indicating appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
TDQS
The two tools have completely distinct purposes: one searches for notes and returns paths, while the other reads the content of a specific note. There is no overlap or ambiguity between them.
Both tools follow a consistent snake_case naming pattern with clear verb_noun structure (obsidian_notes_search, read_note). The naming is predictable and readable throughout.
With only two tools, the server feels thin for its purpose of Obsidian Omnisearch. While the tools cover basic search and read operations, the scope suggests more functionality (e.g., create, update, delete notes, or advanced search features) would be expected.
The server is severely incomplete for an Obsidian search domain. It lacks any CRUD operations (create, update, delete notes) and advanced search capabilities (e.g., filtering by tags, dates). Agents will hit dead ends when trying to perform common 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
Search your Obsidian vault to quickly find notes by title or keyword, summarize related content, a…
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…
Serve a folder of Markdown notes as an MCP server: hybrid search, reading, and sourced answers.
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceProvides a standardized interface for AI assistants to interact with Obsidian vaults through a local REST API, enabling reading, writing, searching, and managing notes.66MIT
- AlicenseBqualityDmaintenanceEnables direct file system access to Obsidian vaults with auto-discovery, full-text search, and note operations. Supports reading, writing, and searching across Obsidian notes without requiring plugins or REST API.64,785MIT
- AlicenseNot gradedqualityCmaintenanceEnables AI assistants to search, read, and analyze Obsidian notes via the Local REST API.2018ISC
- AlicenseNot gradedqualityDmaintenanceEnables users to search, list, and read notes in an Obsidian vault via a CLI or HTTP API, integrating with Obsidian for note management.225MIT
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/anpigon/mcp-server-obsidian-omnisearch'
If you have feedback or need assistance with the MCP directory API, please join our Discord server