Three tools with basic schemas and descriptions, but significant gaps in parameter documentation and output schema clarity. view_buffers has no parameters (empty schema is valid but limits flexibility). send_normal_mode and send_command_mode have single required string parameters with minimal descriptions. No output schemas documented for any tool. Descriptions are present but generic (10-194 chars baseline; these range 50-180 chars). No error handling guidance, no parameter constraints (enums, ranges), no idempotency hints for write operations. Tool names follow verb_noun pattern (good), but lack clarity on side effects and recovery paths.

• Document output schemas for all three tools. Example for view_buffers: {type: 'object', properties: {buffers: {type: 'array', items: {type: 'object', properties: {name, content, cursor_line, cursor_col, is_active}}}}}. This enables LLMs to extract buffer names and positions for chaining.
• Expand parameter descriptions with format and constraint hints. For send_normal_mode: 'keys: string, Neovim normal mode keystrokes (e.g., "gg", "dd", ":%s/old/new/g"). Max 1000 chars. Invalid sequences return error with suggestion.' For send_command_mode: 'command: string, Neovim ex command (e.g., ":w", ":set number", ":!ls"). Must start with colon. Returns command output or error message.'
• Add error handling guidance to write tools. Example: 'If Neovim is not running, returns error "Neovim connection lost. Reconnect and retry." Retryable: yes. If command syntax is invalid, returns error with Neovim's error message, user must fix syntax and retry.'
• Add idempotency hints to tool descriptions. send_normal_mode: 'Note: Some keystrokes (e.g., delete, insert) are not idempotent. Retrying may produce different results. Use view_buffers to verify state before retry.' send_command_mode: 'Most ex commands are idempotent (e.g., :set, :read). Destructive commands (e.g., :!rm) are not, verify before retry.'
• Consider adding optional parameters to view_buffers for filtering and pagination. Example: {buffer_name?: string, context_lines?: number (default 100, range 10-500)}. This enables agents to focus on specific buffers and reduce token overhead.