2026.10.06
obsidian-mcp-server: MCP Access to an Obsidian Vault
obsidian-mcp-server exposes Obsidian vault operations through MCP, including search, note editing, tags, frontmatter, scoped access, and deletion consent.
What it does
obsidian-mcp-server is an MCP server for Obsidian vaults. Through Obsidian’s Local REST API plugin, MCP-compatible clients can read, search, and modify notes instead of treating the vault as a passive document collection. It can run as a STDIO process or as a local Streamable HTTP server, making it relevant to AI workflows built around Markdown knowledge bases.
Its defining feature is targeted editing. In addition to raw and structured note reads, the tools can address a heading, block, or frontmatter field and append, prepend, replace, or otherwise update only that target. Tags can be managed in frontmatter, inline body content, or both. Individual frontmatter keys can also be retrieved, set, or deleted.
Documented capabilities
The README lists 14 tools and three resource types. The toolset includes recursive note listing, text and JSONLogic search, and BM25-ranked Omnisearch when that plugin was reachable at startup. Writing features cover note creation, whole-file overwrite, section-level edits, and literal or regular-expression replacement. Resources include vault content, tag snapshots, and status information through obsidian://vault/{+path}, obsidian://tags, and obsidian://status.
Access can be scoped by folders. The README describes read and write scope controls, and says that OBSIDIAN_READ_PATHS filters listings and tag results to readable content. Command-palette tools are opt-in through OBSIDIAN_ENABLE_COMMANDS. Deletion has an additional control: the v3.6.1 release notes say that a server-stored consent record must be redeemed for the delete to proceed. The same release requires stateful sessions for HTTP startup; this does not affect STDIO.
Who it suits
The project is a reasonable fit for people who already use Obsidian for personal knowledge, project material, or documentation and want an AI client to perform bounded vault operations. Users comfortable with MCP, Obsidian plugins, and local service configuration will be better positioned to deploy it. If the goal is strictly read-only question answering, its write, command, and deletion features may be more capability than necessary.
Limits and deployment considerations
The first dependency is Obsidian’s Local REST API plugin. Omnisearch is explicitly conditional on the plugin being reachable during startup, so BM25 search should not be assumed in every installation. STDIO and HTTP also represent different deployment paths, and the stateful HTTP session requirement should be checked against the chosen client and any proxy arrangement.
Write operations, replacements, command execution, and deletion can change a local knowledge base. The release adds a consent-record check for deletion, but the supplied sources do not establish a complete backup model, recovery plan, or security boundary for every deployment. Before adoption, define readable and writable folders, enable command tools only when needed, and test path handling, frontmatter behavior, and deletion flows against a non-critical vault.
Repository metadata identifies the project as Apache License 2.0 and not archived. That does not establish compatibility with every operating environment. The supplied material does not confirm minimum hardware requirements, performance figures, or a complete platform compatibility matrix, so those points remain for adopters to verify.
Sources
Sources checked: 2026-10-06