Haiku Control MCP has basic tool definitions with names and descriptions, but significant quality gaps. All 7 tools have descriptions (10-80 chars, mostly short), and input schemas are present with parameter types. However, descriptions are sparse and lack LLM-optimization guidance. Parameter descriptions are minimal or absent. No output schemas documented. No error handling guidance. No tool annotations (readOnlyHint/destructiveHint). The server targets a niche OS (Haiku) with shell command execution and file I/O, high-risk operations that need stronger validation and error recovery patterns.

• Expand tool descriptions to 150-250 chars. Include: what the tool does, when to use it (vs. alternatives), what it returns, and any prerequisites. E.g., 'Run a shell command on Haiku and return stdout, stderr, and exit code. Use for one-off commands; for long-running tasks, use run_command_background. Returns structured output with exit code for error detection.'
• Document output schemas for all tools. Specify return types, field names, and structure. E.g., run_command returns {stdout: string, stderr: string, exit_code: number}. This enables LLMs to chain tools and extract required fields.
• Add tool annotations: mark run_command and write_file as destructiveHint=true; mark read_file, list_directory, get_job_status, get_system_info as readOnlyHint=true. This signals to agents which operations have side effects.
• Add error handling guidance to run_command and run_command_background. Document common failure modes (timeout, permission denied, command not found) and recovery steps. E.g., 'If exit_code is 127, command not found, check PATH or use absolute path.'
• Enhance parameter descriptions with format/constraint details. E.g., 'command: Shell command string (bash syntax, max 4096 chars). Use absolute paths for files. Avoid shell metacharacters unless escaped.' and 'path: Absolute file path (e.g., /boot/home/user/file.txt). Must exist for read_file; parent dir must exist for write_file.'