seekstone

---

	Seekstone	obsidian-mcp-server (#1 by downloads)	REST-proxy servers
Local REST API plugin	Not needed	Required	Required
Obsidian app running	Not needed — works with Obsidian closed	Required	Required
Search payload @ 10k notes	2.0 KB	47 KB	up to 95 MB
Warm search latency @ 10k notes	5.2 ms	732 ms (~141× slower)	up to 1,550 ms
Structured frontmatter queries	Built-in (query_notes) — property/date/size predicates, answers in a few hundred bytes	JSONLogic via REST	Varies

Same queries, same committed vaults, 20 runs each, one machine. In-process adapters were re-run on the fixture-v2 vault in September 2026; the REST-proxy rows (rest, obsidian-mcp-server, mcp-obsidian) plus obsidian-mcp and obsidian-mcp-pro are June 2026 captures on fixture v1 — per-row provenance in benchmarks.json, the generated source of truth every number here is checked against in CI — full results across eight servers and three vault sizes below, fully reproducible from the harness.

---

---

What is Seekstone?

Seekstone is an Obsidian MCP server — it gives Claude (and any Model Context Protocol client) direct read and write access to your Obsidian vault. No Obsidian app needs to be open, no plugins are required, and nothing leaves your machine.

It reads your vault directly from disk rather than routing through the Obsidian Local REST API plugin, and holds a warm full-text index in-process. The practical difference is twofold:

• Speed. Keyword searches return in single-digit milliseconds warm and semantic searches in ~26 ms — up to ~514× faster than every other Obsidian MCP server we benchmarked, because there's no subprocess to spawn and no HTTP round-trip per query.
• Context. A broad search that returns tens of megabytes and millions of tokens via a REST-proxy server returns ~2 KB via Seekstone — up to a ~47,000× reduction that only widens as your vault grows.

Search comes in three modes: ranked full-text search (fuzzy and prefix matching), optional local semantic search (meaning-based, via a small on-device embedding model — opt-in, offline at runtime after a one-time ~30 MB model download), and structured metadata queries — query_notes filters by frontmatter properties (status, due, type, …), tags, folder, modified time, and size, answering questions like "which draft notes changed this week?" in a few hundred bytes instead of a search-and-read loop.

Claude can search and read your entire note library, in milliseconds, without burning most of its context window on a single tool call.

Published on npm as seekstone — install with npx -y seekstone. (Previously also published as obsidian-mcp-seekstone; that alias is deprecated but existing installs keep working.)

---

Why Seekstone? The numbers.

Most Obsidian MCP servers return full note content for every search hit. On a broad query that's megabytes of text your LLM has to process — most of it irrelevant, all of it burning context window.

Seekstone returns short ranked excerpts instead (~120 characters by default, tunable per query). We benchmarked Seekstone against 7 other Obsidian MCP servers — 8 servers total — across three vault sizes — 1,000 / 5,000 / 10,000 notes (20 runs each). Every number below is fully reproducible: the vaults are committed to this repo (generated from the public-domain 1911 Encyclopædia Britannica), so you can clone it and run the exact same benchmark yourself.

The point of testing three sizes is that this is where the architectures diverge — a real vault only grows.

Search payload — bytes returned per query (context tax; lower is better)

Server	Architecture	1k notes	5k notes	10k notes
🥇 Seekstone	in-process index	1.6 KB	1.8 KB	2.0 KB
mcpvault	fs-direct subprocess	1.7 KB	1.9 KB	2.2 KB
obsidian-mcp-rs	fs-direct, per-query scan	5.4 KB	5.8 KB	6.2 KB
obsidian-tc	SQLite platform	4.6 KB	6.8 KB	7.2 KB
obsidian-mcp-server	REST API	55 KB	47 KB	47 KB
obsidian-mcp-pro	fs-direct subprocess	25 KB	84 KB	114 KB
obsidian-mcp	fs-direct subprocess	18 KB	105 KB	201 KB
mcp-obsidian	REST API	9.8 MB	45 MB	95 MB

Seekstone stays flat (~2 KB) no matter how big your vault gets, because it always returns ranked excerpts — and it's now the smallest payload of every server tested, edging out mcpvault at all three sizes. The REST-proxy servers return full note content for every match, so they grow with the vault — mcp-obsidian hits 95 MB at 10k notes, and a single broad query (the capital of) averaged 370.9 MB / 97.8 million tokens per call across 20 runs. At 10k notes that's a ~47,000× context-tax difference.

Search latency — warm mean, ms (lower is better)

Server	1k notes	5k notes	10k notes	vs Seekstone @10k
🥇 Seekstone	1.0	2.7	5.2	—
obsidian-mcp-rs	5.8	18	35	~7× slower
obsidian-mcp-pro	46	213	430	~83× slower
obsidian-mcp-server	82	356	732	~141× slower
obsidian-mcp	82	405	811	~156× slower
mcpvault	89	436	897	~173× slower
mcp-obsidian	164	740	1,550	~299× slower
obsidian-tc	263	1,253	2,667	~514× slower

Every competitor spawns a subprocess or makes HTTP round-trips per query, and most do work that scales with vault size. Seekstone holds a warm in-process index — no IPC, no network — so keyword search stays in single-digit milliseconds even at 10,000 notes (the shipped semantic pipeline — embed, scan, MaxSim rerank — lands at ~26 ms). And the gap widens with scale: from 1k → 10k notes the competitors slow down 5–10×, while Seekstone barely moves. Even the fastest alternative — obsidian-mcp-rs, which re-scans the vault on every query — is ~7× slower warm at 10k notes with 3× the payload, and the REST-proxy generation runs ~110–300× slower.

Seekstone is the only server in our benchmark set that delivers both ~2 KB payloads and single-digit-ms keyword latency at every vault size — and, as far as we know, the only Obsidian MCP server with published, reproducible benchmarks. The harness, the synthetic vaults, and the full results are open source: see benchmark-scaling.md and the harness. Clone, run, verify.

---

Install

Choose the method that suits you best.

Using an AI agent? Paste this prompt

If you use Claude Code, Cursor, or another coding agent, you don't need to follow any instructions yourself — paste this prompt and the agent does the install:

Install the seekstone MCP server for this editor. Run npx -y seekstone init --client code --write (use desktop, cursor, or vscode for other clients). It auto-detects my Obsidian vault; if it lists several, ask me which one and re-run with --vault "<path>". Relay any errors to me, then tell me to restart this session so the seekstone tools load.

seekstone init is fully non-interactive — with --write it validates the vault and patches the client config in one shot (Claude Code via claude mcp add, other clients via an additive JSON patch with a timestamped backup).

Option 1 — One-click (Claude Desktop, no terminal needed)

1. Download seekstone.mcpb (direct link, always the latest release)
2. Open it with Claude Desktop — double-click in Finder, or right-click → Open With → Claude Desktop
3. Pick your Obsidian vault folder when prompted

You'll know it worked when seekstone appears in Claude's toolbar. No JSON editing, no terminal, no Node.js required.

Want semantic search? Grab seekstone-semantic.mcpb instead — same server with the local embedding model shipped inside the bundle (~28 MB bigger), so meaning-based search works out of the box: still no terminal, and nothing is downloaded at runtime.

Option 2 — Guided setup (recommended for CLI users)

Open Terminal (macOS: Cmd+Space, type "Terminal", press Enter) and run:

npx -y seekstone init

You'll know it worked when Seekstone appears in Claude's toolbar under the plug icon.

Seekstone reads Obsidian's own vault registry to detect your vault, validates it, and either prints the config block to paste or patches Claude Desktop directly:

# Auto-detect vault, print config to paste
npx -y seekstone init

# Auto-detect vault, patch Claude Desktop in place (with backup)
npx -y seekstone init --write

# Specify vault explicitly if you have multiple
npx -y seekstone init --vault "/path/to/vault"

# Auto-configure Claude Code in one step (auto-detects vault, runs claude mcp add)
npx -y seekstone init --client code --write

# Or just print the Claude Code command without running it
npx -y seekstone init --client code

Option 3 — Manual config (Claude Desktop)

Add to claude_desktop_config.json (Settings → Developer → Edit Config):

{
  "mcpServers": {
    "seekstone": {
      "command": "npx",
      "args": ["-y", "seekstone"],
      "env": { "SEEKSTONE_VAULT": "/absolute/path/to/your/vault" }
    }
  }
}

Option 4 — Claude Code

Auto-detects your vault and configures Claude Code in one command:

npx -y seekstone init --client code --write

Or manually, if you prefer to specify the vault path explicitly:

claude mcp add seekstone --env SEEKSTONE_VAULT=/absolute/path/to/your/vault -- npx -y seekstone

Option 5 — Cursor

One-click: — then set SEEKSTONE_VAULT to your vault's absolute path in Cursor's MCP settings (the link installs a placeholder).

Or let the CLI auto-detect your vault and patch ~/.cursor/mcp.json (with a backup):

npx -y seekstone init --client cursor --write

Or add the block manually to ~/.cursor/mcp.json (global) or <project>/.cursor/mcp.json (per-project):

{
  "mcpServers": {
    "seekstone": {
      "command": "npx",
      "args": ["-y", "seekstone"],
      "env": { "SEEKSTONE_VAULT": "/absolute/path/to/your/vault" }
    }
  }
}

Option 6 — VS Code

One-click: — then set SEEKSTONE_VAULT to your vault's absolute path when VS Code opens the server config (the link installs a placeholder).

Or let the CLI auto-detect your vault and write the workspace config (.vscode/mcp.json in the current directory):

npx -y seekstone init --client vscode --write

Or add it from the terminal:

code --add-mcp '{"name":"seekstone","command":"npx","args":["-y","seekstone"],"env":{"SEEKSTONE_VAULT":"/absolute/path/to/your/vault"}}'

Or add the block manually to .vscode/mcp.json (workspace) or via Command Palette → MCP: Open User Configuration (user-global). Note VS Code's two quirks: the top-level key is servers (not mcpServers), and "type": "stdio" is required:

{
  "servers": {
    "seekstone": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "seekstone"],
      "env": { "SEEKSTONE_VAULT": "/absolute/path/to/your/vault" }
    }
  }
}

