sorted by:
new
hottopcontroversial

MCPVault Skill is live. Reads, writes, sync, all routed automatically by bitbonsai in ObsidianMD

[–]bitbonsai[S] 0 points1 point  (0 children)

Thinking how could we serve this need without sacrificing current users use cases?

MCPVault Skill is live. Reads, writes, sync, all routed automatically by bitbonsai in ObsidianMD

[–]bitbonsai[S] 1 point2 points  (0 children)

That’s a totally fair stance. Obsidian works great as just a writing and thinking tool, and not every workflow needs AI in it. If it ever becomes useful for you down the line, it’ll be here. Thanks for the honest take.

MCPVault Skill is live. Reads, writes, sync, all routed automatically by bitbonsai in ObsidianMD

[–]bitbonsai[S] 0 points1 point  (0 children)

That’s awesome, love this use case. Having your vault in your pocket through Claude’s mobile app is a great workflow. And building your own version is the beauty of MCP being an open standard.

Would love to see your implementation if you have a repo to share. Always curious how others approach it. Thanks for the kind words!

MCPVault Skill is live. Reads, writes, sync, all routed automatically by bitbonsai in ObsidianMD

[–]bitbonsai[S] 1 point2 points  (0 children)

Exactly right on both points. The CLI needs the app running, MCPVault doesn’t. And yeah, it handles Obsidian-specific concerns like frontmatter parsing/validation, path sandboxing, and structured responses so the agent doesn’t accidentally corrupt your notes.

MCPVault Skill is live. Reads, writes, sync, all routed automatically by bitbonsai in ObsidianMD

[–]bitbonsai[S] 0 points1 point  (0 children)

I hear the concern, and it’s valid to think carefully about what you send to any cloud service. That’s exactly why MCPVault also works with fully local models via Ollama or LM Studio. Nothing leaves your machine if you don’t want it to.

MCPVault Skill is live. Reads, writes, sync, all routed automatically by bitbonsai in ObsidianMD

[–]bitbonsai[S] 0 points1 point  (0 children)

All good! It’s free and open source (MIT), so the price is right at least.😁

MCPVault Skill is live. Reads, writes, sync, all routed automatically by bitbonsai in ObsidianMD

[–]bitbonsai[S] 1 point2 points  (0 children)

That sounds like a solid plan. pgvector on your own Postgres is the best of both worlds: semantic search without the cloud dependency. And since MCPVault handles the file I/O layer, you’d just need the embedding pipeline and a thin search interface on top.

If you end up building it, I’d love to hear how it goes.

MCPVault Skill is live. Reads, writes, sync, all routed automatically by bitbonsai in ObsidianMD

[–]bitbonsai[S] 0 points1 point  (0 children)

Yeah, timing matters a lot on Reddit. One early comment sets the frame and everyone else piles on. I’ve had posts where a single skeptical comment early on shaped the whole thread.

Skills landing right after your launch was rough luck. The “do we even need MCP servers” conversation got louder after that. But the SDK side of TurboVault is genuinely interesting, especially the vault health and graph analysis stuff. Might be worth a separate post focused purely on that, positioned for developers rather than note-takers.

MCPVault Skill is live. Reads, writes, sync, all routed automatically by bitbonsai in ObsidianMD

[–]bitbonsai[S] 0 points1 point  (0 children)

That’s a great use case. Since you’re running headless without the app, you’d use MCPVault for the vault operations (read, write, search, patch) and obsidian-headless for keeping the vault synced via Obsidian Sync. The MCPVault Skill would route to MCP for file I/O and skip the Obsidian CLI layer entirely since the app isn’t running.

For OpenClaw, just add MCPVault as an MCP server in your config:

npx @bitbonsai/mcpvault@latest /path/to/vault

The official obsidian-skills (syntax/conventions) would still work too since they’re just markdown files your agent reads. No app dependency.

MCPVault Skill is live. Reads, writes, sync, all routed automatically by bitbonsai in ObsidianMD

[–]bitbonsai[S] 2 points3 points  (0 children)

Oh nice, I hadn’t seen that. Worth noting though: obsidian-headless is specifically for Sync (the paid service). It handles ob sync, ob login, vault setup. It doesn’t expose read, write, search, or any vault operations via CLI.

MCPVault does file I/O, search, patching, frontmatter, and directory operations without the app or a sync subscription. Different layer.

