Asher Vault MCP has well-structured tool definitions with proper JSON schemas and tool annotations. All 6 tools are explicitly registered with names, descriptions, and input schemas. However, descriptions are minimal (10-50 chars), parameter descriptions lack depth, and output schemas are not documented. Error handling is basic. Tool names follow verb_noun convention (vault_*) but lack specificity about what 'vault' means to new users. No pagination support despite potential for large result sets.

• Expand all tool descriptions to 50-200 chars. Example: 'vault_write: Write or overwrite a file in the Vault. Overwrites existing files without warning. Use vault_search to check if a file exists first if you need to preserve it.'
• Document output schemas in tool descriptions or a separate schema map. Example: 'vault_list returns {entries: [{name, type: "file"|"folder", path}]}. vault_search returns {matches: [{name, path}], total_count}.'
• Add pagination to vault_search: accept 'limit' (1-100, default 20) and 'offset' parameters. Return total_count so LLMs know if more results exist.
• Enhance error messages with recovery hints. Example: 'File not found at /path/to/file. Try vault_search("filename") to locate it, or vault_list() to browse the vault.'
• Add a dry_run parameter to vault_move and vault_write to support confirmation workflows. Or document that vault_move is non-idempotent and agents should verify the destination path before calling.

Inferred effective spec: <=2025-11-25.

• Relies on Stateful initialize / Mcp-Session-Id (removed; protocol is stateless) - make each request self-contained