uitree-local
Related Servers
Alternatives to uitree-local
No user-submitted related servers found.
Related Servers
- AlicenseNot gradedqualityBmaintenanceEnables controlling an Android device from an MCP client via ADB, including wireless debugging discovery, UI-tree inspection, and performing taps, swipes, typing, app actions, and shell commands without relying on screen coordinates.1 npmMIT
- AlicenseNot gradedqualityDmaintenanceEnables MCP-compatible agents to control an Android device over the network via ADB, providing tools for shell commands, screen capture, UI inspection, file operations, and input simulation.16 npmMIT
- AlicenseNot gradedqualityBmaintenanceEnables an AI agent to operate a spare Android phone through MCP: capture screenshots, inspect UI controls, tap/swipe, input Chinese text, launch apps, and optionally run rooted shell commands or transfer files. It also supports a live web console for remote viewing and control.18MIT
- AlicenseNot gradedqualityBmaintenanceEnables AI agents to control a physical Android device or Docker-hosted emulator over ADB by taking screenshots and performing taps, swipes, key presses, text input, shell commands, app launches, and device info queries. It runs as a local MCP stdio server alongside a web UI and REST API for remote access.1MIT
- FlicenseNot gradedqualityBmaintenanceEnables agents to interact with Android via text-based UI trees instead of screenshots, supporting taps, swipes, input, macro recording, and device control through an MCP server and CLI.-
- AlicenseCqualityBmaintenanceEnables AI agents to control Android phones, emulators, redroid containers, iOS devices, and cloud-hosted devices through a perceive-act-verify loop of screen reading, taps, gestures, typing, and app launching. Exposes 138 tools for driving screens, elements, and files over adb, Portal APIs, and ios-portal without running ARM-only code on the device.94MIT
TDQS
Scored across 30 tools
Several tools overlap: get_screen_state already includes element tree and phone state, making get_element_tree and get_phone_state potentially confusing; keyboard_key and press_global_action both handle back/home; tap vs tap_element and long_press vs long_press_element split the same action by target type. Descriptions clarify intended use, but an agent still faces multiple plausible choices.
Names are consistently snake_case and mostly follow verb_noun or noun_verb patterns (get_screen_state, launch_app, tap_element). Minor deviations exist: keyboard_clear and keyboard_key put the noun first, and bare verbs tap/swipe/ping lack a noun. Overall readable and predictable.
30 tools is high for a device-automation MCP and exceeds the typical 3-15 well-scoped range; several getters are redundant because get_screen_state already bundles element tree and phone state. This inflates surface area and increases selection cost.
The surface covers core device control well: screen inspection, taps/swipes, keyboard, global actions, apps, files, clipboard, overlay, and keep-awake. Minor gaps remain (e.g., pinch/zoom or multi-touch gestures, wait-for-idle), but agents can work around them with existing swipe/tap primitives.