The Obsidian Local REST MCP server bridges an AI client to Obsidian through the Local REST API community plugin. It is one of several ways to get a vault in front of Claude, and the honest position is that it is not always the one you want.
What it actually does
The plugin exposes an HTTP API from inside Obsidian; this server translates that into MCP tools. The agent can read and write notes, use Obsidian’s own search rather than plain text matching, and reach features that live in the application rather than in the files: templates, the link graph, and plugin-provided behaviour.
Practical patterns:
- ‘Search my vault for everything about this project, using Obsidian search syntax.’
- ‘Create a note from my daily template and fill in today’s meetings.’
- ‘What links to this note, and which of those are stale?‘
Why use it
The case for this over reading the folder directly is Obsidian’s own capabilities. Search that understands your syntax, templates that execute properly, and the link graph, which is genuinely useful and does not exist at the filesystem level. If your vault’s value is in its connections rather than its file contents, that difference matters.
Gotchas
For most people, the Filesystem server is the simpler answer: no plugin, no API key, no requirement that Obsidian be open, and it reads the same Markdown. Reach for this one when you have hit a specific feature you need. Obsidian must be running, which rules out headless or scheduled use. The API key grants full vault access, so treat it accordingly. And note that Local REST API 5.x started serving MCP directly, so check your plugin version first: you may not need a bridge at all.