MCP Server for Obsidian: the 3 options
Two servers actually matter, they both go through the same plugin, and the only real decision is how much editing power you hand the model.

An MCP server for Obsidian lets an AI client — Claude Desktop, Cursor, or anything that speaks the Model Context Protocol — read, search, and edit the notes in your vault. There are really only two serious options, and they both reach your vault the same way: through Obsidian's Local REST API community plugin, not by touching your .md files on disk. The third pick on this page is a different animal — a multi-agent framework, not a vault connector — and I'll say when it's worth it.
Everything here runs locally over stdio, which is normal: about 90% of MCP servers run locally over stdio, and Obsidian servers are firmly in that camp. Nothing leaves your machine unless you make it.
The short answer: which one to install
Install mcp-obsidian (Obsidian Local REST API) if you want the simplest, most-battle-tested option. It's the Python community server (uvx mcp-obsidian), exposes 7 tools — list, read, search, patch, append, delete — and it's the one most tutorials assume. If you already have uv installed, you're a config block away from working.
Install obsidian-mcp-server by cyanheads if you care about what the agent can touch. It's the TypeScript server (npx -y obsidian-mcp-server@latest), ships 14 tools, and adds the things the Python one lacks: section-aware patch edits, folder-scoped permissions, a global read-only kill switch, and human-in-the-loop confirmation before a delete. It also supports an HTTP transport if you ever need it.
Both are community servers — there is no official first-party Obsidian MCP server, which is common: most MCP servers wrap someone else's product rather than being built by the vendor. That's fine here, because both are widely used and actively maintained.
How they compare
The headline differences, side by side:
| mcp-obsidian | obsidian-mcp-server | |
|---|---|---|
| Language / runner | Python, uvx | TypeScript, npx |
| Tools | 7 | 14 |
| Transport | stdio | stdio + HTTP |
| Edit granularity | patch by heading / block ref | section-aware patch, frontmatter, tags |
| Guardrails | none built in | read-only switch, folder scoping, delete confirm |
| Best when | you want the default, simplest setup | you want tight control over agent writes |
Both talk to the same Local REST API endpoint, so switching later is cheap — you swap the server block, not your workflow.
The prerequisite everyone skips: the Local REST API plugin
Neither server reads your files directly — they call a local HTTP endpoint that Obsidian exposes, so Obsidian must be running and the plugin installed first. Skip this and every tool call fails with a connection error, which is the single most common "the Obsidian MCP server doesn't work" report.
Do this once:
- In Obsidian, install the community plugin Local REST API and enable it.
- Open its settings and copy the API key it generates.
- Note the port — it defaults to
27124on127.0.0.1.
That API key is what the server authenticates with. Treat it like a password; anything holding it can edit your vault.
Copy-paste config (Claude Desktop / Cursor)
Here's the minimal, correct config for the Python server. Drop it into your client's MCP config (e.g. claude_desktop_config.json) and restart the client:
{
"mcpServers": {
"obsidian": {
"command": "uvx",
"args": ["mcp-obsidian"],
"env": {
"OBSIDIAN_API_KEY": "<your-obsidian-rest-api-key>",
"OBSIDIAN_HOST": "127.0.0.1",
"OBSIDIAN_PORT": "27124"
}
}
}
}
Paste the API key from the plugin into OBSIDIAN_API_KEY. If you left the plugin on defaults, HOST and PORT are already right and can be omitted. For the cyanheads server, the block is the same shape but command becomes npx and args become ["-y", "obsidian-mcp-server@latest"]. If editing JSON by hand isn't your thing, the config generator builds the block for you, or see the general walkthrough on how to add an MCP server.
Watch your tool budget
Before you add either server, count what you already have loaded. Clients like Cursor start degrading tool selection past roughly a 40-tool budget, and these servers spend 7 or 14 of it. That's not a lot on its own, but stack an Obsidian server on top of a filesystem server, a browser server, and GitHub, and you're over the line fast.
If your agent starts calling the wrong tool or ignoring one, the fix is usually fewer servers, not a bigger prompt — the math is laid out in Cursor's tool limit. For a vault, one Obsidian server is enough; you almost never need both installed at once.
When Agent-MCP fits instead
Reach for Agent-MCP only if your goal is orchestrating multiple AI agents against a shared knowledge base, not wiring a single vault to one client. It's a multi-agent collaboration framework with a shared knowledge graph and 12 tools — a heavier, different tool than a vault connector.
If you just want Claude to read and edit your notes, Agent-MCP is overkill; use one of the two servers above. If you're building a system where several specialized agents coordinate over MCP, it's the right shape. Don't install it expecting a drop-in Obsidian integration — that's not what it is.
For the broader picture of what these servers can do and how they rank, browse the best MCP servers list and the full capabilities breakdown.