Seekstone is an open-source MCP server that connects Claude (or any MCP client) straight to your Obsidian vault by reading it from disk. No plugin, no app running, nothing leaves your machine. Search returns ~2 KB of ranked excerpts — not megabytes of full notes. Reproducible benchmarks included.
No reviews yetBe the first to leave a review for Seekstone
Maker
📌
Hey Product Hunt 👋
I built Seekstone because connecting Claude to my Obsidian vault kept eating the context window. Most Obsidian MCP servers proxy a REST plugin and return full note content for every search match — in my benchmarks, one broad query on a 10k-note vault returned 95 MB, peaking at 370 MB (~98M tokens) in a single tool call. The AI's memory is gone before the conversation starts.
Seekstone reads the vault straight from disk and returns ranked excerpts instead of whole notes:
⚡ ~2 KB per search at 10k notes — flat as your vault grows (up to ~47,000× less than REST-proxy in the worst case)
🚀 6 ms warm search — ~70–250× faster than every other Obsidian MCP server I benchmarked
🔒 Local-only: no Obsidian app required, no network calls, no telemetry, sandboxed to your vault
🛠️ 17 tools: full-text search, structured frontmatter queries, backlinks, outlines, tags, daily notes, and 8 conservative write tools (frontmatter edited in place, verified byte-for-byte)
The part I'm proudest of: the benchmarks are reproducible. The harness, the synthetic 1k/5k/10k-note test vaults (built from the 1911 Encyclopædia Britannica), and every report are committed to the repo — clone it and re-run them yourself.
Setup is one command: npx -y seekstone init — works with Claude Desktop, Claude Code, Cursor, and VS Code, plus a one-click .mcpb bundle for Claude Desktop (no terminal needed).
MIT licensed. I'd love your feedback — especially if you run a big vault. AMA 👇
Report
The local-only approach is honestly what sold me on this, super clean setup. One thing I'd love to see is fuzzy or typo-tolerant search, because right now if I slightly misspell a tag or a term in my vault the results just miss it entirely. Even a simple edit-distance fallback on titles would make this feel way more forgiving day to day.
Report
Maker
@mustafasobgmyg Semantic type search is on our roadmap to implement. Appreciate the feedback, and this is something we will prioritize on the roadmap. Ideally, finding relevant information is the tool's #1 job.
Report
Maker
@mustafasobgmyg Coming back to correct my own earlier reply, because I went and checked the code — typo tolerance is actually already in there, on by default. Every search_vault query runs with edit-distance fuzzy matching plus prefix matching, across titles, body text, and tags (tags are even boosted). "benchamrk" still finds "benchmark" — roughly one typo's worth of slack on short words, two on longer ones.
So if a slightly misspelled term came back empty, I'd genuinely love to see the exact query. Two likely culprits: the typo exceeded the edit-distance budget, or it went through one of the structured tools (exact tag filters don't fuzz) — both are fixable, and I'll turn your example into a test case.
What I meant by the roadmap comment is the different beast: semantic search, matching by meaning ("car" → "automobile"). That's still ahead of us — but for misspellings, you're covered today.
Report
honestly this is exactly what i needed for my vault, love that nothing leaves my machine. one thing that would make it even better is supporting some kind of incremental indexing so the initial setup on a large vault doesnt take forever, maybe with progress feedback so you know its not just hanging
Report
Maker
@ebraryqku Appreciate the feedback. Makes perfect sense. We will include that into the roadmap for consideration!
The local-only approach is honestly what sold me on this, super clean setup. One thing I'd love to see is fuzzy or typo-tolerant search, because right now if I slightly misspell a tag or a term in my vault the results just miss it entirely. Even a simple edit-distance fallback on titles would make this feel way more forgiving day to day.
@mustafasobgmyg Semantic type search is on our roadmap to implement. Appreciate the feedback, and this is something we will prioritize on the roadmap. Ideally, finding relevant information is the tool's #1 job.
@mustafasobgmyg Coming back to correct my own earlier reply, because I went and checked the code — typo tolerance is actually already in there, on by default. Every search_vault query runs with edit-distance fuzzy matching plus prefix matching, across titles, body text, and tags (tags are even boosted). "benchamrk" still finds "benchmark" — roughly one typo's worth of slack on short words, two on longer ones.
So if a slightly misspelled term came back empty, I'd genuinely love to see the exact query. Two likely culprits: the typo exceeded the edit-distance budget, or it went through one of the structured tools (exact tag filters don't fuzz) — both are fixable, and I'll turn your example into a test case.
What I meant by the roadmap comment is the different beast: semantic search, matching by meaning ("car" → "automobile"). That's still ahead of us — but for misspellings, you're covered today.
honestly this is exactly what i needed for my vault, love that nothing leaves my machine. one thing that would make it even better is supporting some kind of incremental indexing so the initial setup on a large vault doesnt take forever, maybe with progress feedback so you know its not just hanging
@ebraryqku Appreciate the feedback. Makes perfect sense. We will include that into the roadmap for consideration!