# Three ways to run an MCP server for Obsidian, and what each one needs switched on

> The Local REST API plugin now ships its own MCP server, so most of the wrappers are redundant. The three routes compared on what has to be running.

Source: https://baalda.com/blog/mcp-server-for-obsidian
Site: Baalda, https://baalda.com
Published: 2026-10-11

**Short answer.** Three routes exist. The Local REST API plugin now ships a built-in MCP server at /mcp/ on 127.0.0.1, authenticated with a bearer token. Wrapper servers like mcp-obsidian call that same plugin. Filesystem servers read the .md files directly. The first two need Obsidian open; all three hold one key over one vault.

There is no Obsidian server. Obsidian's own help page defines a vault as "a folder on your local file system where Obsidian stores your notes", and that single sentence decides everything about this question. An MCP server for Obsidian is not a thing you connect to. It is a process somebody runs next to your copy of the folder, and the three ways of running it differ in exactly one thing that matters: what has to be switched on before the AI can see anything.

That is the axis nobody sorts the options by, which is why the choice looks harder than it is.

## What are the real options, and how does each one reach the vault?

Search for this and you get GitHub repos and directory listings, all documenting themselves. Underneath the product names there are three architectures.

**Inside the app.** The [Local REST API plugin](https://community.obsidian.md/plugins/obsidian-local-rest-api) by Adam Coddington, on about 781,000 downloads, now ships its own MCP server. Its description is blunt about what that means for the rest of the field: third-party MCP servers for Obsidian exist but "are no longer necessary", because the plugin "ships a built-in MCP server that runs inside Obsidian and has direct access to your vault's live metadata, active file, and command palette." The server lives at `/mcp/` on port 27124 over HTTPS or 27123 over HTTP, authenticated with a bearer token you copy from its settings, and exposes `vault_list`, `vault_read`, `vault_write`, `vault_patch`, `vault_delete`, `search_query`, `tag_list` and `command_execute`.

**Beside the app, through that same plugin.** This is where most of the SERP sits. [MarkusPfundstein/mcp-obsidian](https://github.com/MarkusPfundstein/mcp-obsidian) states its prerequisite plainly: "You need the Obsidian REST API community plugin running." You give it `OBSIDIAN_API_KEY`, `OBSIDIAN_HOST` and `OBSIDIAN_PORT`, defaulting to `127.0.0.1` and `27124`, and it exposes seven tools including `patch_content`, `append_content` and `delete_file`. [cyanheads/obsidian-mcp-server](https://github.com/cyanheads/obsidian-mcp-server) does the same against "The Obsidian Local REST API plugin, v4.0.0 or later", adds a choice of stdio or HTTP transport, and adds folder allowlists in `OBSIDIAN_READ_PATHS` and `OBSIDIAN_WRITE_PATHS`. These are wrappers around the plugin that now has an MCP server of its own, which is the plugin's point.

**Straight at the files.** [StevenStavrakis/obsidian-mcp](https://github.com/StevenStavrakis/obsidian-mcp) skips Obsidian entirely and takes a path:

```json
{
  "mcpServers": {
    "obsidian": {
      "command": "npx",
      "args": ["-y", "obsidian-mcp@2", "serve", "--vault", "notes=/absolute/path/to/vault"]
    }
  }
}
```

Its README is explicit about the trade: it "works directly with Markdown files, so Obsidian does not need to be open." Its README also tells you to back up important vaults and to use revision preconditions on notes that are being edited concurrently, which is an honest warning about what writing into a folder a desktop editor may also have open can do.

## What has to be running before the AI sees anything?

Here is the whole comparison, on the axis that decides it.

| Route | Reaches the vault via | Obsidian app open? | Machine awake? | Scope |
|---|---|---|---|---|
| Local REST API built-in MCP | the plugin, inside Obsidian | Yes | Yes | the vault, one bearer token |
| mcp-obsidian, obsidian-mcp-server | the plugin's HTTP API on 127.0.0.1 | Yes | Yes | the vault, one API key, optional path allowlists |
| obsidian-mcp (filesystem) | the `.md` files directly | No | Yes | the folders you pass on the command line |

Two of the three need the Obsidian application running on the machine holding the folder. Not installed, running. Close the app and the MCP server answers nothing, because the server is a feature of a text editor that happens to be open. The filesystem route removes that requirement and keeps the other one: the laptop still has to be awake, because the files are on it.

For one person at their own desk this is fine, and it is worth saying so before the rest of this post: if you are sitting in front of the machine with the vault on it, the Local REST API plugin's built-in server is the shortest correct answer and you can stop reading. The wrappers exist mostly because they predate it.

It stops being fine the moment anything about the arrangement is not one person at one desk. An agent that runs on a schedule, a teammate's assistant that should be able to read the runbook, anything that has to answer when you are asleep: none of these can be served by a process that lives inside an editor on your laptop. This is where [Baalda](/) is built differently rather than configured differently. The MCP endpoint is a route on the same server that already holds the notes, so there is no second process, no plugin and nothing to keep open:

```bash
claude mcp add --transport http context https://api.baalda.com/api/mcp \
  --header "Authorization: Bearer mcp_…"
```

The notes are still plain markdown files on your own disk, syncing to that server rather than living only on it. The difference is that the thing an agent talks to is not your editor.

## What does one key actually reach?

Every option above authenticates the same way: one secret, standing for the whole vault.

The Local REST API plugin uses one bearer token. `mcp-obsidian` uses one `OBSIDIAN_API_KEY`. The filesystem server uses no credential at all, just a path. `cyanheads/obsidian-mcp-server` is the only one that lets you narrow the blast radius, through `OBSIDIAN_READ_PATHS` and `OBSIDIAN_WRITE_PATHS`, and its own README is candid that this is not on by default: with `MCP_AUTH_MODE=none` and no path allowlist, any caller that can reach the server gets unrestricted vault access.

A path allowlist is a scope, though, not a person. It says which folders this installation may touch. It cannot say who is asking, because in a single-user editor there is nobody to ask about. That is not a flaw in these projects. It is the correct design for the thing Obsidian is, and it only becomes a problem when the notes stop being one person's.

That problem, and what a server has to do about it, is the subject of [a separate post on running that server off your laptop](/blog/local-mcp-server-your-team-vault). It is a different question from this one and it has a different answer.

## What about the AI writing while Obsidian has the file open?

The filesystem route buys availability by writing to `.md` files behind a running editor's back. Obsidian is holding its own in-memory state for anything you have open, and nothing in that path coordinates the two writers. This is the same shape as the problem that produces [Obsidian sync conflicts](/blog/obsidian-sync-conflicts), with the difference that one of the writers is now a model.

The plugin routes avoid it by going through Obsidian itself, which is a real advantage and the main reason to prefer them when the app is going to be open anyway. They pay for it with the requirement that the app is open.

## When is an Obsidian MCP server still the right answer?

Often, and Baalda does not change that for most people.

If your vault is local, yours, and on the machine you work at, install the Local REST API plugin, turn on its MCP server, paste the bearer token into your client and you are done in about five minutes. Nothing here beats that for a single person, and a managed server is a worse answer to a question you do not have.

The honest limits of the alternative, stated plainly: Baalda is not an Obsidian plugin. It is a separate application with its own vault, so moving to it is a move, not an add-on, and there is no Obsidian importer. If what you want is Obsidian plus an AI, the plugin is the answer and this post has already given it to you. If what you want is for the notes to be reachable when your laptop is shut, or by more than one person, that is a different thing to run, and no MCP server for Obsidian can turn a folder on one disk into it.

You can read how the endpoint works in [the MCP docs](/docs/mcp), or compare the two tools directly on [the Obsidian comparison page](/compare/obsidian).

## FAQ

### Do I still need mcp-obsidian or obsidian-mcp-server?

Probably not. The Local REST API plugin those wrappers depend on now ships an MCP server of its own, and its description says so directly: "Several third-party MCP servers for Obsidian exist, but they are no longer necessary. This plugin ships a built-in MCP server that runs inside Obsidian and has direct access to your vault's live metadata, active file, and command palette." The wrappers predate it. They are still useful if you want something the built-in server does not expose, and `cyanheads/obsidian-mcp-server` in particular adds folder allowlists through `OBSIDIAN_READ_PATHS` and `OBSIDIAN_WRITE_PATHS` plus a choice of stdio or HTTP transport. For a plain setup, one fewer process is one fewer thing to debug.

### Does Obsidian have to be running for an MCP server to work?

For two of the three routes, yes. The plugin's built-in server runs inside Obsidian, and the wrapper servers call that plugin over 127.0.0.1, so both of them answer nothing when the app is closed. The filesystem route is the exception: `StevenStavrakis/obsidian-mcp` states that it "works directly with Markdown files, so Obsidian does not need to be open." That one still needs the machine itself awake, because the vault is a folder on that machine.

### Can I stop the AI reading parts of my vault?

Partly, and only on some routes. `cyanheads/obsidian-mcp-server` takes comma-separated folder allowlists in `OBSIDIAN_READ_PATHS` and `OBSIDIAN_WRITE_PATHS`, and `OBSIDIAN_READ_ONLY` denies writes outright. Its README is clear that none of this is the default: with `MCP_AUTH_MODE=none`, "any caller on the network gains unrestricted vault access." The filesystem server scopes to whatever paths you pass it. What none of them can do is vary by person, because a local editor has no accounts.

### Is a remote MCP endpoint less safe than a local one?

It is a different trade, not a strictly worse one. A local server needs no network exposure, which is a real advantage, but it runs with your account's reach on your own machine and authenticates with a single long-lived key in a config file. A remote endpoint moves the secret and the reachable surface to a server you have to trust, and in exchange the grant can be scoped and revoked without touching your laptop. If you self-host, that server is also yours. The honest version of this comparison is in the post on running a vault's MCP server off your laptop.

### Can two people share one Obsidian MCP server?

Not meaningfully. Every route here authenticates with one secret standing for the whole vault, so a second person either gets the same key and the same reach as you, or runs their own server against their own copy of the folder. Two servers over two copies means whatever an agent writes lands in one replica and has to sync to the other afterwards, which is a replication problem rather than a permissions one. There is nothing to configure here because Obsidian is a single-user editor and these servers are faithful to that.