Obsidian MCP Server

Your agents' memory, in the vault you already have, reachable from claude.ai, ChatGPT, Claude Code and your phone.

A self-hosted Model Context Protocol server that turns an Obsidian vault into long-term memory for every agent you use. Agents search it by meaning or by exact words, follow its wikilinks, see what changed since their last session and who changed it, keep their to-dos in it, and write back through guarded, atomic edits. 32 tools over plain markdown files that you can open, edit and grep.

What sets it apart:

• Your existing vault, served in place. No imposed note format, no sidecar syntax, no "memory" folder you have to adopt. Agents read what you read, follow your wikilinks, and pick up your folder layout, frontmatter schema and tag conventions from the vault itself.
• Remote and multi-user. OAuth 2.0 PKCE and API keys, so claude.ai, Claude Desktop, Claude mobile, ChatGPT, Claude Code and n8n all read and write the same files, each user confined to their own vault root.
• Writes are guarded. An edit that carries expected_hash is refused when the note changed since it was read, and a deployment can require the hash on every edit (Guarding edits against stale reads). Every publish is atomic, a create refuses a path that is already taken, deletes go to .trash/, and dry_run returns the diff before anything lands.

Connect from Claude Code:

claude mcp add obsidian --transport http \
  --url "https://obsidian-mcp.<your-domain>/mcp" \
  --header "Authorization: Bearer omcp_..."

In claude.ai, Claude Desktop or ChatGPT, add a custom connector at https://obsidian-mcp.<your-domain>/mcp and sign in through the OAuth consent page. Connect a client has the rest.

Stack: Python 3.12, FastAPI, PostgreSQL with pgvector, and an embedding backend of your choice (Ollama, OpenAI or Hugging Face TEI; see Pick an embedding backend).

Contents

• Why this exists
• A session at the keyboard
• A session away from the keyboard
• What's in the box
• vs. other Obsidian MCP servers
  • vs. hosted memory systems
  • vs. an agent with raw file access
• Who this is for
• Control panel
• Quick start
• Versioning and compatibility
• Upgrading
• Cost expectations
• The self-describing vault
• Multi-user mode
• Configuration
• Architecture
• Project layout
• Development
• Security notes

Why this exists

There are three things going on here, and they're more interesting together than apart.

1. Agent memory that you can actually read

If you let an agent run for a while, it needs memory. Most setups solve this with an opaque vector store, a SQLite blob, or a managed "memory" service that you can't see into. That works until you want to know what the agent thinks it knows about you, or you need to

... View full README on GitHub