WikiMoth MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| WIKIMOTH_VAULT | No | Path to the Wikilink vault (Obsidian vault or notes folder). If not set, the server may use the current directory or a default. |
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 | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| recallA | Deterministically recall the note-chain from the user's WikiMoth [[wikilink]] memory that answers a question. Walks the authored links (multi-hop), returns the exact notes with NO LLM call to retrieve, far fewer tokens than dumping the whole vault, and the same result every time. Call this before answering anything that might live in the user's notes, memory, or past sessions. |
| statusA | Report the connected WikiMoth memory vault: path, note and chunk counts, whole-vault token size, and the token backend. Use to confirm memory is wired up. |
| list_conflictsA | Deterministically list contradiction CANDIDATES in the WikiMoth vault: notes that assert different values for the same (subject, predicate). No model finds them. Each candidate is for YOU to adjudicate: decide if it is a real contradiction and which note is current. Notes tagged valid-time 'disjoint' are likely a legitimate succession (consider superseding), 'overlapping' is a real conflict. Use before trusting a possibly-stale fact recalled from memory. |
| list_lintA | Deterministically report vault-hygiene issues: broken [[links]], orphan notes, duplicate identities, empty stubs, stale/expired notes, and supersession chains/cycles. No model. Read-only. Use to check the memory's structural health or before trusting a possibly-broken link. |
| list_duplicatesA | Deterministically find exact and near-duplicate notes (MinHash/Jaccard, no model). WikiMoth capture is append-only and never merges, so content gets restated; this surfaces it. Candidates only: decide which to keep (consider superseding the older one). |
| list_fadingA | Deterministically list the 'fading' review queue: notes going cold (old, rarely linked, rarely recalled), scored by a decay + access + connectivity strength. Read-only, nothing is deleted. Use to suggest what the user might archive, refresh, or supersede. |
| supersedeA | Mark an OLD note as replaced by a NEW one, WITHOUT deleting it (invalidate-don't-delete: the file stays, its frontmatter records superseded_by/valid_to/status). Call this AFTER you have adjudicated that NEW genuinely replaces OLD (e.g. from a list_conflicts candidate). OLD/NEW are note stems, slugs, or paths. |
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 7 tools
Each tool has a clearly distinct purpose: recall retrieves note-chains; status reports vault metadata; list_duplicates, list_conflicts, list_lint, and list_fading each surface a different kind of maintenance issue; supersede performs the single write action. No two tools could be reasonably confused.
The naming is predominantly snake_case with a consistent list_ prefix for the four inspection tools, and recall/supersede are clear action verbs. The one deviation is 'status', which is a noun rather than a verb_phrase, though it is still intuitive.
Seven tools is well-scoped for the server's purpose of maintaining and recalling from a WikiMoth vault. Each tool addresses a distinct need without redundancy, and the count feels neither thin nor bloated.
The set covers the key lifecycle: detect issues (duplicates, conflicts, lint, fading), adjudicate via recall/status, and resolve via supersede. Minor gaps exist such as no direct 'get_note' or vault-wide listing tool, but recall likely covers most retrieval needs and the core maintenance loop is complete.