Mirage provides 13 tools with basic naming (vm_* prefix) and descriptions, but quality is inconsistent. All tools have input schemas with typed parameters and descriptions, meeting minimum requirements. However, descriptions are terse (avg ~40 chars, well below the 194-char baseline), lack context on when to use each tool, and omit error recovery guidance. No output schemas are documented. Parameter descriptions are minimal, e.g., 'VM name' for the 'name' param appears in 12 tools identically. No enum constraints, no pagination support, no idempotency hints. Error handling is absent from tool definitions. Security-sensitive tools (vm_delete, vm_exec) lack permission gates or confirmation patterns. Composition is reasonable (each tool does one thing), but tools like vm_run combine clone+exec+delete without clear atomicity guarantees.

• Expand all tool descriptions to 100 - 200 characters. Include: what the tool does, when to use it (vs similar tools), what it returns, and any prerequisites. E.g., 'vm_list: Returns all VM images and running VMs with their current status (booting, running, stopped). Call this first to discover available VMs before starting or cloning.'
• Document output schemas for all tools. Specify field names, types, and meanings. E.g., vm_list returns [{name: string, status: 'booting'|'running'|'stopped', pid?: number, started_at?: ISO8601}]. This enables LLMs to chain tools correctly.
• Add confirmation or dry-run support to destructive tools. vm_delete should accept a --confirm flag or return a confirmation token. Alternatively, document that agents must call vm_list first to verify the VM exists before deletion.
• Enhance parameter descriptions with constraints and examples. E.g., 'name: VM name (2-64 alphanumeric + hyphens, e.g., ubuntu-dev-01)' and 'timeout_seconds: Command timeout in seconds (1-3600, default 300)'. Use enums for boolean flags: 'restore: Restore from snapshot if available (true|false, default false)'.
• Add error recovery guidance to tool descriptions. E.g., 'vm_exec: If the command times out, increase timeout_seconds or check guest agent status with vm_logs. If the guest is unresponsive, call vm_stop then vm_start to reboot.'