This MCP server exposes 5 file-system tools with minimal documentation. All tools have descriptions (10-30 chars), but they are generic and lack actionable context for LLM selection. Input schemas are present with basic type info, but parameter descriptions are trivial (e.g., 'The file path where content will be written'). No output schemas are documented. Error handling is minimal, no recovery guidance, no categorization of retryable vs. fatal errors. The tools themselves are simple file operations (read, write, list, create, move) with no composition hints or chaining metadata. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk profiles (WRITE, READ_ONLY, REVERSIBLE). This is a basic STDIO-only file-system wrapper with no LLM-optimized design.

• Add output schemas for all tools. Document what read_file returns (e.g., {content: string, size: number, encoding: string}), what list_directory returns (e.g., {files: [{name, type, size}], total: number}), and what move_file returns (e.g., {source, destination, success: boolean}).
• Expand tool descriptions to 100-200 characters. Include WHEN to use each tool and what it returns. Example: 'Read the contents of a file. Returns the file content as a string. Use this to retrieve note data or configuration files. Fails if the file does not exist or is not readable.'
• Add tool annotations: mark read_file and list_directory with readOnlyHint=true; mark write_file, create_directory, and move_file with destructiveHint=true (or idempotentHint=true if move_file is idempotent).
• Enhance parameter descriptions with constraints. Example: 'The file path to read (absolute or relative to NOTES_DIR; must not contain '..' or symlinks; max 255 chars).'
• Implement error categorization and recovery guidance in the callTool function. Return structured errors: {error: string, category: 'retryable'|'user_fixable'|'fatal', suggestion: string}. Example: 'File not found. Try list_directory() to see available files.'