MCP server for managing a Zettelkasten vault with note creation, linking, and file operations
Vault Keeper demonstrates basic tool structure with visible input schemas and descriptions for all 6 tools. However, multiple critical gaps prevent a higher score: (1) descriptions are minimal (10-60 chars, below the 50-200 char baseline for LLM optimization); (2) parameter descriptions exist but lack constraints, ranges, or format guidance; (3) no output schema documentation; (4) error responses are free-text strings without recovery guidance; (5) security issues including hardcoded VAULT_ROOT and no permission checks; (6) no indication of idempotency or mutation semantics beyond informal 'Risk' labels. The tools follow verb_noun naming convention well (get_next_id, create_note, add_backlink), and all input parameters are typed with descriptions, but the descriptions are surface-level. Tools like 'move_note' and 'add_backlink' lack explicit guidance on side effects, error recovery, or validation rules. Per-tool average is 42/100.
Appends a markdown link of 'note_to_link' to the 'parent_note_rel'.
Creates a new note at the given path (relative to vault root).
Returns the next available ID from the specified folder (e.g., '002 Project' or '003 TechStack').
Returns a greeting from the Vault Keeper MCP.
Moves a note from source to destination (both relative to root).
Prepends text to the beginning of an existing file.
Minimal parameter descriptions lack format, range, and constraint guidance. No parameter specifies allowed characters, length limits, path depth, character encoding, or regex patterns.
No output schema documentation. Tools return free-text strings without typed objects. LLMs cannot parse structured results or chain calls with confidence.
Error responses are unactionable. Messages like 'File not found' or 'Destination already exists' provide no recovery guidance, alternative options, or next steps for the LLM.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 44 | 2026-07-28+ | v2 |
Hardcoded VAULT_ROOT '/Users/shridhar600/Documents/Personal/Shridhar' in source code is not configurable. Production deployments cannot use this server without code modification. Vault path should be a server parameter or environment variable.
No permission checks or authorization gates. Any client can invoke destructive operations (create_note, move_note, prepend_text_to_file) without authentication or role verification.
No idempotency guarantees or semantics declared. Tools like create_note fail on retry with same input; tools like prepend_text_to_file append duplicate content on retry. Agents need idempotency hints to safely handle transient failures.
Tool descriptions are 35-60 chars, below the 50-200 char LLM-optimization baseline. Descriptions like 'Returns the next available ID from the specified folder' lack context on when to call this tool, what the 'ID' numbering scheme is, or expected file naming conventions.
Path traversal validation relies on os.path.normpath and startswith check, which may be bypassed with symlinks or case-sensitive filesystem mismatches. Input should be validated against an allowlist or strict schema.