Mycelium ships in two tiers. Filesystem tools give sovereignty and reliability — markdown on disk, available even when Obsidian is closed. CLI tools give aliveness — the AI reaches inside the running app. Everything below ships in v1.3.0; anything still in design is labelled Coming Next.
102 tools, split by what they depend on. The filesystem tier is the dependable substrate; the CLI tier is the living application. If the app is closed, the 74 keep working.
Filesystem = sovereignty & reliability. · CLI = aliveness, inside the running Obsidian app.
When the app is running, the CLI tier becomes a full Obsidian operator — using Obsidian’s own search, your templates, Bases, history and commands.
It can inspect internal app state, use Obsidian APIs, bridge plugin APIs, and prototype operations that aren’t yet formal tools. This is power that comes with ownership — you own the vault, you choose which tools are exposed, and you can disable advanced tools per deployment.
eval_obsidian is an advanced operator tool — enable it deliberately, and disable any tool with OBSIDIAN_DISABLED_TOOLS. Local ownership means you decide.Different questions need different retrieval paths — and some need to cross vault boundaries. This is the heart of the product story.
When you remember a phrase, project name, person, or exact term — even if it could live in several vaults.
When you remember the idea, not the words. Optional local embeddings via Ollama make this possible.
When the question lives in relationships: what points here, where does this lead, what’s disconnected? Navigation, not ranking.
When notes carry properties: status, type, priority, owner, area, date, client, stage — anything you tag.
A note is a file and an Obsidian identity and structured content and metadata and a set of links. Mycelium exposes the right layer for each operation.
../ traversal stay blocked.obsidian:// URIs. Native wikilinks stay vault-local; cross-vault movement runs through resolver-backed paths and URIs.A good session starts with get_started: it tells the assistant which vaults exist and which tools fit each job. From there, the resolver ladder gives a recovery path — Obsidian-native resolution before filesystem habits.
// the agent is simply stuck { "error": "Unknown vault", "received": "Research" }
{
"error": "Unknown vault",
"closest_matches": ["Research Vault"],
"next_action": "Retry with vault=
\"Research Vault\""
}
Same pattern for a missing note: the error suggests follow_link, find_note_by_name and search_content as ordered next steps. The agent reads the hint and tries again — no human correction needed.
Mycelium exposes both native Obsidian wikilinks and cross-vault URI targets, so an agnostic AI client writes links that actually resolve — and cites which vault each came from.
# Same vault — a wikilink [[Note Name]] # Across vaults — an Obsidian URI (vault + file URL-encoded, no .md) [Kickoff](obsidian://open?vault=Work&file=Projects%2FKickoff)
These are designed as future direction. They make a forward-looking story — but none of them is presented as a capability in v1.3.0. What ships today for the graph is read-only: backlinks, outlinks, orphans, broken links, health.
Inspiration for where Mycelium goes — not available today.
Help the AI understand hubs, roots, leaves and structural position inside a vault.
Use links and structure to annotate, exclude, or re-rank search results.
Combine semantic relevance with structural importance — without pretending it ships today.
Treat folders from different filesystem locations as one working vault surface.
Portable, structured memory layers built from vault knowledge.
The broader future framing behind graph intelligence and composed knowledge spaces.