Three tools with minimal descriptions (10-20 chars each) and no visible input schemas in the source. Tool names lack action verbs (read_file, write_file are acceptable; run_command is vague). No parameter type definitions visible. No output schemas documented. No error handling guidance. Descriptions are too brief to guide LLM selection. This server falls well below production baseline (median ~50).

• Add explicit JSON Schema input definitions for all three tools. Include type, description, and constraints for each parameter. Example: {"path": {"type": "string", "description": "AmigaOS file path (e.g., SYS:file.txt). Must be absolute.", "pattern": "^[A-Z]+:.*"}}
• Expand tool descriptions to 100-200 characters. State WHAT the tool does, WHEN to use it, and what it returns. Example for read_file: 'Read and return the full contents of a file on the Amiga filesystem. Use this to inspect configuration files, logs, or source code. Returns the file content as a string; fails if the file does not exist or is not readable.'
• Add output schema documentation. Specify the structure of responses (e.g., read_file returns {"content": string, "size_bytes": number}; run_command returns {"stdout": string, "stderr": string, "exit_code": number}).
• For run_command, implement a confirmation pattern. Add a 'dry_run' parameter (boolean, default false) so agents can preview command output before execution. Document that this tool is irreversible and requires explicit user approval for destructive commands.
• Add error handling guidance. Document what errors are possible (file not found, permission denied, command timeout) and what the LLM should do next (e.g., 'If file not found, try list_directory() to see available files').