vault-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| VAULT_LANG | No | The language the server speaks: 'en' (default) or 'pt'. Covers tool and field descriptions, input refusals, startup errors, result labels, and write-layer errors. | en |
| VAULT_PATH | Yes | The absolute path to the vault root. Mandatory. If not set or not a directory, the server exits with code 1. | |
| VAULT_AUTO_PUSH | No | When set to '1', every write also runs git push after commit. Off by default. | 0 |
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": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| vault_searchA | Lexical-semantic search over the vault (BM25 plus one wiki-link hop). Call it before answering any question about the user's decisions, patterns, gotchas or history, and before recording a new learning. Returns snippets already cited as |
| vault_get_noteA | Reads a whole note by its vault-relative path (e.g. |
| vault_listA | Lists notes by metadata — tipo, tags, status, folder — without looking at content. Use it for inventory ("which projects are active?", "which notes carry the jwt tag?"), not to search by subject: for subject use vault_search. |
| vault_backlinksA | Lists the notes pointing at the given note. Use it to gauge how connected a subject is, to find the MOC that indexes the note, or to weigh the impact of changing or renaming it. |
| vault_write_noteA | Creates or replaces a whole note, with frontmatter guaranteed, and commits it to the vault's git. It replaces the entire file: to change one passage use vault_edit_note, and to record a learning use vault_learn, which picks the destination and propagates on its own. |
| vault_edit_noteA | Replaces ONE exact passage of an existing note and commits. Fails, without writing, if the passage does not appear or appears more than once — in that case send more context in old_text. |
| vault_learnA | Records a learning in the vault. Call it whenever something non-obvious and reusable comes up during the session — an architecture decision, a pattern, a gotcha, a configuration trap — without asking first where to save it: the server decides on its own between appending to the existing note that already covers the subject and creating a new one (the bias is to create), and propagates on its own to the domain MOC and the daily note (and to the knowledge index when the domain is new), all in a single commit. Show the returned diff to the user. |
| vault_moveA | Moves, renames, promotes or archives a note, fixing on its own every link that would otherwise start pointing somewhere else, migrating its entry between domain MOCs and committing it all at once. |
| vault_deleteA | Deletes a note and commits, removing its line from the domain MOC. Refuses, without deleting, if the note has no committed version in HEAD (there would be no way to undo), if it is structural (MOC, daily note, index) or if it lives under |
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 9 tools
Each tool targets a distinct operation: search, list metadata, read note, backlinks, whole-file write, passage edit, automatic learning, move, and delete. The descriptions explicitly contrast overlapping-sounding tools (vault_write_note vs vault_edit_note vs vault_learn; vault_search vs vault_list), leaving little room for misselection.
All tools share the vault_ prefix and snake_case, and most follow a verb_noun shape like vault_get_note, vault_write_note, and vault_edit_note. A few names are bare verbs or nouns without an explicit object (vault_search, vault_learn, vault_backlinks), but the pattern is still predictable and readable.
Nine tools is well-scoped for a knowledge vault server: there is a clear placement for reading, searching, listing, writing, editing, learning, moving, and deleting notes. Each tool earns its place and none is redundant.
The tool set covers the full note lifecycle — discovery, retrieval, creation, editing, deletion, and move/rename — plus vault-specific needs like backlinks, link fixing, MOC propagation, and git commits. No critical dead ends are obvious from the described surface.