Context
This is feedback from an AI agent (GitHub Copilot, operating as a Chief of Staff agent) that tested the vault MCP tools in a real workspace session. The agent manages files, drafts, and operational state daily — this evaluation reflects what a power-user agent would need.
What works well
Tool naming (90% match)
The tool names map almost perfectly to standard VS Code workspace file tools — vault_read_file, vault_create_file, vault_list_dir, vault_grep_search, vault_file_search. No learning curve. An agent that knows how to work with files knows how to work with the vault.
Metadata without unlock
list_dir and file_search working without unlock is excellent. An agent can browse and locate files without requiring the user to unlock first — useful for context loading at session start.
Tags
The tags parameter on create_file is a useful addition that standard workspace tools don't have. Helpful for classifying files by domain (e.g., email-draft, correspondence, financial).
Unlock gate
The security model is sound. The agent attempted vault unlock in a terminal and was correctly blocked at the passphrase prompt — it cannot proceed without human input. The passphrase never transits through agent context. Time-limited unlock sessions work as expected.
What's missing
1. vault_replace_string_in_file / vault_multi_replace_string_in_file (critical)
This is the biggest gap. The agent can create files but cannot edit them. In practice, editing is the most frequent file operation — updating drafts, appending to documents, correcting content. Without this, the workaround is read → modify in memory → overwrite, which is fragile and wasteful.
2. vault_delete_file
The agent created a test file during evaluation and has no way to clean it up. Minor, but needed for basic file lifecycle.
3. vault_status
Knowing whether the vault is locked before attempting a content operation would save a failed call + "please unlock" roundtrip. The agent could check proactively at session start and prompt the user upfront instead of discovering the lock state via an error.
Minor: parameter inconsistency
vault_grep_search uses a pattern parameter, while the standard workspace grep_search tool uses query + isRegexp. This means the agent occasionally passes the wrong parameter name by habit. Consider matching the workspace tool signature, or accepting both parameter names.
Bottom line
The vault is usable today for read-only encrypted storage — storing sensitive files that the agent can browse and retrieve when unlocked. Adding replace_string_in_file and delete_file would make it a full replacement for convention-based private file workflows (e.g., gitignored private/ folders). The unlock gate and metadata separation are well-designed.
Context
This is feedback from an AI agent (GitHub Copilot, operating as a Chief of Staff agent) that tested the vault MCP tools in a real workspace session. The agent manages files, drafts, and operational state daily — this evaluation reflects what a power-user agent would need.
What works well
Tool naming (90% match)
The tool names map almost perfectly to standard VS Code workspace file tools —
vault_read_file,vault_create_file,vault_list_dir,vault_grep_search,vault_file_search. No learning curve. An agent that knows how to work with files knows how to work with the vault.Metadata without unlock
list_dirandfile_searchworking without unlock is excellent. An agent can browse and locate files without requiring the user to unlock first — useful for context loading at session start.Tags
The
tagsparameter oncreate_fileis a useful addition that standard workspace tools don't have. Helpful for classifying files by domain (e.g.,email-draft,correspondence,financial).Unlock gate
The security model is sound. The agent attempted
vault unlockin a terminal and was correctly blocked at the passphrase prompt — it cannot proceed without human input. The passphrase never transits through agent context. Time-limited unlock sessions work as expected.What's missing
1.
vault_replace_string_in_file/vault_multi_replace_string_in_file(critical)This is the biggest gap. The agent can create files but cannot edit them. In practice, editing is the most frequent file operation — updating drafts, appending to documents, correcting content. Without this, the workaround is read → modify in memory → overwrite, which is fragile and wasteful.
2.
vault_delete_fileThe agent created a test file during evaluation and has no way to clean it up. Minor, but needed for basic file lifecycle.
3.
vault_statusKnowing whether the vault is locked before attempting a content operation would save a failed call + "please unlock" roundtrip. The agent could check proactively at session start and prompt the user upfront instead of discovering the lock state via an error.
Minor: parameter inconsistency
vault_grep_searchuses apatternparameter, while the standard workspacegrep_searchtool usesquery+isRegexp. This means the agent occasionally passes the wrong parameter name by habit. Consider matching the workspace tool signature, or accepting both parameter names.Bottom line
The vault is usable today for read-only encrypted storage — storing sensitive files that the agent can browse and retrieve when unlocked. Adding
replace_string_in_fileanddelete_filewould make it a full replacement for convention-based private file workflows (e.g., gitignoredprivate/folders). The unlock gate and metadata separation are well-designed.