epsilongraph
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| OBSIDIAN_MCP_DATA | No | Moves the heavy per-vault cache (BM25 index, embeddings) to ~/.cache/obsidian-mcp/vaults/{slug}/ instead of the vault-local .obsidian-mcp directory used by the Layer 0 obsidian-mcp server. | |
| EPSILONGRAPH_INDEX | No | The path to the SQLite index. The index lives at ~/.cache/epsilongraph/index.sqlite by default — outside the vault, so it is never committed and never syncs. | |
| EPSILONGRAPH_VAULT | No | The path to the Obsidian vault to index and serve. Vault resolution order: --vault → $EPSILONGRAPH_VAULT → ~/.config/epsilongraph/config.json → Obsidian's own registry (obsidian.json, the vault marked "open": true) → cwd. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| vault_packA | Budgeted, provenance-annotated context pack for a task or question. Returns ranked notes with WHY each matched, whether it is grounded (and by what), what constrains it, and what it applies to. Use this first for any question about how to do something in this vault. Cheaper and more trustworthy than reading whole notes. |
| vault_claimA | The epistemic state of one rule or note: its grounding, whether it has been tested and in how many distinct projects, recorded disagreements, blast radius if changed, and what the note admits it does not know. Use before relying on a rule, and before changing one. |
| vault_impactA | The blast radius of changing a note. By default this is the TRANSITIVE closure, not depth-1: depth-1 understates the falsified set by a median of 3.9x and up to 9.5x on the notes that matter. semantics='falsified' (default) answers 'what is now FALSE?' and follows only 'Governed by', because that is the one bucket asserting content conformance. semantics='needs_reread' also follows 'Read first', which asserts a reading order rather than conformance, and answers 'what must I re-examine?' -- a much larger set. Run before editing any framework note. |
| vault_load_bearingB | Every note ranked by how much of the vault a change to it would falsify. On this vault the answer is bimodal: a handful of notes falsify 30-50% of the corpus and the large majority falsify nothing. Use this to decide where to be careful. |
| vault_gapsA | What the vault itself admits it does not know, gathered from the notes' own [!todo] and [!question] callouts. Read this BEFORE proposing a new direction: the corpus may already record the gap, or may already have closed it. |
| vault_searchC | Ranked notes for a query, with match explanation and provenance. |
| vault_neighborsB | Typed neighbours of a note. The eight buckets are not equivalent: Governed by and Read first are constraints, Source and Evidence are grounding, Applied in is where it is executed, See also is the weakest. |
| vault_getB | Full markdown of one note. Use after pack/search to drill in. |
| vault_skeletonA | Every rule and every typed relation in the vault, with no bodies (~29k tokens here, 18% of the corpus). Small enough to hold for a whole session, which is usually better than repeated searching. |
| vault_statsB | Index size, layer and provenance distribution, and freshness. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 10 tools
Most tools target clearly distinct operations (search, get, pack, neighbors, skeleton, stats, gaps). However, vault_load_bearing vs vault_impact both compute falsification/blast radius (global ranking vs per-note transitive closure), and vault_claim also surfaces blast radius, so an agent could conflate these three. The rich descriptions mostly resolve the overlap, but the boundaries are not as crisp as they could be.
Every tool uses the same vault_ prefix followed by a single descriptive noun (search, get, pack, neighbors, skeleton, stats, gaps, claim, impact, load_bearing). The convention is uniform snake_case throughout with no mixing of styles or verb forms.
Ten tools is well-scoped for a knowledge-vault query and analysis server, with each tool earning its place across retrieval (search, get, pack), structure (neighbors, skeleton), and epistemic analysis (claim, impact, load_bearing, gaps, stats). Nothing feels redundant or padding.
The read/analysis surface is comprehensive: retrieval, structure, provenance, epistemic state, and impact are all covered, plus a session-level skeleton and stats. The one notable gap is that descriptions repeatedly reference editing and changing notes, yet no mutation tool (edit/update) exists in the set, leaving a workflow dead-end if agents are meant to act on the vault.