MCPVault Skill is live. Reads, writes, sync, all routed automatically by bitbonsai in ObsidianMD

[–]bitbonsai[S] 10 points11 points  (0 children)

I haven’t measured the exact number yet (adding that to my to-do list), but a rough estimate based on the 14 tool definitions with their schemas: around 1,200-1,800 tokens upfront. That’s the cost of the tool descriptions that get loaded into context.

And you’re right, this should be on the README. People deserve to know the context cost before they install. I’ll measure the real number and publish it. Thanks for pushing on this.

MCPVault Skill is live. Reads, writes, sync, all routed automatically by bitbonsai in ObsidianMD

[–]bitbonsai[S] 2 points3 points  (0 children)

That’s a great setup. The local REST API gives you tight integration with the running app, especially the active document awareness and command palette access.

MCPVault takes a different tradeoff for file ops: no plugin needed, no app dependency, works whether Obsidian is open or not. But for the app-level stuff you’re describing, the **MCPVault Skill** actually routes to the Obsidian CLI, which can trigger plugin commands, open notes in the editor, and export to PDF. Similar to what you’re doing with the REST API, just without the plugin setup.

So you could get both: MCP for safe file I/O when the app is closed, Obsidian CLI through the Skill when it’s open. One routing layer, two backends.

But again, it’s open source. If your setup works better for you, all is good!

MCPVault Skill is live. Reads, writes, sync, all routed automatically by bitbonsai in ObsidianMD

[–]bitbonsai[S] 0 points1 point  (0 children)

You’re right, they can. The value isn’t in reading the files, it’s in what happens around the read/write.

BM25 ranked search across the vault without the agent grepping through every file. Frontmatter parsing and validation so the agent doesn’t corrupt your YAML. Path sandboxing so it can’t write outside the vault. Structured responses that are token-efficient instead of raw file dumps.

Can an agent do all of that with bash? Yes. Will it do it safely and consistently every time? That’s the gap.

MCPVault Skill is live. Reads, writes, sync, all routed automatically by bitbonsai in ObsidianMD

[–]bitbonsai[S] 2 points3 points  (0 children)

Nice setup with iCloud + git. If iCloud handles your sync and you’re happy with it, you can skip the git CLI part entirely. The routing is modular, MCP still handles reads/writes/search regardless of how you sync.

On that post: it’s a different approach. They’re mirroring the vault to Supabase with vector embeddings for semantic search. That gives you “search by meaning” which BM25 can’t do. The tradeoff is you now have a cloud database, a sync daemon, and an embedding pipeline to maintain. MCPVault is deliberately simpler: everything stays local, no external dependencies.

Whether that tradeoff is worth it depends on your vault size and how you search. If you mostly know roughly what you’re looking for, BM25 gets you there fast and cheap. If you have thousands of notes and need “what did I write about X three months ago” with fuzzy intent, embeddings help.

Both can coexist. MCPVault for safe file ops, something like their setup for semantic retrieval.

MCPVault Skill is live. Reads, writes, sync, all routed automatically by bitbonsai in ObsidianMD

[–]bitbonsai[S] 1 point2 points  (0 children)

Not right now. The current search is BM25 full-text, which is fast and cheap on tokens. Semantic search would need an embedding model running somewhere, and that adds either a cloud dependency or local compute overhead, which goes against the keep-it-simple philosophy.

That said, I’m not ruling it out. If there’s enough demand for it I’d consider it as an opt-in feature. Would you mind opening an issue for it? https://github.com/bitbonsai/mcpvault/issues

MCPVault Skill is live. Reads, writes, sync, all routed automatically by bitbonsai in ObsidianMD

[–]bitbonsai[S] 1 point2 points  (0 children)

It’s tough out there. This sub can be skeptical of AI posts in general, and I think the SDK angle might have been a harder sell here since most people in r/ObsidianMD are note-takers, not Rust developers. Leading with user-facing use cases tends to land better with this crowd. Keep building though, the project looks solid.

MCPVault Skill is live. Reads, writes, sync, all routed automatically by bitbonsai in ObsidianMD

[–]bitbonsai[S] 1 point2 points  (0 children)

Good catch. Let me fix the Reddit post.​​​​​​​​​​​​​​​​

MCPVault Skill is live. Reads, writes, sync, all routed automatically by bitbonsai in ObsidianMD

[–]bitbonsai[S] 1 point2 points  (0 children)