Requires VS Code 1.102+; seekstone appears in Copilot Chat's Agent mode tools picker.

Other MCP clients (Windsurf, Cline, …)

Seekstone is a standard MCP stdio server — any MCP client can run it. Use the same JSON block as above in your client's MCP config (command: npx, args: ["-y", "seekstone"], env SEEKSTONE_VAULT).

---

After installing, restart the client. On startup Seekstone walks the vault, builds an in-memory full-text index (a few seconds for thousands of notes), and keeps it live as you edit. The 21 tools below are then available to Claude.

Requires Node.js ≥ 22 for the CLI options. The one-click .mcpb bundle has no external requirements.

If Seekstone saves you context, consider ⭐ starring the repo — it helps others find it.

---

What can Claude do with your vault?

Once Seekstone is connected, you can ask Claude things like:

• "Search my notes for everything about [topic] and give me a summary" — uses search, returns ranked excerpts, not full files
• "Find all notes tagged #project and list their titles" — uses list_notes with a tag filter
• "Read just the 'Decisions' section of my [project] note" — uses read_note with a section selector, so only that slice enters context
• "What links to my [topic] note, and what does it link out to?" — uses get_backlinks and get_links to walk your graph
• "Append today's standup notes to my daily note" — uses append_periodic_note, resolving the daily-note path from your vault config (Obsidian doesn't need to be open)
• "Fix every occurrence of the old project name in this note" — uses replace_in_note, with a dry-run preview before it writes
• "Add a summary section to the bottom of [note]" — uses append_note, never touches frontmatter
• "Move all notes in /inbox to /archive/[year]" — uses move_note
• "Update the status field in this note's frontmatter to 'done'" — uses patch_frontmatter, preserves key order and quote style
• "Create a new meeting note for today with a standard template" — uses create_note

Claude never sees your full vault at once — it searches and reads selectively, so even large vaults (10k+ notes) stay within context budget.

---

Tools

Read

Tool	Description
search	Full-text search. Returns ranked excerpts (default ~120 chars, tunable via excerptLength), not full notes. Fuzzy and prefix matching; with SEEKSTONE_SEMANTIC=1, mode: "semantic"/"hybrid" searches by meaning via a local embedding model (nothing leaves your machine).
query_notes	Structured metadata query. Filter by frontmatter key/value predicates (eq, ne, contains, exists, missing, gt/gte/lt/lte), tag, folder, modified time, and size; sort and select the fields you need. Returns compact rows (path + title by default), not note content.
context_pack	Answer-ready context for a natural-language question in one call, hard-capped at a byte budget (default 2 KB): ranked excerpts, linked neighbor notes with one-line summaries, and follow-up source paths — replaces a search → read → get_backlinks round-trip loop.
read_note	Read the full content of a note by vault-relative path. Supports returning a single section, block, or line range.
list_notes	List notes, optionally filtered by folder prefix or tag.
list_tags	List all tags in the vault sorted by usage count (or alphabetically).
outline_note	Return a note's heading and block structure without its full content — cheap navigation before a targeted read.
get_backlinks	Find all notes that link to a given note.
get_links	List all outgoing wikilinks and markdown links from a note.
get_periodic_note	Read today's (or any date's) daily, weekly, monthly, quarterly, or yearly note — path resolved from your vault config, no Obsidian required.
list_writes	Recent writes from the journal — seq, timestamp, tool, touched paths, and whether each is still undoable. Metadata only, never note content.

