Obsidian MCP server: four ways to connect your vault to AI agents

1. mcp-obsidian (Local REST API family)

The most popular approach (the mcp-obsidian repo counts 4k+ GitHub stars as of July 2026): MarkusPfundstein's mcp-obsidian and similar servers (such as cyanheads' obsidian-mcp-server) talk to the Local REST API community plugin inside Obsidian. The agent gets real Obsidian semantics: list files, read and patch notes, run search.

Requirements follow from the design: Obsidian must be installed and running with the plugin enabled, you configure an API key, and the MCP server runs as a local process on the same machine. Setup takes a few minutes and everything stays local.

2. Filesystem MCP server

A vault is a folder of markdown files, so the generic filesystem MCP server (@modelcontextprotocol/server-filesystem) pointed at the vault also works. Obsidian does not even need to be running. The tradeoff: the agent sees files, not a knowledge base. No semantic search, no wikilink resolution, no metadata awareness; on a large vault the agent falls back to reading whole files, which is slow and token-hungry.

3. Obsidian plugins with built-in MCP

Some community plugins embed an MCP (or similar) endpoint directly in Obsidian. Convenient, same constraint as option 1: the vault is reachable exactly while Obsidian is open on that machine.

All three local ways share the same profile: fully private, quick to set up, and tied to your running desktop. For a single user on one machine, that profile is often exactly right, and you should start there.

What the agent gets

The MCP endpoint exposes search, expand, note_html, similar, plus federated_* tools for reaching peer bases (federation). Search returns a toc_path pointing at the exact section of a note, so the agent reads that section instead of the whole file, about 15× cheaper at the median, measured and reproducible in the token benchmark.

Access is not all-or-nothing: notes without free: true require a token, and subscription subgraphs let you expose one folder of the vault to an agent (or a person) without exposing the rest. That is the piece local servers structurally cannot do, and it is what makes a shared team vault workable.

Set it up

1. Create an instance: self-host with Docker (guide), boot a throwaway local one with memcli, or use a free cloud instance.
2. Install the trip2g sync plugin in Obsidian, connect it, press Sync. Details in getting started.
3. Add the MCP endpoint to your client:

{
  "mcpServers": {
    "obsidian-vault": {
      "url": "https://your-site.example.com/_system/mcp"
    }
  }
}

For private vaults, create a personal token under User → Tokens and send it as Authorization: Bearer t2g_…. All auth options: MCP reference.

Verify

curl https://your-site.example.com/_system/mcp \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"tools/list","id":1}'

The response lists the tools. Then, in your MCP client, ask the agent to search for a phrase you know is in the vault and to quote the note it found. If it quotes your text, the loop is closed. You can test against a live instance right now: https://trip2g.com/_system/mcp serves this documentation site's own vault.