Obsidian is the closest thing most knowledge workers have to a personal database. Thousands of Markdown files. A link graph. Tags. Templates. A daily note habit. The kind of structure that looks tidy from the inside and unreadable from the outside.
Claude, on its own, sees none of it. You can paste a note into the chat window and ask a question, sure. But that is not a knowledge system. That is glorified copy-paste. The whole point of Obsidian is that you have built up years of context. The whole point of Claude is to think with you. The piece in the middle, until late 2024, did not exist.
Then MCP shipped. And in 2026, connecting Obsidian to Claude is the cleanest version of the personal AI workflow most people are reaching for. There are two real paths. They optimize for different things. This is the practical guide for picking one and getting it working.
- Two install paths in 2026: Filesystem MCP (no plugin, talks to your Markdown files directly) or Local REST API + mcp-obsidian (richer, requires the Obsidian plugin and an API key).
- Filesystem MCP wins for most knowledge workers. Faster, lower memory, works when Obsidian is closed, no plugin to maintain.
- Use the REST API path when you need Obsidian’s own search index, template execution, or live link-graph updates inside the running app.
- Restart Claude Desktop fully after any config change. A window reload does not pick up new servers.
- Pair Obsidian MCP with a bookmarks MCP. Obsidian does not capture posts you save on X, Reddit, or LinkedIn. ContextBolt fills that gap so Claude sees both notes and saved content.
What an Obsidian MCP setup actually does
The Model Context Protocol is an open standard released by Anthropic in late 2024 that defines how AI clients talk to external tools. An MCP server exposes tools, the AI client (Claude Desktop, Cursor, ChatGPT in Developer Mode) calls them mid-conversation, and the results flow back into the model’s reasoning.
For Obsidian, that means Claude can list the files in your vault, read any note, search across notes, write new notes, and edit existing ones. Without copy-paste. Without exporting. Without you parking the question while you go find the right file. The vault becomes a live data source instead of a folder you visit when you remember to.
Two ecosystems serve this in 2026. The official Filesystem MCP server treats your vault as what it actually is on disk: a folder full of Markdown. The community Obsidian Local REST API plugin plus mcp-obsidian treats the vault as a running Obsidian instance and talks to it over an authenticated local HTTP API. Both work. They are good at different things.
Filesystem MCP vs Obsidian Local REST API: which one to pick
The Obsidian forum threads on this go back and forth, and most of the back-and-forth misses the framing. The question is not which one is better in the abstract. It is which one fits the work you do with your vault.
| Dimension | Filesystem MCP | Obsidian Local REST API + mcp-obsidian |
|---|---|---|
| Plugin required? | No | Yes (Local REST API community plugin) |
| Works when Obsidian is closed? | Yes | No |
| Read and write notes | Yes | Yes |
| Uses Obsidian’s own search index | No (greps files on disk) | Yes |
| Atomic note updates (patch by heading or block) | No | Yes |
| Triggers link graph updates live | No (needs Obsidian to re-scan on open) | Yes |
| Memory footprint | Low | Higher (Obsidian must run) |
| Auth model | Folder allowlist | API key in config |
| Best for | Daily knowledge work, drafting, retrieval | Power workflows, atomic edits, template execution |
The clean rule: if you mostly read notes and write new ones, Filesystem MCP. If you depend on Obsidian-specific features like Dataview queries, Templater scripts, or surgical edits to a single heading inside a long note, the REST API path is worth the plugin overhead.
Most setups I have seen in the wild start with Filesystem and never move. The richer features sound great in a demo. In practice, the friction of keeping Obsidian open and the plugin updated outweighs the wins for daily use.
Path 1: Filesystem MCP (the simple one)
This is the recommended starting point. Five minutes, one config edit, one restart.
Step 1. Find your vault path. In Obsidian, open the vault settings (the cog icon, then About). The path is shown at the top. On macOS it usually lives in ~/Documents/ObsidianVaults/YourVault. On Windows it tends to be under C:\Users\you\Documents\ObsidianVaults\YourVault. Copy the full path.
Step 2. Open the Claude Desktop config file. In Claude Desktop, go to Settings, then Developer, then Edit Config. That opens claude_desktop_config.json in your default editor (or creates it if missing). On macOS the file lives at ~/Library/Application Support/Claude/claude_desktop_config.json. On Windows it lives at %APPDATA%\Claude\claude_desktop_config.json.
Step 3. Add the Filesystem MCP server. Drop in the standard block, pointing it at your vault path. Multiple allowed paths are supported, so you can include other folders you want Claude to touch.
{
"mcpServers": {
"obsidian-vault": {
"command": "npx",
"args": [
"-y",
"@modelcontextprotocol/server-filesystem",
"/Users/you/Documents/ObsidianVaults/YourVault"
]
}
}
}
Step 4. Fully quit and reopen Claude Desktop. Cmd-Q on macOS, fully close on Windows. A window reload does not pick up new MCP servers. Roughly half of “my MCP server is not showing up” troubleshooting is people who reloaded instead of restarted.
Step 5. Test it. Open a new chat and ask “list the files in my Obsidian vault” or “find every note that mentions my Q3 plan.” Claude calls the filesystem tools, returns the matches, and you are running. The hosted GitHub MCP server install guide from the official MCP servers repo covers the same pattern if you want extra context.
What Filesystem MCP gives you out of the box: list files in a directory, read any file, write new files, edit existing ones, search file contents (grep-style), and move or rename. That is almost everything you actually need to use a vault from Claude. The performance is good even on 10,000-note vaults. The reason is that Filesystem MCP just touches plain text on disk. There is no Obsidian process in the path, no plugin layer, no HTTP round trip.
The trade-off: this approach does not know what Obsidian knows. It cannot trigger a graph refresh. It cannot run Dataview queries. It cannot execute a Templater template. For most reading, writing, and searching, that is fine. For power workflows, see path two.
Path 2: Local REST API + mcp-obsidian (the powerful one)
This is the path to take if you live inside Obsidian and want Claude to act on the running app, not just the files. Step count is higher. The payoff is depth.
Step 1. Install the Local REST API community plugin. Inside Obsidian: Settings, then Community plugins, then Browse. Search for “Local REST API” by coddingtonbear. Install it. Enable it.
Step 2. Generate an API key. Open the plugin settings. Copy the API key. By default the plugin runs at https://127.0.0.1:27124 with a self-signed certificate. There is an HTTP endpoint at http://127.0.0.1:27123 if you prefer to skip the cert dance. The key is your only auth, so treat it like a password. Do not commit it to a repo.
Step 3. Install mcp-obsidian. This is the bridge that exposes the REST API as MCP tools. The mcp-obsidian repo by MarkusPfundstein is the most widely used implementation. It supports list files, read file, search, patch content (atomic edits by heading or block), append content, and delete.
Step 4. Wire it into Claude Desktop. Edit claude_desktop_config.json the same way as before. The block for the REST API path looks like this.
{
"mcpServers": {
"obsidian-api": {
"command": "uvx",
"args": ["mcp-obsidian"],
"env": {
"OBSIDIAN_API_KEY": "your-api-key-here",
"OBSIDIAN_HOST": "127.0.0.1",
"OBSIDIAN_PORT": "27124"
}
}
}
}
uvx is the easiest way to run a Python MCP server without a venv. If you do not have uv installed, the project ships pip install instructions in its README.
Step 5. Keep Obsidian open while you use it. This is the trade-off. The REST API plugin only responds when Obsidian itself is running. If you close the app, the MCP calls fail. For people who keep Obsidian open all day, that is invisible. For people who only open Obsidian when they need a note, this path is the wrong fit.
What the REST API path adds over Filesystem MCP: atomic patch operations (edit one heading without touching the rest of the file), search through Obsidian’s own indexer (handles aliases, wikilinks, and frontmatter the way Obsidian itself does), and the link graph updates as Claude writes. It is the more satisfying option to watch in action, especially if you are doing things like triaging a daily note or extending a wiki.
For comparison reading on the broader pattern, the Obsidian forum showcase thread has user reports from across both setups.
What to do once it is connected
A working Obsidian-Claude setup is one of those things that feels underwhelming for the first five minutes and obvious after a week. The wins compound. Here is the short list of what people actually do with it.
Surface old notes during a current task. “Have I written anything about pricing experiments?” Claude searches the vault and pulls the three notes that match. You read for thirty seconds and remember the thing you forgot.
Restructure a daily note into a project page. “Take the meeting notes I wrote today and put the action items into the existing project file.” Claude reads the daily note, finds the project file, appends a structured task list. The kind of edit you mean to do every Friday and never do.
Generate the boring scaffolding. Onboarding doc for a new hire. Stub pages for ten upcoming articles. Project briefs that follow your existing template. Claude can write the scaffold and you fill in the parts that need a brain.
Maintain a private wiki. Read all your journal entries, find every person you mentioned, create or update their entity note with backlinks. The claude-obsidian companion project built around Karpathy’s LLM Wiki pattern is a worked example. Ten to fifteen minutes of manual work, done in seconds.
Pull from notes mid-chat. Asking Claude any work question becomes implicitly grounded in everything you have written. “What is my current take on Y?” no longer means “let me explain my current take on Y from scratch.” It means “Claude already read it.”
For more on building this kind of stack, see Personal AI Context Stack for Claude and the round-up of 7 Best MCP Servers for Knowledge Workers.
The five mistakes that break Obsidian MCP setups
Six months of forum reading and the same handful of issues come up again and again.
Pointing Filesystem MCP at the wrong path. The vault folder name is not always the same as the path Obsidian reports. Symlinks, iCloud Drive, and Windows OneDrive paths trip people up. If list_files returns nothing or a .obsidian config folder appears but no notes, your path is wrong.
Forgetting the API key in the REST API setup. The plugin generates a key but does not surface it loudly. If your OBSIDIAN_API_KEY env var is empty, every request returns 401 and the MCP server looks broken. Open the plugin settings, copy the key fresh, paste it again.
Skipping -y on npx commands. Without -y, npx waits for an interactive “install this package” prompt. Claude cannot answer it. The process hangs. Filesystem MCP and dozens of other community servers all start through npx -y. The -y is not optional.
Reloading instead of restarting. Claude Desktop only reads its config and connector list at full startup. Cmd-Q on macOS, fully close on Windows, then reopen. Reload Window does nothing.
Running 25 MCP servers at once. Each MCP server is a subprocess with startup cost and memory overhead. Past ten, you will feel it. Past twenty, Claude Desktop’s memory use climbs fast and tool calls get slower. Three to six servers is the sweet spot, and an Obsidian server is one of the highest-leverage slots.
Why bookmarks belong next to Obsidian, not inside it
Most knowledge workers I talk to have two halves to their thinking layer. The first half is what they wrote: notes, journals, briefs, project docs, the things that live in Obsidian. The second half is what they saved: tweets, Reddit threads, LinkedIn posts, articles read in passing. The two halves rarely meet.
Obsidian is great at the first half. It is not built for the second. Importing your X bookmarks into Obsidian by hand is a tax nobody pays for long. The result is that the saved-content half stays trapped in a sidebar inside whichever platform you saved it on, and Claude only sees the half you have already typed up.
This is where a bookmarks MCP earns its slot. ContextBolt is a Chrome extension that captures bookmarks from X, Reddit, and LinkedIn, tags them by topic automatically, and exposes them through a personal MCP endpoint. The free tier (150 bookmarks) covers casual use. Pro at $6 a month adds unlimited bookmarks, encrypted cloud sync, and the MCP endpoint that any client can call.
Wire it in the same way as the Obsidian server. Open Claude Desktop, go to Settings, then Connectors, then Add custom connector. Paste your endpoint URL. Restart. Now Claude has access to both halves of your thinking layer: the notes you wrote in Obsidian and the posts you bookmarked while doom-scrolling. Asking “what have I been thinking about this quarter?” returns a real answer because the input is real.
For the parallel walk-through inside Claude Desktop specifically, see Claude Desktop MCP: Setup, Servers, and the 2026 Stack. For the broader picture of personal AI memory, see 9 Ways to Give Claude Long-Term Memory.
The one opinion worth holding
Almost every “connect Obsidian to Claude” guide on the internet starts with the REST API plugin. The plugin is interesting. The blog posts are well-written. The demo videos are convincing. And most readers do not need any of it.
Filesystem MCP, pointed at your vault folder, covers 90 percent of what people actually do with the integration. It is faster. It uses less memory. It works when Obsidian is closed. It has zero plugin dependencies that can break after an update. The REST API path is a real upgrade for power workflows, and you should know it exists. But making it your default is choosing a heavier setup before you know whether you need it.
The other thing worth saying out loud: the MCP server you wire up is more important than the AI client you use. Claude Desktop, Cursor, Windsurf, and ChatGPT Developer Mode all read the same servers. Your Obsidian MCP setup is a one-time piece of work that pays off across every client you touch for the next two years. The marginal value of switching clients is small. The marginal value of having your notes inside any of them is large.
Set up Filesystem MCP today. Add ContextBolt for the bookmarks half. Reach for the REST API path when, and only when, you hit a specific feature you actually need. That is the entire decision tree.