Two things stand out at this size. The UI layer is built for a model rather than a script — elements are found by text or resource-id, taps target what was found, and waits are conditional instead of timed, which is the difference between a reliable flow and a sleep-and-hope loop. And the comparison tools turn one-off readings into before-and-after evidence: state snapshots, performance and screenshot baselines, OTA fingerprints, thermal baselines. Large outputs come back as handles you fetch deliberately, which is what keeps a server this size usable in a conversation.
An Android control and diagnostics server with 204 tools across 45 modules. It uses ADB by default and switches to direct execution when it detects Termux on the device, covering everything from tapping a button to reading a modem's AT command responses.
- UI automation that reads the screen instead of guessing: adb_ui_dump parses the view tree, adb_ui_find matches on text, resource-id or content-description, adb_tap_element taps what it found, adb_wait_element and adb_wait_stable wait on a condition rather than a sleep, and adb_screencap_annotated returns a screenshot with numbered bounding boxes
- Input past a tap — drag, fling, long press, double tap, pinch, typed text, clipboard read and write, orientation control, and adb_batch_actions to send several in one call instead of several round trips
- App lifecycle: install and uninstall, list and inspect packages, clear data, grant and revoke runtime permissions, force-stop, start and restart, and resolve every activity, service and receiver a package registers
- Logs and crashes: logcat snapshots with tag and priority filters, a background watcher polled from a ring buffer, the crash buffer, ANR traces and tombstones, heap dumps, dumpsys and full bug reports
- A device filesystem you can work in — ls, cat, find, grep, stat, checksum, write, move, copy, chmod, chown, mkdir and rm, with pre-flight checks on pushes and on moves out of system paths
- Wireless: pair and connect over TCP, switch a USB device into TCP/IP mode, scan the local network for ADB devices and connect automatically, plus port forwards, reverse forwards and managed tunnels
- Testing structure: named sessions with numbered steps capturing a screenshot and logcat each, workflows defined as JSON and validated before they run, tests generated from the current screen or from a package's intent filters, and Firebase Test Lab runs with their results
- Comparison over time: device state snapshots compared and settings restored, performance baselines with regression checks, screenshot baselines with a visual diff, OTA fingerprints with firmware history, and thermal and battery-drain baselines
- Radio and hardware depth most tooling does not reach — baseband and RIL identification, cell identity, signal detail down to RSRP, RSRQ and SINR, neighbouring cells, carrier config, modem logs, AT command send and probe, and WiFi, Bluetooth, NFC and GNSS firmware identification
- Emulators and VMs: AVDs listed and launched, QEMU images managed and a guest booted and attached as an ADB device, with multi-device shell, install, compare and test across everything connected
- adb_result_list, adb_result_get and adb_result_drop hold large outputs as handles rather than pushing them all into the conversation
Published as deepadb and launched over stdio, or built from the repository and pointed at build/index.js. It shells out to ADB, so the Android platform-tools have to be installed and the device authorised for debugging — adb_health_check validates the toolchain before you start guessing. Individual areas need more: root for adb_root_shell, chown and tcpdump, scrcpy for mirroring, Gradle for builds, QEMU with KVM for the VM tools, and Firebase credentials for Test Lab. On an Android device running Termux it executes directly instead of over ADB. The project points at its SECURITY.md before any HTTP, WebSocket or GraphQL transport is exposed beyond loopback.
One command — npx -y deepadb