GBOX is an Android device management and testing tool exposing 20 CLI-based tools via HTTP. While tool names are action-oriented and schemas are present, critical gaps severely limit LLM usability: (1) Parameter descriptions are minimal or absent, most tools lack clear guidance on what values are valid or what side effects occur. (2) Output schemas are completely undocumented, LLMs cannot know what fields to expect, blocking downstream tool composition and planning. (3) Descriptions are often generic ('Connect to an Android device') without explaining WHEN to use the tool vs. similar alternatives (connect_device vs. connect_device_with_id). (4) No error recovery guidance, failures offer no hints for retry or correction. (5) Critical composition issues: connect_device returns nothing visible, but get_device_info requires the same serial, unclear if that serial is the output or must be retained from previous context. (6) Device metadata (serial, deviceId, osType) is scattered across tools with inconsistent naming (serial vs. serialKey vs. deviceId), forcing LLMs to track multiple identifier types. This is a functional tool suite but poorly optimized for agent interaction.

• Document output schemas for all tools. For get_device_info, list_bridges, get_bridge, get_device_reconnect_state: specify the exact JSON structure returned, including all field names, types, and what they represent.
• Enhance parameter descriptions with constraints and prerequisites. E.g., 'serial: Device serial number (format: alphanumeric, 10-20 chars). Obtain via list_devices() or device settings. Required for all device operations.'
• Clarify the distinction between connect_device and connect_device_with_id. Choose one canonical tool or explicitly document when to use each. If both exist, document which parameters trigger different code paths and what each returns.
• For update_device_info, replace the generic 'device' object parameter with explicit fields (device_id, device_type, os_type, etc.) with type and constraint information.
• Add error handling documentation: for each tool, document common failure modes (e.g., 'device not found', 'port already in use') and recovery paths. E.g., 'If device not found, call list_bridges() to verify device is registered, then retry with the correct serial.'
• Implement idempotent operation hints. Mark tools as safe-to-retry (e.g., is_device_connected, get_device_info) vs. destructive (e.g., disconnect_device, remove_bridge) so LLMs know when retries are safe.
• Add WHEN guidance to tool descriptions. E.g., 'Call this before connecting to verify the device is currently registered and online.'
• Resolve identifier naming: pick one canonical identifier per resource (serial for devices, bridge_id for bridges) and use it consistently. Document how to obtain IDs from human-readable names (e.g., 'search by partial serial').