vault-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| VAULT_MCP_HOST | No | Host to bind the HTTP server to. Also settable via --host. | 127.0.0.1 |
| VAULT_MCP_HTTP | No | Set to true to serve streamable HTTP at /mcp instead of stdio. Also settable via --http. | false |
| VAULT_MCP_PORT | No | Port to bind the HTTP server to. Also settable via --port. | 8787 |
| VAULT_MCP_ROOT | No | Path to the vault root directory. Defaults to ~/Documents/seandavis. | ~/Documents/seandavis |
| VAULT_MCP_OAUTH_CLIENT_ID | No | OAuth client ID for OAuth authentication (used with --auth google/github). | |
| VAULT_MCP_OAUTH_CLIENT_SECRET | No | OAuth client secret for OAuth authentication (used with --auth google/github). |
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
} |
| logging | {} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| extensions | {
"io.modelcontextprotocol/ui": {}
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| searchC | Search the vault's markdown files. |
| read_noteA | Read a note by wiki-link name (e.g. 'icegate') or vault-relative path (e.g. 'notes/icegate.md'). Returns the resolved path and full content. |
| relatedA | Graph neighborhood of a note: resolved outgoing [[wiki-links]], unresolved link targets, backlinks (notes linking here), and up to 10 notes sharing frontmatter tags. |
| queryA | Run read-only SQL (DuckDB dialect; SELECT/WITH only) over the vault metadata index. The index is rebuilt from the files — it is never a source of truth. Schema: notes(path, name, title, type, tags VARCHAR[], aliases VARCHAR[], date, status, frontmatter JSON, modified TIMESTAMP, size, body /* full note text — SELECT specific columns, not * /) links(source / path /, target / wiki-link name as written */) Examples: SELECT type, count() FROM notes GROUP BY type ORDER BY 2 DESC SELECT path, title FROM notes WHERE list_contains(tags, 'memory') SELECT target, count() n FROM links GROUP BY target ORDER BY n DESC LIMIT 20 SELECT path, json_extract_string(frontmatter, '$.status') FROM notes WHERE type = 'projects' |
| recentB | Most recently modified notes, optionally filtered by type. |
| create_noteA | Create an atomic idea note in notes/ (one idea per note, template frontmatter enforced). Use for durable ideas/insights worth keeping — search first to avoid duplicating an existing note; link related notes in the content with [[wiki-links]]. Fails if the note already exists. |
| edit_noteA | Surgically correct an existing note by exact string replacement. old_text must occur exactly once in the note's current text — read_note first and copy the passage verbatim, adding surrounding lines if it is not unique. Works anywhere in the file, frontmatter included. Prefer this over update_note for corrections: it cannot drop text you did not quote. |
| rename_noteA | Rename a note to a new title. The file becomes slugify(new_title).md in the same directory, the first H1 heading is set to the new title, and [[wiki-links]] to the old name anywhere in the vault are rewritten to the new one (|alias and #heading forms preserved). Fails if a note with the target name already exists. Returns old_path, path, links_rewritten. |
| update_noteA | Rewrite a note's entire body. The frontmatter block is preserved verbatim (use edit_note to change frontmatter). Everything below it is replaced with content — read_note first and carry forward anything that should survive. For targeted corrections use edit_note instead. |
| add_inbox_itemA | Add an open action item to the vault inbox (the source of truth for all open action items). Use for tasks/follow-ups, not ideas or status. |
| append_dailyA | Append a timestamped entry to today's journal Log — for decisions, conclusions, work accomplished, and key insights as they happen. |
| refresh_indexA | Force a rebuild of the metadata index from the files on disk. Returns note and link counts. |
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 12 tools
Most tools target distinct actions (read, search, query, create, edit, rename, etc.), but search and query both retrieve notes via different mechanisms, and edit_note vs update_note have subtle differences that could cause misselection. Overall, the detailed descriptions help clarify boundaries.
Eight tools follow a verb_noun pattern (read_note, create_note, edit_note, rename_note, update_note, add_inbox_item, append_daily, refresh_index), but four tools use single-word names (query, search, related, recent) that deviate from the pattern. This mixed convention is still readable but not fully consistent.
Twelve tools is well within the ideal 3-15 range for a domain of this scope. Each tool serves a clear purpose, covering retrieval, creation, modification, and maintenance without unnecessary bloat.
The vault domain has solid coverage for creating, reading, updating, renaming, and querying notes, but there is no delete or remove tool, which is a notable gap in the note lifecycle. Additional operations like archiving are also absent, though the core workflows are mostly covered.