Write

Tool	Description
create_note	Create a note (optional frontmatter + body); parent directories are created automatically.
delete_note	Move a note to the vault's .trash/ folder (Obsidian-compatible, restorable). Pass permanent: true to skip the trash — the write journal still lets undo_write restore it.
move_note	Move or rename a note — wikilinks and markdown links in other notes that point at it are rewritten so nothing breaks (rewriteLinks: false to opt out); destination directories are created automatically.
rename_heading	Rename a heading in a note — every [[note#heading]] wikilink and embed across the vault is rewritten so references keep working (aliases preserved, fenced code blocks left alone).
append_note	Append text to a note body without touching frontmatter.
patch_frontmatter	Set, update, or delete frontmatter keys without reordering existing keys or changing quote style.
patch_note	Append, prepend, or replace text at a heading or block reference (createIfMissing to add the section) — frontmatter untouched.
replace_in_note	Find and replace text in the note body — literal or regex, case sensitivity, whole-word matching, optional limit (replaces all occurrences by default), and a dry-run preview.
append_periodic_note	Append to today's periodic note, creating it from a template if it doesn't yet exist.
undo_write	Revert a journaled write: every file it touched goes back to its byte-identical pre-write state (a multi-file move or heading rename is restored whole; a delete is restored even if it was permanent). Defaults to the most recent write; refuses with undo_conflict if a file changed since, unless force: true. The undo is itself journaled — undo_write({ seq }) on the undo entry redoes it.

Every write tool (append_note, patch_note, patch_frontmatter, replace_in_note, rename_heading, move_note, delete_note, append_periodic_note, and create_note with overwrite: true) supports optional compare-and-swap: pass the contentHash you got from read_note as prevHash and the call fails cleanly if the note changed underneath you — no silently discarded concurrent edit, no moving or deleting content you haven't seen. Every mutating result returns the new contentHash, so chained edits need no re-reads.