Seekstone vs mcpvault.
mcpvault gets the most important thing right: like Seekstone, it's filesystem-direct and returns excerpts, so its search payloads stay ~2 KB at any vault size — no Local REST API plugin, no running app. The gap is latency and depth: mcpvault re-scans the vault in a subprocess per query (958 ms warm at 10,000 notes), while Seekstone serves the same queries from a warm in-process index in 6.2 ms, and adds tools no other benchmarked server has — structured frontmatter queries, backlinks, outlines, and tag listings.
Every number below comes from an open-source harness run on committed 1,000 / 5,000 / 10,000-note vaults — reproducible, not estimated. Full methodology on the benchmarks page; mcpvault lives at bitbonsai/mcpvault.
The comparison in one table.
| Seekstone | mcpvault | |
|---|---|---|
| Architecture | Filesystem-direct, warm in-process index | Filesystem-direct, subprocess scan per query |
| Local REST API plugin | Not needed | Not needed |
| Obsidian app running | Not needed | Not needed |
| Search payload @ 10k notes (mean) | 2.0 KB | 2.2 KB |
| Warm search latency @ 10k notes | 6.2 ms | 958 ms (~155× slower) |
| Backlinks, outlines, tags, structured queries | Built-in (get_backlinks, outline_note, list_tags, query_notes) | Not offered |
What happens as your vault grows.
A vault only gets bigger. Here's both servers on the same committed vaults at 1,000, 5,000, and 10,000 notes — payload first, then warm latency.
Search payload — per query lower is better
| Server | 1k notes | 5k notes | 10k notes |
|---|---|---|---|
| Seekstone | 1.6 KB | 1.8 KB | 2.0 KB |
| mcpvault | 1.7 KB | 1.9 KB | 2.2 KB |
Warm search latency lower is better
| Server | 1k notes | 5k notes | 10k notes |
|---|---|---|---|
| Seekstone | 1.1 ms | 3.1 ms | 6.2 ms |
| mcpvault | 96 ms | 467 ms | 958 ms |
Why the numbers differ.
Seekstone and mcpvault agree on the big architectural call — filesystem-direct, excerpts-not-documents — which is why both sit in the ~2 KB payload class while REST proxies climb into the megabytes. The difference is what happens per query: mcpvault spawns a subprocess and scans the vault each time, so its warm latency grows 10× from a 1k-note vault (96 ms) to a 10k-note vault (958 ms). Seekstone builds its full-text index once, keeps it live with a file watcher, and answers from memory: 6.2 ms at 10,000 notes, barely moving with scale.
The second difference is tool depth. Seekstone ships 17 tools, including several no other benchmarked server offers: query_notes for structured frontmatter queries that answer in a few hundred bytes, get_backlinks and get_links for graph navigation, outline_note for section-level reads, and list_tags — plus periodic-notes support that works with Obsidian closed.
Where mcpvault has the edge.
No tool wins every axis, and a comparison that pretends otherwise isn't worth your trust.
Payload discipline.
mcpvault is the only other server we benchmarked in the ~2 KB class — it returns excerpts, not documents, and stays flat as the vault grows. On the metric that matters most for context tax, it's genuinely good.
The same no-plugin story.
Like Seekstone, it reads the vault from disk: no Local REST API plugin, no API key, and it works with Obsidian closed. The deployment story is equally simple.
Stateless simplicity.
It holds nothing in memory between queries — no resident index, no file watcher. If you query your vault rarely and RAM matters more than latency, that trade-off is defensible.
Reproduce every figure.
The harness, the query set, and all three vaults are committed to the Seekstone repo. Nothing on this page is a marketing estimate.
Trying Seekstone takes about 30 seconds.
Seekstone is a standard MCP stdio server — it works in any client that runs mcpvault, side by side with your current setup, and doesn't touch your notes until you ask it to. Guided setup below, or see the per-client install guides.
Common questions.
Why choose Seekstone over mcpvault if payloads are similar?
Latency and tools. Both return ~2 KB excerpt payloads, but mcpvault re-scans the vault per query — 958 ms warm at 10,000 notes vs 6.2 ms from Seekstone's warm in-process index, a gap that widens with vault size. Seekstone also adds structured frontmatter queries, backlinks, outlines, and tag tools that mcpvault doesn't offer.
Is mcpvault's approach ever preferable?
If you query rarely and want zero resident memory, its stateless design is a fair trade — nothing stays warm between calls. Seekstone spends a few MB of RAM on its index to make every query millisecond-fast; mcpvault spends nothing and pays per query instead.
Are these numbers reproducible?
Yes — every figure comes from an open-source harness run against committed 1,000 / 5,000 / 10,000-note vaults generated from public-domain text, 20 runs per query, cold and warm reported separately. Clone the Seekstone repo and re-run it.