Ermöglicht es AI-Agenten, Android-Geräte über ADB oder durch direkte Ausführung auf dem Gerät via Termux zu inspizieren, zu steuern, zu testen und zu diagnostizieren.
Auch bekannt als fullread/DeepADB
- Stars
- 23
- Tools
- 200
- Downloads, 30 Tage
- —
- Neueste Version
- 1.1.7
- Letzter Commit
- 15. Nov. 2026
- Lizenz
- Apache-2.0
Was ist DeepADB MCP?
DeepADB ist ein MCP server. Ermöglicht es AI-Agenten, Android-Geräte über ADB oder durch direkte Ausführung auf dem Gerät via Termux zu inspizieren, zu steuern, zu testen und zu diagnostizieren. Er stellt 200 Tools bereit, etwa adb_health_check, adb_runtime_audit, adb_devices.
Zusammenfassung generiert aus dem README des Projekts
Über DeepADB MCP server
DeepADB bietet eine umfassende Schnittstelle, damit AI-Agenten mit Android-Geräten interagieren können. Es fungiert als lokaler MCP server, der in zwei verschiedenen Modi betrieben werden kann. Im standardmäßigen ADB-Modus läuft der Server auf einem Host-Rechner und kommuniziert über USB oder WiFi mit einem angeschlossenen Gerät. Wenn es direkt auf einem Android-Gerät über Termux läuft, wechselt es automatisch in einen lokalen Ausführungsmodus unter Verwendung von sh oder su, um Serialisierungs-Overhead zu vermeiden.
Der Server stellt 209 Tools über 49 spezialisierte Module bereit, die alles von UI-Automatisierung und App-Management bis hin zu Hardware-Diagnose und Netzwerk-Capture abdecken. Entwickler können es nutzen, um Screen-States zu inspizieren, Packages zu verwalten oder tiefgehende System-Audits durchzuführen. Es unterstützt verschiedene Transportmethoden wie stdio, HTTP und WebSocket, wodurch es mit Standard-MCP-Clients oder lokalen LLM-Setups wie llama.cpp kompatibel ist.
Geschrieben aus dem README des Projekts. Jeder Use Case wurde gegen ein Zitat daraus geprüft.
So installierst du DeepADB MCP
Formate geprüft am 10. Nov. 2026Zu Cursor hinzufügenZu Goose hinzufügenDeepADB MCP in Claude Code installieren
$ claude mcp add deepadb -- npx -y deepadbDeepADB MCP in Cursor installieren
~/.cursor/mcp.json
{
"mcpServers": {
"deepadb": {
"command": "npx",
"args": [
"-y",
"deepadb"
]
}
}
}DeepADB MCP in VS Code installieren
.vscode/mcp.json
{
"servers": {
"deepadb": {
"type": "stdio",
"command": "npx",
"args": [
"-y",
"deepadb"
]
}
}
}DeepADB MCP in VS Code CLI installieren
$ code --add-mcp '{"name":"deepadb","type":"stdio","command":"npx","args":["-y","deepadb"]}'DeepADB MCP in Claude Desktop installieren
claude_desktop_config.json
{
"mcpServers": {
"deepadb": {
"command": "npx",
"args": [
"-y",
"deepadb"
]
}
}
}DeepADB MCP in Codex installieren
$ codex mcp add deepadb -- npx -y deepadbDeepADB MCP in Codex config.toml installieren
~/.codex/config.toml
[mcp_servers.deepadb] command = "npx" args = ["-y", "deepadb"]
DeepADB MCP in Gemini CLI installieren
$ gemini mcp add -s user deepadb npx -- -y deepadbDeepADB MCP in Gemini settings.json installieren
~/.gemini/settings.json
{
"mcpServers": {
"deepadb": {
"command": "npx",
"args": [
"-y",
"deepadb"
]
}
}
}DeepADB MCP tools 200
Erkannt aus dem READMEadb_health_checkadb_runtime_auditadb_devicesadb_device_infoadb_getpropadb_shelladb_root_shelladb_installadb_uninstalladb_list_packagesadb_package_infoadb_clear_data
| adb_health_check | — | |
| adb_runtime_audit | — | |
| adb_devices | — | |
| adb_device_info | — | |
| adb_getprop | — | |
| adb_shell | — | |
| adb_root_shell | — | |
| adb_install | — | |
| adb_uninstall | — | |
| adb_list_packages | — | |
| adb_package_info | — | |
| adb_clear_data | — |
Alle 200 Tools anzeigenWeniger Tools anzeigen
adb_grant_permissionadb_revoke_permissionadb_list_permissionsadb_force_stopadb_start_appadb_restart_appadb_resolve_intentsadb_sqlite_inspectadb_pushadb_pulladb_lsadb_catadb_file_writeadb_findadb_file_statadb_file_checksumadb_mkdiradb_rmadb_file_moveadb_file_copyadb_file_chmodadb_file_touchadb_file_fsinfoadb_file_chownadb_grepadb_file_replaceadb_logcatadb_logcat_clearadb_logcat_crashadb_logcat_startadb_logcat_polladb_logcat_stopadb_logcat_sessionsadb_dumpsysadb_telephonyadb_batteryadb_networkadb_topadb_perf_snapshotadb_bugreportadb_crash_logsadb_heap_dumpadb_app_route_contextadb_screencapadb_screencap_annotatedadb_current_activityadb_inputadb_start_activityadb_ui_dumpadb_ui_findadb_screen_stateadb_screenrecord_startadb_screenrecord_stopadb_airplane_modeadb_airplane_cycleadb_wifiadb_mobile_dataadb_locationadb_screenadb_settings_getadb_settings_putadb_rebootadb_pairadb_connectadb_disconnectadb_tcpipadb_forwardadb_reverseadb_forward_listadb_forward_removeadb_reverse_removeadb_tunnel_openadb_tunnel_listadb_tunnel_closeadb_avd_listadb_emulator_startadb_emulator_stopadb_qemu_setupadb_qemu_imagesadb_qemu_startadb_qemu_stopadb_qemu_statusadb_qemu_connectadb_qemu_disconnectadb_qemu_guest_shelladb_test_session_startadb_test_stepadb_test_session_endadb_multi_shelladb_multi_installadb_multi_compareadb_multi_testadb_wear_datalayer_preflightadb_input_dragadb_input_flingadb_input_long_pressadb_input_double_tapadb_input_textadb_open_urladb_orientationadb_clipboardadb_input_pinchadb_tap_elementadb_wait_elementadb_wait_stableadb_scroll_untiladb_screenshot_compressedadb_batch_actionsadb_screen_sizeadb_device_stateadb_notificationsadb_snapshot_captureadb_snapshot_compareadb_snapshot_restore_settingsadb_tcpdump_startadb_tcpdump_stopadb_network_connectionsadb_ci_wait_bootadb_ci_device_readyadb_ci_run_testsadb_baseband_infoadb_cell_identityadb_signal_detailadb_neighboring_cellsadb_carrier_configadb_modem_logsadb_a11y_auditadb_a11y_touch_targetsadb_a11y_treeadb_regression_baselineadb_regression_checkadb_regression_historyadb_farm_runadb_farm_resultsadb_farm_matrixadb_registry_searchadb_registry_installadb_registry_installedadb_plugin_listadb_plugin_infoadb_gradleadb_build_and_installadb_shannon_sessionadb_at_detectadb_at_sendadb_at_batchadb_at_probeadb_at_cross_validateadb_screenshot_baselineadb_screenshot_diffadb_screenshot_historyadb_workflow_runadb_workflow_validateadb_workflow_listadb_install_bundleadb_list_splitsadb_extract_apksadb_apex_listadb_mirror_startadb_mirror_stopadb_mirror_statusadb_test_gen_from_uiadb_test_gen_from_intentsadb_test_gen_saveadb_ota_fingerprintadb_ota_checkadb_ota_historyadb_ril_startadb_ril_polladb_ril_stopadb_profile_detectadb_profile_saveadb_profile_listadb_firmware_probeadb_firmware_diffadb_firmware_historyadb_wifi_firmwareadb_bluetooth_firmwareadb_nfc_firmwareadb_gps_firmwareadb_market_searchadb_market_installadb_market_exportadb_selinux_statusadb_selinux_denialsadb_permission_auditadb_thermal_snapshotadb_thermal_compare
| adb_grant_permission | — | |
| adb_revoke_permission | — | |
| adb_list_permissions | — | |
| adb_force_stop | — | |
| adb_start_app | — | |
| adb_restart_app | — | |
| adb_resolve_intents | — | |
| adb_sqlite_inspect | — | |
| adb_push | — | |
| adb_pull | — | |
| adb_ls | — | |
| adb_cat | — | |
| adb_file_write | — | |
| adb_find | — | |
| adb_file_stat | — | |
| adb_file_checksum | — | |
| adb_mkdir | — | |
| adb_rm | — | |
| adb_file_move | — | |
| adb_file_copy | — | |
| adb_file_chmod | — | |
| adb_file_touch | — | |
| adb_file_fsinfo | — | |
| adb_file_chown | — | |
| adb_grep | — | |
| adb_file_replace | — | |
| adb_logcat | — | |
| adb_logcat_clear | — | |
| adb_logcat_crash | — | |
| adb_logcat_start | — | |
| adb_logcat_poll | — | |
| adb_logcat_stop | — | |
| adb_logcat_sessions | — | |
| adb_dumpsys | — | |
| adb_telephony | — | |
| adb_battery | — | |
| adb_network | — | |
| adb_top | — | |
| adb_perf_snapshot | — | |
| adb_bugreport | — | |
| adb_crash_logs | — | |
| adb_heap_dump | — | |
| adb_app_route_context | — | |
| adb_screencap | — | |
| adb_screencap_annotated | — | |
| adb_current_activity | — | |
| adb_input | — | |
| adb_start_activity | — | |
| adb_ui_dump | — | |
| adb_ui_find | — | |
| adb_screen_state | — | |
| adb_screenrecord_start | — | |
| adb_screenrecord_stop | — | |
| adb_airplane_mode | — | |
| adb_airplane_cycle | — | |
| adb_wifi | — | |
| adb_mobile_data | — | |
| adb_location | — | |
| adb_screen | — | |
| adb_settings_get | — | |
| adb_settings_put | — | |
| adb_reboot | — | |
| adb_pair | — | |
| adb_connect | — | |
| adb_disconnect | — | |
| adb_tcpip | — | |
| adb_forward | — | |
| adb_reverse | — | |
| adb_forward_list | — | |
| adb_forward_remove | — | |
| adb_reverse_remove | — | |
| adb_tunnel_open | — | |
| adb_tunnel_list | — | |
| adb_tunnel_close | — | |
| adb_avd_list | — | |
| adb_emulator_start | — | |
| adb_emulator_stop | — | |
| adb_qemu_setup | — | |
| adb_qemu_images | — | |
| adb_qemu_start | — | |
| adb_qemu_stop | — | |
| adb_qemu_status | — | |
| adb_qemu_connect | — | |
| adb_qemu_disconnect | — | |
| adb_qemu_guest_shell | — | |
| adb_test_session_start | — | |
| adb_test_step | — | |
| adb_test_session_end | — | |
| adb_multi_shell | — | |
| adb_multi_install | — | |
| adb_multi_compare | — | |
| adb_multi_test | — | |
| adb_wear_datalayer_preflight | — | |
| adb_input_drag | — | |
| adb_input_fling | — | |
| adb_input_long_press | — | |
| adb_input_double_tap | — | |
| adb_input_text | — | |
| adb_open_url | — | |
| adb_orientation | — | |
| adb_clipboard | — | |
| adb_input_pinch | — | |
| adb_tap_element | — | |
| adb_wait_element | — | |
| adb_wait_stable | — | |
| adb_scroll_until | — | |
| adb_screenshot_compressed | — | |
| adb_batch_actions | — | |
| adb_screen_size | — | |
| adb_device_state | — | |
| adb_notifications | — | |
| adb_snapshot_capture | — | |
| adb_snapshot_compare | — | |
| adb_snapshot_restore_settings | — | |
| adb_tcpdump_start | — | |
| adb_tcpdump_stop | — | |
| adb_network_connections | — | |
| adb_ci_wait_boot | — | |
| adb_ci_device_ready | — | |
| adb_ci_run_tests | — | |
| adb_baseband_info | — | |
| adb_cell_identity | — | |
| adb_signal_detail | — | |
| adb_neighboring_cells | — | |
| adb_carrier_config | — | |
| adb_modem_logs | — | |
| adb_a11y_audit | — | |
| adb_a11y_touch_targets | — | |
| adb_a11y_tree | — | |
| adb_regression_baseline | — | |
| adb_regression_check | — | |
| adb_regression_history | — | |
| adb_farm_run | — | |
| adb_farm_results | — | |
| adb_farm_matrix | — | |
| adb_registry_search | — | |
| adb_registry_install | — | |
| adb_registry_installed | — | |
| adb_plugin_list | — | |
| adb_plugin_info | — | |
| adb_gradle | — | |
| adb_build_and_install | — | |
| adb_shannon_session | — | |
| adb_at_detect | — | |
| adb_at_send | — | |
| adb_at_batch | — | |
| adb_at_probe | — | |
| adb_at_cross_validate | — | |
| adb_screenshot_baseline | — | |
| adb_screenshot_diff | — | |
| adb_screenshot_history | — | |
| adb_workflow_run | — | |
| adb_workflow_validate | — | |
| adb_workflow_list | — | |
| adb_install_bundle | — | |
| adb_list_splits | — | |
| adb_extract_apks | — | |
| adb_apex_list | — | |
| adb_mirror_start | — | |
| adb_mirror_stop | — | |
| adb_mirror_status | — | |
| adb_test_gen_from_ui | — | |
| adb_test_gen_from_intents | — | |
| adb_test_gen_save | — | |
| adb_ota_fingerprint | — | |
| adb_ota_check | — | |
| adb_ota_history | — | |
| adb_ril_start | — | |
| adb_ril_poll | — | |
| adb_ril_stop | — | |
| adb_profile_detect | — | |
| adb_profile_save | — | |
| adb_profile_list | — | |
| adb_firmware_probe | — | |
| adb_firmware_diff | — | |
| adb_firmware_history | — | |
| adb_wifi_firmware | — | |
| adb_bluetooth_firmware | — | |
| adb_nfc_firmware | — | |
| adb_gps_firmware | — | |
| adb_market_search | — | |
| adb_market_install | — | |
| adb_market_export | — | |
| adb_selinux_status | — | |
| adb_selinux_denials | — | |
| adb_permission_audit | — | |
| adb_thermal_snapshot | — | |
| adb_thermal_compare | — |
Konfiguration
DA_HTTP_HOST
| Name | Beschreibung | Typ |
|---|---|---|
| DA_HTTP_HOST | — |
Automatisierte Checks
Geluften am 12. Nov. 2026Vollständiger Bericht →Unsere automatisierten Checks bestanden. Das ist kein Security-Audit: Lies den Code und gib dem Server nur den minimal notwendigen Zugriff. Wie die Checks funktionieren
- Source Repository verknüpft und erreichbarBestanden
- Open Source Lizenz (OSI)Bestanden
- Commit oder Release im letzten JahrBestanden
- Package-Name ähnelt keinem populären PackageBestanden
- Remote Endpoint nutzt HTTPSNicht geprüft
- Destruktive Tools sind markiertBestanden
- Keine versteckten Anweisungen an das ModellBestanden
- Keine kritischen Advisories im Paket oder seinen AbhängigkeitenBestanden
README
Auf GitHub ansehenDeepADB
MCP (Model Context Protocol) server for AI agents that need to inspect, control, test, and diagnose Android devices through ADB—or directly on-device through Termux.
209 tools, 5 resources, and 4 prompts across 49 modules—from UI automation and application management to logs, network capture, baseband, firmware, security, and hardware diagnostics.
Get started
DeepADB runs as a local MCP server. It uses ADB on a host computer and automatically switches to direct execution when running on Android (detected through /system/build.prop).
git clone https://github.com/fullread/DeepADB.git
cd DeepADB
npm ci
npm run build
npm start
Add build/index.js to your MCP client configuration, then begin with these workflows:
| Goal | Start with |
|---|---|
| Confirm the toolchain and connected device | adb_health_check, then adb_devices |
| Inspect the current Android UI | adb_screen_state, then adb_ui_dump |
| Diagnose a device or app | adb_device_info, adb_logcat, and adb_dumpsys |
For a guided local connection, see MCP Client Configuration. Read SECURITY.md before exposing HTTP, WebSocket, or GraphQL transports beyond loopback.
Using llama.cpp or another local model? See Local LLM clients for direct stdio, authenticated browser HTTP, and small tool profiles. WebSocket is not required.
Architecture
┌──────────────────────────────────────────────────┐
│ MCP Client │
│ (Any MCP-capable client) │
└──────────────────────┬───────────────────────────┘
│ stdio (JSON-RPC), HTTP (/mcp or /sse), or WebSocket
┌──────────────────────▼───────────────────────────┐
│ DeepADB Server │
│ │
│ ┌─────────────────────────────────────────────┐ │
│ │ Tool Modules (49) │ │
│ │ device │ shell │ packages │ files │ logs │ │
│ │ diagnostics │ ui │ build │ health │ │
│ │ wireless │ control │ logcat-watch │ │
│ │ forwarding │ screen-record │ emulator │ │
│ │ testing │ multi-device │ snapshot │ │
│ │ network-capture │ ci │ plugins │ baseband │ │
│ │ accessibility │ regression │ │
│ │ device-farm │ registry │ at-commands │ │
│ │ screenshot-diff │ workflow │ sensors │ │
│ │ split-apk │ mirroring │ test-gen │ │
│ │ ota-monitor │ ril-intercept │ │
│ │ device-profiles │ firmware-analysis │ │
│ │ workflow-market │ selinux-audit │ │
│ │ thermal-power │ network-discovery │ │
│ │ input-gestures │ wireless-firmware │ │
│ │ app-network │ database-inspector │ │
│ │ runtime-audit │ wear │ │
│ ├─────────────────────────────────────────────┤ │
│ │ Resources (5) │ Prompts (4) │ │
│ └───────────────────┬─────────────────────────┘ │
│ │ │
│ ┌───────────────────▼─────────────────────────┐ │
│ │ ToolContext (unified DI) │ │
│ │ server │ bridge │ deviceManager │ │
│ │ logger │ security │ config │ │
│ └───────────────────┬─────────────────────────┘ │
│ │ │
│ ┌───────────────────▼─────────────────────────┐ │
│ │ Middleware Layer │ │
│ │ OutputProcessor │ SecurityMiddleware │ │
│ │ InputSanitizer │ Logger (stderr-safe) │ │
│ └───────────────────┬─────────────────────────┘ │
│ │ │
│ ┌───────────────────▼─────────────────────────┐ │
│ │ Bridge Layer (auto-detect) │ │
│ │ │ │
│ │ ┌─────────────┐ ┌────────────────────┐ │ │
│ │ │ ADB Bridge │ OR │ Local Bridge │ │ │
│ │ │ (PC mode) │ │ (on-device mode) │ │ │
│ │ │ via adb.exe │ │ via sh/su direct │ │ │
│ │ └──────┬───────┘ └────────┬───────────┘ │ │
│ │ │ │ │ │
│ │ Retry │ Timeout │ Cache │ Serial routing │ │
│ └─────────┼─────────────────────┼─────────────┘ │
└────────────┼─────────────────────┼───────────────┘
│ │
┌───────▼───────┐ ┌───────▼───────┐
│ ADB Binary │ │ sh / su │
│ (USB/WiFi) │ │ (local) │
└───────┬───────┘ └───────┬───────┘
│ │
┌─────▼────────────────────▼─────┐
│ Android Device │
└────────────────────────────────┘
Dual-Mode Architecture
DeepADB operates in two modes, auto-detected at startup:
ADB Mode (default) — PC-side bridge
AI Agent (PC) ←→ MCP ←→ DeepADB (PC) ←→ ADB (USB) ←→ Android Device
Standard mode: DeepADB runs on a PC/Mac/Linux host and communicates with the device over USB via ADB. The complete 209-tool surface is registered through the ADB bridge with automatic retry on transient failures; environment-specific tools report their capability requirements when a host cannot run them.
On-Device Mode — direct local execution
AI Agent (Termux) ←→ MCP (stdio/HTTP) ←→ DeepADB (Termux) ←→ sh/su (local)
When DeepADB runs directly on the Android device (e.g., inside Termux), it auto-detects the environment and switches to LocalBridge. Commands execute directly via sh/su — no ADB server, no USB, no serialization overhead. The same 209-tool MCP surface is registered, with capability-aware guidance when an optional on-device binary such as sqlite3 is unavailable.
Current test profiles: npm test retains strict rooted Pixel 6a / Android 16
coverage. npm run test:emulator uses a disposable fixture app for portable
lifecycle/UI tests and verifies sensor readings against Android's actual inventory.
Pixel-only hardware checks have explicit skips in the emulator profile; unexpected
failures still fail its optional CI lane. See test setup and profile boundaries.
The release baselines below describe the published artifacts. See the
Unreleased changelog for subsequent changes and validation.
1.1.6 device validation (November 1, 2026): the released build's full on-device run passed 836 checks, 0 failed, 3 skipped (839 total) across all 24 suites on the rooted Pixel 6a / Android 16, using Termux Node 24.22.1 and SQLite 3.54.1. The three skips reuse the cached Alpine kernel, initrd and disk; the actual VM boot and shutdown checks passed. Coverage includes the 28 runtime-audit regressions, device SQLite, live Shannon AT/OK, client/plugin compatibility, POSIX security cases and PIN-based UI recovery. The production installation passed eight strict checks before and after promotion, plus eight real Chromium checks and six authenticated WebSocket/GraphQL checks. Following the final documentation audit and verified redeployment, 1.1.6 is the only DeepADB installation retained on the validation Pixel; older installations and rollback copies were removed at the operator's request. Real phone-to-watch validation remains deferred.
The earlier 1.1.6 host/ADB baseline on Windows/Node 24.22.2 passed 783 checks,
0 failed, 18 expected skips (801 total). After the oversized-header test was
split into a portable regression, Node 22.23.4 device-free coverage passed
351 checks, 0 failed, 17 expected skips (368 total). Host skips cover
device-only or POSIX behavior, unavailable tcpdump and Windows file-symlink
privileges; they are distinct from the on-device results above.
v1.1.5 final audit-fix verification (Windows host): the ten device-free suites passed 295 checks, zero failures, and 17 expected skips (312 total) under Node 22.23.4 with coverage. The new hardening suite separately passed 41 checks on Node 24.22.2, with one Windows file-symlink capability skip; 16 other skips in the full CI set require hardware. Eight real-browser CORS/reload checks passed. The Pixel passed eight disposable POSIX path/link/race checks and five focused hardware smoke checks; the latest snapshot code also completed a real schema read through the isolated worker. These initial checks preceded the separate on-device release validation described below.
Final hardening hardware regression (October 31, 2026): all 22 host/ADB suites passed on the Pixel 6a / Android 16 using Node 24.22.2: 728 passed, 0 failed, 18 expected skips (746 total). This includes 41 audit-hardening, 33 local-LLM, 36 SDK/client/plugin compatibility, 93 security and 46 UI checks, plus live SQLite and Shannon validation. The skips are five on-device-only QEMU checks, twelve Windows/POSIX/tcpdump checks and one Windows file-symlink capability case. That last case is additionally covered by the disposable Pixel POSIX probes above. The suite exited successfully, left no ADB forwards, and made no repository file changes. This validates the host build; on-device LocalBridge execution is verified separately during release preparation.
1.1.5 release validation: the production-only package initializes with 209 tools, five resources/templates and four prompts. The staged Pixel build, using Termux Node 24.22.1 and SQLite 3.54.1, passed real SQLite schema/query reads, write rejection, runtime/health checks and a live Shannon handshake. Eight real-browser checks also passed against that on-device process, including authenticated SSE/Streamable HTTP, denied Origins and repeated page reloads. Six optional WebSocket/GraphQL checks passed with their production packages installed. The verified build was promoted to the normal installation path; Android auto-detection and all eight strict device checks passed again there. At that release's validation, the 1.1.4 rollback copy also started on the new runtime. The final host hardware rerun passed 728 checks with zero failures and 18 skips; device-free Node 24 coverage passed 295 checks with zero failures and 17 skips. GitHub CI covers Node 22/24/26 builds and regressions, real-browser MCP compatibility, coverage and dependency auditing, with separate CodeQL analysis for application code and GitHub Actions.
Earlier unreleased host hardware validation (October 31, 2026, before the final seven-finding hardening pass): the expanded suite,
including SDK migration, browser reconnect, request-ID/cancellation, plugin
callback lifetime, and profile regressions, completed on Pixel 6a / Android 16
with 687 passed, 0 failed, and 17 expected skips (704 total). Live llama.cpp
checks separately exercised stdio, authenticated browser
Streamable HTTP, and legacy SSE with the inspect profile; see
LOCAL_LLMS.md for the tested model and
browser HTTP reload recovery and its limits. Phone-to-watch Wear validation is deferred.
v1.1.4 host hardware validation: the full Pixel 6a / Android 16 regression completed with 604 passed, 0 failed, and 17 expected environment-specific skips (621 total). This includes live AT/OK validation on /dev/umts_router, a guarded read-only SQLite schema snapshot with cleanup, the unified runtime audit, per-app route context, and the single-device Wear preflight. The skips are the five on-device-only QEMU checks plus twelve Windows-host or unavailable-tcpdump security checks.
v1.1.3 hardware baseline: validated on a Pixel 6a (Android 16, Termux + Magisk + QEMU 10.2.1) across a four-cell test matrix — host (ADB) and on-device (LocalBridge), each with and without a device PIN — with 0 failures in every cell. The v1.1.3 suite contained 577 tests in the host/ADB configuration and 613 on-device; the difference is the QEMU virtualization and Alpine VM-boot suites, which run only on-device:
- ADB mode, no PIN: 556 passed / 0 failed / 21 skipped (577 total). Skips: 5 QEMU (on-device only), 7 gracefulKill unit tests (require POSIX signals, skipped on the Windows host), 3 tcpdump sanitization (tcpdump is root-only and unreachable over a non-root ADB shell), 2 host-shell round-trips (require a POSIX /bin/sh), 4 screen-state (require DA_TEST_PIN).
- ADB mode, with PIN: 560 passed / 0 failed / 17 skipped (577 total). The 4 screen-state tests unlock and run.
- On-device mode, no PIN: 606 passed / 0 failed / 7 skipped (613 total). All QEMU tests run, including Alpine Linux VM boot with KVM acceleration, big.LITTLE CPU topology detection, guest ADB connectivity error handling, and clean VM shutdown; the tcpdump and gracefulKill suites also run here (root + POSIX). Skips: 3 QEMU setup steps that no-op when the Alpine kernel/initrd/disk are already cached, 4 screen-state (require PIN).
- On-device mode, with PIN: 610 passed / 0 failed / 3 skipped (613 total). Every test enabled by the environment runs; the 3 skips are the cached-VM setup steps.
Privilege escalation: In ADB mode, all shell commands run as uid=2000 (the shell user) which has system-level permissions. In Termux, commands run as a regular app user. LocalBridge automatically elevates privileged commands through su when root (Magisk) is available:
- Command allowlist: 16 system commands (
settings,dumpsys,am,input,screencap,screenrecord,uiautomator,app_process,getenforce,setenforce,cmd,pm,wm,svc,ip,ifconfig) are routed throughsu -cto match ADB-mode behavior. - Path-based elevation: Commands referencing
/sdcard,/storage, or/system/paths are elevated to bypass Android scoped storage restrictions. - Root detection: Cached after a single
su -c idprobe at first use. Graceful degradation when root is unavailable. - Screenshot lifecycle: Allocate, capture and remove private device scratch files under the same identity. LocalBridge uses root when available, while the pulled output remains owned by the Termux user. Registered VM targets use ADB on the guest.
- The elevation allowlist is frozen (
ReadonlySet+Object.freeze) — not configurable via environment variables or runtime API.
Auto-detection: Checks for /system/build.prop (present on all Android devices, never on hosts). Override with DA_LOCAL=true or DA_LOCAL=false.
On-device setup (Termux):
pkg install nodejs-lts git sqlite
git clone https://github.com/fullread/DeepADB.git
cd DeepADB
npm ci
npm run build
Choose the launch mode for your client. For stdio, configure the MCP client to
launch node with the absolute path to DeepADB/build/index.js; the client
starts the process itself. To run a loopback HTTP listener instead:
DA_HTTP_HOST=127.0.0.1 DA_HTTP_PORT=3000 npm start # /mcp and legacy /sse
This listener is accessible only on the device, not directly over Wi-Fi. For browser clients, configure a bearer token and an exact Origin allowlist; see Local LLM clients. For remote access, follow the token and TLS reverse-proxy or SSH-tunnel guidance in SECURITY.md.
Use a supported Node LTS release; Node 24 is validated for this release. The
sqlite package supplies the sqlite3 executable required by on-device database
inspection. Production installs that omit development dependencies must install
ws and/or graphql separately when those optional transports are enabled.
Before replacing an existing device installation, stage the built package, keep
a rollback copy, and verify its actual LocalBridge execution with the device's
runtime and binaries. Host/ADB tests alone do not validate that deployment.
MCP Client Configuration
Configure a local stdio MCP server with node as the command and the absolute
path to build/index.js as its argument. The client starts the server process.
For clients that use an mcpServers JSON configuration, the equivalent is:
{
"mcpServers": {
"deepadb": {
"command": "node",
"args": ["/path/to/DeepADB/build/index.js"]
}
}
}
Other clients may use a settings form, TOML, or a different JSON layout; enter
the same command and argument using that client's configuration format. Leave
DA_HTTP_PORT, DA_WS_PORT, and DA_GRAPHQL_PORT unset for this stdio setup.
See Local LLM clients for explicit environment settings and
authenticated browser connections.
Available Tools (209)
Start with the capability area that matches your task; the complete reference remains below.
Complete tool reference
Health (1 tool)
adb_health_check— Comprehensive toolchain validation: ADB binary, server, device connection, authorization, root access, and storage writability
Runtime Audit (1 tool)
adb_runtime_audit— Unified read-only readiness audit for transport, Android userspace, root, SELinux, storage, command capabilities, UI/network diagnostics, SQLite, modem nodes, and Wear prerequisites
The audit retains successful checks when an independent probe fails. Its report
labels readiness as available, unavailable (a confirmed negative result),
or inconclusive (failed, timed out, incomplete, or not safely checked).
Audit status: partial and the Probe issues section identify incomplete
checks while preserving useful device information and snapshots. A partial
report is returned normally; failure to resolve the requested device remains a
tool error. complete means the checks completed, not that every capability is
available. Modem node visibility does not verify an AT handshake, and Play
services presence does not verify phone/watch pairing. Use the dedicated
Shannon and Wear tools for those narrower checks.
SQLite readiness follows the inspector's execution mode: host ADB uses the
host's Node SQLite backend (Node 22.16+ with node:sqlite enabled), while
on-device LocalBridge uses device sqlite3. A phone's SQLite binary cannot
make a missing host backend available. Backend availability alone does not
verify access to a particular app database.
Device (3 tools)
adb_devices— List all connected devices with state, model, and product infoadb_device_info— Detailed device properties (model, OS, SDK, build, security patch, ABI)adb_getprop— Read a specific system property or dump all properties
Shell (2 tools)
adb_shell— Execute arbitrary shell commands with configurable timeout (security-checked)adb_root_shell— Execute commands as root via su (requires rooted device, security-checked)
Packages (12 tools)
adb_install— Install APK with replace/downgrade optionsadb_uninstall— Remove package with optional data retentionadb_list_packages— List packages filtered by name or type (all/system/third-party)adb_package_info— Detailed package info (version, permissions, paths)adb_clear_data— Clear all app data and cacheadb_grant_permission— Grant a runtime permission to a packageadb_revoke_permission— Revoke a runtime permission from a package (reset permission state for testing denial flows)adb_list_permissions— List all declared and granted permissions for a package, filterable by granted/deniedadb_force_stop— Force-stop an app immediatelyadb_start_app— Launch an app by package name (resolves launcher activity)adb_restart_app— Force-stop then re-launch in one call (configurable delay)adb_resolve_intents— Discover registered activities, services, and receivers with intent filters
Room & SQLite Inspection (1 tool)
adb_sqlite_inspect— Package-scoped listing, schema inspection and validated read-only SQL. Prefersrun-as, falls back to root, rejects linked directories/files and verifies opened descriptors. Queries a private snapshot (database + WAL ≤64 MiB) with bounded execution and output, then removes it. Host inspection needs Node 22.16+ and runs in an isolated process; on-device inspection uses a trustedsqlite3binary. Neither backend queries the live app path. Snapshots are not transactional backups; concurrent writes may require retrying with the app stopped.
Files (18 tools)
adb_push— Push local file to device (hard-blocked kernel paths, fs-type awareness, storage reporting)adb_pull— Pull file from device to local filesystemadb_ls— List device directory contents (simple or detailed)adb_cat— Read text file from device with optional line limitadb_file_write— Create or overwrite text files via heredoc (buffer limit warning, fs-aware, post-verify)adb_find— Search for files by name/pattern with depth control and result cappingadb_file_stat— File metadata: size, permissions, timestamps, ownership, SELinux contextadb_file_checksum— SHA-256/SHA-1/MD5 hash with size-based timeout estimationadb_mkdir— Create directories with parent creation (-p), hard-blocked kernel pathsadb_rm— Delete files/directories with depth-based recursive protection and symlink resolutionadb_file_move— Move/rename with source depth protection and post-verifyadb_file_copy— Copy with pre-flight size+space check and post-verify size matchadb_file_chmod— Change permissions (Zod-validated octal mode, depth-based recursive protection)adb_file_touch— Create empty files or update timestamps (explicit timestamp support)adb_file_fsinfo— Filesystem report: type, mount, capacity, capabilities, SELinux, limitationsadb_file_chown— Change ownership (root required, depth-based recursive protection)adb_grep— Search file contents with fixed-string default, recursive depth control, result cappingadb_file_replace— Find/replace text in files (sed-backed, proper escaping, backup option)
Logs — Snapshots (3 tools)
adb_logcat— Filtered logcat snapshot with tag, priority, grep, and buffer selectionadb_logcat_clear— Clear all logcat buffersadb_logcat_crash— Crash buffer log snapshot
DeepADB MCP Fragen
Wie füge ich DeepADB MCP zu Claude Code hinzu?
Führe claude mcp add deepadb -- npx -y deepadb in deinem Terminal aus. Füge --scope user hinzu, damit der Server in jedem Projekt verfügbar ist.
Wie füge ich DeepADB MCP zu Cursor hinzu?
Öffne ~/.cursor/mcp.json und füge den Server unter mcpServers hinzu, mit der Cursor-Config aus dem Installationsabschnitt oben.
Welche Tools bietet DeepADB MCP?
Er stellt 200 Tools bereit, darunter adb_health_check, adb_runtime_audit, adb_devices, adb_device_info, adb_getprop.
Wie läuft DeepADB auf Android?
Es kann direkt auf dem Gerät über Termux laufen, indem ein LocalBridge-Modus genutzt wird, der Befehle via sh/su ausführt.
Kann ich DeepADB mit lokalen LLMs nutzen?
Ja, es unterstützt lokale LLM-Clients über direktes stdio, authentifiziertes Browser-HTTP und kleine Tool-Profile.