obsidian-rag-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| obsidian_get_configA | Show the current configuration (vault path, embedding provider/model). The API key is never returned. |
| obsidian_indexA | Scan the vault and build/refresh the embedding index. Args: force: rebuild the index even if one already exists. |
| obsidian_searchA | Semantically search the vault for chunks related to Args: query: what to look for (natural language). top_k: number of results to return (1-20). |
| obsidian_ragA | Retrieve the most relevant Obsidian notes for Use this to analyze a user's message against what is stored in the vault: search first, then reason over the returned context. Args: question: the user's question / content to analyze. top_k: number of context chunks to retrieve (1-20). |
| obsidian_list_notesA | List the markdown notes in the vault. Args: keyword: optional filter; only notes whose path contains this string are returned. |
| obsidian_read_noteA | Read the full text of a note from the vault. Args: path: vault-relative markdown path, e.g. "Projects/MyProject.md". |
| obsidian_index_statusA | Report whether an index exists and matches the configured embedding model. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 7 tools
obsidian_search and obsidian_rag are heavily overlapping: both take a query/question and top_k to retrieve relevant vault content, with only a subtle framing difference. The other tools are distinct, but these two create real ambiguity for an agent.
Most tools follow an obsidian_verb pattern (obsidian_search, obsidian_list_notes, obsidian_read_note, obsidian_get_config), but obsidian_rag and obsidian_index_status break the convention with an acronym and a noun phrase. The shared prefix helps, but the pattern is inconsistent.
Seven tools is well-scoped for an Obsidian RAG server covering indexing, semantic retrieval, note listing/reading, status, and configuration. Each tool occupies a reasonable place in the workflow without obvious bloat.
The core RAG lifecycle is covered: build/refresh index, search and retrieve context, list/read notes, check index status, and view config. Minor omissions like an explicit index deletion or note write operations are outside the apparent read-only RAG scope.