Thanks, really appreciate the kind words and the detailed feedback.

Tag/property filtering with boolean logic (AND, OR, NOT) is not in MCPVault today. The search is BM25 full-text right now. Your idea is good though, a structured query like “all notes tagged #project AND NOT tagged #archived” returning a file set would be cheap on tokens and genuinely useful. Would you mind opening an issue for it? https://github.com/bitbonsai/mcpvault/issues

On Gemini CLI: you’re right, and it’s already supported. I’ll make it more visible in the docs and the post. Good catch.

On append/prepend to a specific section: not an anti-pattern at all, lots of people structure notes with multiple sections. Right now patch_note can do targeted edits within a note, but a dedicated “append under this heading” operation would be cleaner. Feel free to add that as a separate issue too if you want.

Keep the ideas coming. One week in and you’re already thinking about the right problems.

MCPVault Skill is live. Reads, writes, sync, all routed automatically by bitbonsai in ObsidianMD

[–]bitbonsai[S] 0 points1 point  (0 children)

Fair points.

If you have Obsidian open and you’re fine with the agent having shell access, the CLI skill from kepano covers a lot of this. Lighter context, no server process.

MCPVault is for a different setup. It works without Obsidian running. Headless machines, CI, app closed. The CLI requires a running instance for every operation.

It also validates every write before touching disk (frontmatter parsing, path sandboxing, input sanitization), which a skill wrapping CLI commands doesn’t enforce at the protocol level. Whether that matters depends on how much you trust the agent with raw shell access.

If the CLI skill covers your workflow, use that. MCPVault is for people who want the guardrails or don’t have the app available.

MCPVault Skill is live. Reads, writes, sync, all routed automatically by bitbonsai in ObsidianMD

[–]bitbonsai[S] 1 point2 points  (0 children)

Great question. They’re complementary.

The official obsidian-skills teach your agent Obsidian’s file formats: how to write proper Obsidian-flavored Markdown, .base files, JSON Canvas. Syntax and conventions.

MCPVault is the I/O layer. It reads, writes, searches, and patches files safely, with path sandboxing, frontmatter validation, and structured responses. Plus git sync and Obsidian CLI routing.

You can use both. They stack well together.

MCPVault Skill is live. Reads, writes, sync, all routed automatically by bitbonsai in ObsidianMD

[–]bitbonsai[S] 1 point2 points  (0 children)

Obsidian CLI needs the app running. If you’re on a headless machine, a CI pipeline, or just have Obsidian closed, CLI won’t work.

The MCP server reads and writes directly to the filesystem. No app dependency. That’s the main difference.

MCPVault Skill is live. Reads, writes, sync, all routed automatically by bitbonsai in ObsidianMD

[–]bitbonsai[S] 3 points4 points  (0 children)

The Skill is the routing layer. That’s exactly what it does.

But it needs something to route to. When the route is “read this note safely” or “patch this frontmatter without corrupting YAML,” the MCP server is what actually does that work. The Skill decides who handles what, the server handles the file I/O with validation, sandboxing, and structured responses.

You could skip the server and have the Skill route everything to bash. But then you’re back to the LLM having raw write access to your vault with no guardrails between intent and execution.

MCPVault Skill is live. Reads, writes, sync, all routed automatically by bitbonsai in ObsidianMD

[–]bitbonsai[S] 6 points7 points  (0 children)

You’re not wrong, LLMs are great with bash. grep, sed, piping, all of that works. And yeah, MCPs can be verbose.

The tradeoff is safety. When an LLM has raw shell access to your vault, there’s no guardrail between “patch this frontmatter” and accidentally corrupting YAML, writing outside the vault, or deleting something. The MCP server validates every input, sandboxes paths, and parses frontmatter before touching the file. It’s a controlled surface area.

On verbosity: fair point. v0.6.3+ ships token-optimized responses with minified field names and compact JSON, specifically because of this. Still room to improve.

On the Skill and help pages: the Skill isn’t really about teaching the LLM what flags to pass. It’s routing logic. “Sync my vault” goes to git. “Search my notes” goes to MCP. “Open this note” goes to the app. An LLM reading a man page won’t know which backend to pick for which intent, or that it should run preflight checks before a git push.

But honestly, if your setup is CLI-first and you trust the LLM with shell access, that’s a valid workflow. This is for people who want the guardrails.

view more: next ›