Obsidian MCP Server Cursor IDE Setup 2026: Vault Access Without the App Running

How do you connect Obsidian to Cursor IDE via MCP? Clone and build a filesystem-based Obsidian MCP server (git clone, npm install, npm run build), then point Cursor at the built dist/index.js file with an OBSIDIAN_VAULT_PATH environment variable set to your vault's folder. No plugin, no Obsidian process running, no REST API — the server reads and writes .md files directly. Restart Cursor, and it can list notes, search vault content, and create or edit notes from chat.

Set expectations first: there is no single official Obsidian MCP server. Obsidian itself doesn't ship one, so what exists is a handful of community projects that take genuinely different approaches — some read the vault straight off disk, some run as an actual Obsidian plugin and talk to a local HTTP endpoint while the app is open. This guide covers the filesystem approach first, because it's the simplest to reason about and doesn't require Obsidian to be running at all, then covers the plugin-based alternative and when it's actually the better fit.

Two Real Approaches, Not One

Filesystem-based (what this guide sets up): the server reads and writes Markdown files directly from your vault's folder on disk. It doesn't know Obsidian is even installed — a vault, after all, is just a folder of .md files plus a .obsidian config directory. This means it works whether or not Obsidian is open, and setup is a standard Node.js build-and-run.

Plugin-based: an actual Obsidian community plugin (installed through Obsidian itself, commonly via the BRAT beta-plugin loader) that starts a local HTTP server inside the running Obsidian process, typically on a port like 27123, using streamable-HTTP transport with bearer-token auth. Because it runs inside Obsidian, it can potentially use Obsidian's own indexed search and live plugin state rather than re-implementing search over raw files — but it requires Obsidian to actually be open, and setup involves installing a beta plugin loader rather than a plain Node build.

If you want Cursor to read and edit vault notes as part of a coding or writing workflow without needing Obsidian open in the background, filesystem-based is the more predictable choice, and it's what the rest of this guide walks through. If you specifically need to interact with a vault while you're actively working in it inside Obsidian, the plugin route is worth a look — just know it's a different install path with a different trust model (an HTTP endpoint with a bearer token, versus a local subprocess).

What the Filesystem Server Actually Does

The reference implementation here exposes 13 tools, all operating on a single vault folder:

Every tool accepts a response_format parameter (markdown or json), so you can get either human-readable output or structured data depending on what the calling workflow needs.

Prerequisites

Step 1: Clone and Build the Server

git clone <obsidian-mcp-repo-url> obsidian-mcp
cd obsidian-mcp
npm install
npm run build

This produces dist/index.js inside the cloned folder — that's the file Cursor will run directly with Node, not through npx from a published package.

Step 2: Find Your Vault Path

This is the folder Obsidian opens as a vault — for example /Users/you/Documents/MyVault. If you're not sure, check Obsidian's own vault list in Settings, or just locate the folder that contains a .obsidian subdirectory.

Step 3: Configure mcp.json

{
  "mcpServers": {
    "obsidian": {
      "command": "node",
      "args": ["/absolute/path/to/obsidian-mcp/dist/index.js"],
      "env": {
        "OBSIDIAN_VAULT_PATH": "/absolute/path/to/your/vault"
      }
    }
  }
}

Both paths need to be absolute — the built dist/index.js from Step 1, and your vault folder from Step 2. Restart Cursor completely for the new server to register.

Step 4: Verify

List the notes in my Obsidian vault

If real note titles come back, the connection works. Try a search next:

Search my vault for notes mentioning "quarterly planning" and show me 
which ones also have the #work tag

Practical Workflows

Pulling reference material into a coding session

Read my Obsidian note on the API auth flow and summarize the steps so 
I can implement the equivalent in this codebase

Capturing a decision without switching apps

Create a note in my vault called "2026-08-29 architecture decision" with 
frontmatter tags [decisions, backend] summarizing what we just agreed on 
in this conversation

Auditing a knowledge base for orphaned notes

Use the backlinks tool to check which notes in my "Projects" folder have 
zero incoming links, so I can find ones that got orphaned

Security Notes Worth Taking Seriously

