Vaultwright demonstrates solid foundational quality with complete JSON schemas, clear naming conventions, and consistent parameter documentation. All 10 tools follow verb_noun patterns (get_, scan_, read_, search_, extract_, find_, create_). Schemas are properly typed with required fields declared. However, descriptions are terse (averaging ~80 chars, below the 194-char baseline), lack WHEN/WHY context, and parameter descriptions are minimal. Output schemas are undocumented, LLMs cannot predict response structure. Error handling is present but generic. Write operations (create_*) lack confirmation/dry-run patterns. No tool annotations (readOnlyHint/destructiveHint) despite clear risk stratification.

• Document output schemas for all tools. Specify return type (object/array), field names, types, and examples. E.g., get_vault_summary should return {summary: string, fileCount: number, folderCount: number, excludedCount: number}.
• Expand tool descriptions to 150 - 250 chars. Add WHEN/WHY context: 'Use get_vault_summary for a quick overview of vault structure and file counts. Use scan_vault for detailed metadata extraction across all notes. Call get_vault_summary first to understand vault scope.'
• Add confirmation/dry-run pattern to write tools. Introduce a 'dryRun' boolean parameter (default false) to preview changes without committing. Or add separate preview_* tools that return proposed changes for agent review.
• Annotate tools with readOnlyHint and destructiveHint in the tool definition. E.g., {name: 'get_vault_summary', readOnlyHint: true, ...} and {name: 'create_review_note', destructiveHint: true, ...}.
• Add parameter descriptions and constraints. E.g., maxChars: 'Maximum characters to read from the note (1 - 1000000; default 100000). Larger values may timeout on slow disks.' and excludedFolders: 'Array of folder names to skip (e.g., ["Archive", "Templates"]). Paths are relative to vaultPath.'