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

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 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 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 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 skips Obsidian entirely and takes a path:

{
  "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.

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:

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. 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, 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, or compare the two tools directly on the Obsidian comparison page.