The filesystem-based server includes path traversal protection and symlink blocking — reasonable defaults, since the entire tool surface is "read and write arbitrary Markdown files," which is exactly the kind of access you don't want an agent stepping outside of via a crafted path or a symlink pointing somewhere it shouldn't. It also caps individual file reads at 5 MB and truncates responses at 25,000 characters, so a single enormous note (or a runaway search result) won't blow up context or hang a request. None of that requires network access — it's a local Node process talking to local files, same trust boundary as any other filesystem-scoped MCP server.

That said, OBSIDIAN_VAULT_PATH grants full read and write over everything in that folder. If your vault has a subfolder of financial notes, medical records, or anything you wouldn't want summarized into an agent's context or edited unsupervised, that's not a config option this server exposes a way around — it's an all-or-nothing grant at the folder level, similar to how the official Filesystem MCP server treats its allowed directories.

Troubleshooting

Server doesn't appear in Cursor's MCP panel
Confirm the path in args points to the actual built dist/index.js, not the repo root — npm run build has to complete successfully first. Try running node /path/to/dist/index.js manually in a terminal; if that errors, the problem is the build or Node itself, not Cursor.

"Vault not found" or empty note list
OBSIDIAN_VAULT_PATH is pointing at the wrong folder, or a folder that doesn't actually contain .md files at the top level. Double-check against the path Obsidian itself shows for the vault in its settings.

Notes with unusual characters or deep nesting don't show up in search
This is a known rough edge in early-stage community MCP servers generally, not specific to one implementation — if search misses something, fall back to list_notes scoped to the folder you expect it in, and read directly rather than trusting search exhaustively.

Writes work but Obsidian's own UI doesn't reflect them until you click into the app
Expected — this server writes files directly to disk. Obsidian picks up external file changes when it regains focus or via its own file-watcher, but there can be a brief lag if Obsidian was already open when the write happened.

You actually need Obsidian's live search index or plugin state, not just the raw files
That's outside what the filesystem approach offers by design — look at the plugin-based server instead, which runs inside Obsidian and can be closer to what the app itself sees, at the cost of needing Obsidian open and a different (HTTP + bearer token) connection model.

When Not to Use This

If your actual goal is general local file access — not vault-specific features like backlinks, tags, and frontmatter — the plain Filesystem MCP server pointed at the same folder does a simpler version of the same job with an officially maintained package. Reach for the Obsidian-specific server when you actually want the vault-shaped tools: tag filtering, backlink lookups, frontmatter-only reads. And if you need Cursor to see live changes the instant they happen inside Obsidian's own UI, the filesystem approach's disk-level access isn't event-driven — you're reading current file state on each call, not subscribing to change events.

Frequently Asked Questions

Q: Is there an official Obsidian MCP server?
A: No. Obsidian doesn't publish one itself. What's available are community projects, split mainly between filesystem-based servers that read the vault directly off disk and plugin-based servers that run inside Obsidian and expose a local HTTP endpoint.

Q: Does Obsidian need to be running for this to work?
A: Not for the filesystem-based approach covered in this guide — it reads and writes .md files directly, independent of whether the Obsidian app is open. The plugin-based alternative does require Obsidian to be running, since the server runs inside it.

Q: Can the agent see my Obsidian tags and frontmatter, not just raw text?
A: Yes, the filesystem server has a dedicated metadata tool that returns frontmatter and tags without loading the full note body, plus a tag-based search tool for filtering notes by hashtag.

Q: Is it safe to point this at my entire vault?
A: The server includes path traversal and symlink protections and a 5 MB per-file read cap, but access is still all-or-nothing at the folder level — anything under OBSIDIAN_VAULT_PATH is readable and writable. Keep sensitive notes in a separate vault or folder if you don't want them in scope.

Q: What's the advantage of the plugin-based alternative over the filesystem approach?
A: Running inside Obsidian, a plugin-based server can potentially use the app's own live index and plugin state rather than re-reading files fresh each call. The tradeoff is that Obsidian has to be open, and the connection is HTTP with bearer-token auth rather than a local subprocess reading files directly.

Related Guides