Obsidian MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| DEBUG | No | Enable debug logging | false |
| MCP_PORT | No | Port for HTTP mode | 3000 |
| MCP_TRANSPORT | No | Transport mode for the server: 'stdio' or 'http' | stdio |
| OBSIDIAN_API_KEY | Yes | API Key from Obsidian's Local REST API settings | |
| OBSIDIAN_API_URL | No | Obsidian REST API URL | http://127.0.0.1:27123 |
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": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| vault_get_fileA | Get the content of a file from the Obsidian vault. Can return raw markdown, parsed JSON with metadata (tags, frontmatter, stats), or a document map showing headings, blocks, and frontmatter fields. |
| vault_create_fileA | Create a new file in the vault or completely replace an existing file's content. Use this when you want to write the entire file content at once. |
| vault_append_to_fileA | Append content to the end of an existing file. If the file doesn't exist, it will be created. Use this to add content without replacing existing content. |
| vault_patch_fileA | Partially update a file by inserting content relative to a heading, block reference, or frontmatter field. Operations: append (after target), prepend (before target), or replace. Useful for updating specific sections without rewriting the entire file. |
| vault_delete_fileA | Delete a file from the Obsidian vault. This operation cannot be undone. |
| vault_listA | List files and directories in the Obsidian vault. Returns a formatted list showing directories (ending with /) and files. Use this to explore the vault structure. |
| search_simpleA | Perform a simple text search across all files in the vault. Returns matching files with context around each match. Best for straightforward text searches. |
| search_advancedA | Perform an advanced search using Dataview DQL or JsonLogic. Dataview is best for querying metadata and frontmatter (e.g., "TABLE FROM #tag"). JsonLogic is best for complex logical queries on note properties. |
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 8 tools
Every tool has a clearly distinct purpose with no ambiguity. The two search tools are well-differentiated (advanced vs. simple), and the file operation tools each handle specific actions (create, get, append, patch, delete, list) without overlap. Descriptions clearly indicate when to use each tool.
All tools follow a consistent verb_noun pattern with snake_case throughout. The 'vault_' prefix groups related file operations, while 'search_' prefixes distinguish query tools, creating a predictable and readable naming convention across all 8 tools.
8 tools is well-scoped for an Obsidian vault management server. This provides complete coverage for core operations (search, file CRUD, vault exploration) without being overwhelming. Each tool earns its place with clear utility for the domain.
The toolset provides complete coverage for Obsidian vault operations. It includes search capabilities (simple and advanced), full file lifecycle management (create, get, append, patch, delete), and vault exploration (list). No obvious gaps exist for the stated purpose of managing an Obsidian vault.