That is what makes an automation survive a layout change — clicking by resource id and waiting for an element to appear beats replaying tap positions from a recording. Pair `dump_hierarchy` with the toast capture when a step silently fails: the XML tells you what the screen actually contains, and the toast usually tells you why the app refused.
A Python MCP server that automates Android devices through uiautomator2 over ADB. Tools are grouped by job — device, apps, screen, input, inspection and a few advanced ones — and it runs either as a stdio server for AI clients or as an HTTP API.
- Device: `connect_device`, `get_device_info`, `get_device_status`, `check_adb_and_list_devices`
- Apps: `get_installed_apps`, `get_current_app`, `start_app`, `stop_app`, `stop_all_apps`, `clear_app_data`
- Screen: `screen_on`, `screen_off`, `unlock_screen`, `wait_for_screen_on`
- Input: `click` and `long_click` by text, resource id or description, plus `send_text`, `swipe`, `drag` and `press_key`
- Inspection: `get_element_info`, `wait_for_element`, `scroll_to`, `screenshot`, and `dump_hierarchy` for the whole screen as XML
- Advanced: `get_toast` to capture the last toast message, and `wait_activity` to block until a named activity appears
Python 3.13 or higher, Android Debug Bridge on your PATH, and a connected device with USB debugging enabled and uiautomator2 support. Install dependencies with uv. The server ships configured for HTTP on port 8080; for AI clients you switch the entry point to stdio transport before wiring it into Claude Desktop or VS Code.
