Benchmarked against
the whole field.
Every number on this page comes from an open-source harness run on committed vaults of 1,000, 5,000, and 10,000 notes — public-domain content, 20 runs per query. Nothing here is a marketing estimate — the vaults ship in the repo, so clone it and reproduce each figure exactly.
The only Obsidian MCP server
with published numbers.
Measured against 5 other popular servers — 6 servers total — across 1,000 / 5,000 / 10,000-note vaults — public-domain content, fully reproducible, 20 runs each. The harness and the vaults are open source; clone the repo and verify every figure.
One broad search via a REST-proxy server (mcp-obsidian) returns 97.8 million tokens at 10,000 notes — about 489× larger than Claude's entire ~200K-token context window. The result can't even be sent. Seekstone returns the same search in ~570 tokens.
Latency is nice. Payload is the point.
The Obsidian Local REST API plugin returns full note content for every search hit — tens of megabytes the model has to read. Seekstone returns short ranked excerpts. Same query, up to ~47,000× less to send at 10,000 notes.
| Metric | Seekstone | REST API plugin |
|---|---|---|
| Search payload (mean, 10k vault) | ~2 KB | 62.6 MB |
| Worst-case payload (broad query) | ~2 KB | 245 MB |
| Context tokens (broad query) | ~570 | 65.7 million |
| Warm search latency (10k vault) | 1–6 ms | ~575 ms |
| Obsidian app required | No | Yes |
| Local REST API plugin required | No | Yes |
| Network calls | Zero | HTTP to localhost |
| Search matching | Fuzzy + prefix | Exact / plugin-dependent |
| Frontmatter write safety | Byte-identical | Varies |
This table measures the Local REST API plugin's HTTP API directly — the lower bound for any server built on it. MCP servers that proxy the plugin add JSON-RPC encoding on top: the same broad query via mcp-obsidian peaked at 370.9 MB / 97.8 million tokens in a single tool call.
REST and subprocess servers span ~430–1,550 ms warm search latency at 10,000 notes in the chart above; Seekstone's in-process index serves the same queries in single-digit milliseconds — and the gap only widens as the vault grows.
Watch what happens as your vault grows.
A real vault only gets bigger — and that's where the architectures diverge. Seekstone holds a warm in-process index, so it stays flat on both payload and latency, while REST-proxy and full-scan servers climb with every note.
Holds a warm full-text index and returns ranked excerpts. Flat on both payload and latency — a few KB and a few ms at any vault size.
Spawn a process and scan the disk per query. Latency climbs with the vault — from tens of ms to over a second at 10,000 notes.
Forward to Obsidian's HTTP API, which returns full note content for every hit — tens of megabytes per search, growing with the vault.
Search payload — bytes 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 |
| obsidian-mcp-server | 55 KB | 47 KB | 47 KB |
| obsidian-mcp-pro | 25 KB | 84 KB | 114 KB |
| obsidian-mcp | 18 KB | 105 KB | 201 KB |
| mcp-obsidian | 9.8 MB | 45 MB | 95 MB |
Warm search latency — milliseconds lower is better
| Server | 1k notes | 5k notes | 10k notes |
|---|---|---|---|
| Seekstone | 1.1 ms | 3.1 ms | 6.2 ms |
| obsidian-mcp-pro | 46 ms | 213 ms | 430 ms |
| obsidian-mcp-server | 82 ms | 356 ms | 732 ms |
| obsidian-mcp | 82 ms | 405 ms | 811 ms |
| mcpvault | 96 ms | 467 ms | 958 ms |
| mcp-obsidian | 164 ms | 740 ms | 1,550 ms |
At 10,000 notes that's a ~47,000× payload difference, and Seekstone is 70–250× faster than the proxies — both gaps widening with scale. Seekstone is the only server that stays flat on both axes.
Run it yourself.
The harness lives in the Seekstone repo. It runs each query set against every adapter and reports cold (run 1) and warm (runs 2–N) distributions separately — a cheap warm number can't hide a brutal cold start.
- VaultsCommitted 1,000 / 5,000 / 10,000-note vaults generated from the public-domain 1911 Encyclopædia Britannica — the same size distribution as a real PKM vault, and byte-for-byte reproducible.
- Runs20 per query; warm latency reported as the median (p50).
- PayloadBytes measured on the actual MCP tool response, not an idealized excerpt.
- FieldCompared against obsidian-mcp-server, mcp-obsidian, obsidian-mcp-pro, mcpvault, and obsidian-mcp.
Where Seekstone isn't the answer.
No tool wins every axis. Here's where the trade-offs land — so you can decide with eyes open.
It keeps an index in memory.
Seekstone builds a small in-process search index (a few MB for a typical vault). If you run many MCP servers at once, that's real RAM the REST plugin offloads to the already-running Obsidian process.
The first query is the slow one.
Cold start warms the index in a few seconds. Every query after that is the millisecond latency you see above — but the very first call pays for the index build.
It's lexical, not semantic.
Search is fuzzy + prefix matching, not embedding-based semantic search. That's deliberate: no local model, no API key, no extra dependency — at the cost of pure meaning-based recall.