qa-mcp-server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| --fake | No | Use the scripted fake device instead of a real adb device. | false |
| --port | No | Port for the streamable HTTP transport, for example 8765. | |
| --config | Yes | Path to the qa-mcp.toml configuration file (set apk_dir, artifacts_dir, allowed_packages, and adb_path there). | |
| --dry-run | No | Plan state-changing commands without executing them. | false |
| --transport | No | Transport for the server: stdio or http; HTTP binds to loopback by default. | stdio |
| --allow-remote | No | Allow the HTTP transport to bind to non-loopback interfaces. | false |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
Android QA tools over adb. Typical exploratory loop: list_devices -> launch_app -> dump_ui (read the screen) -> tap / input_text / press_key -> dump_ui again -> logcat (level E, package) to catch crashes -> screenshot for evidence. Prefer tap with a selector (text, resource_id or content_desc taken from dump_ui) over raw coordinates. All inputs are validated; commands outside the allowlist are rejected.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_devicesA | List attached Android devices and emulators with their state. State is device, offline or unauthorized; only "device" accepts commands. |
| install_apkA | Install (or reinstall, keeping data) an APK from the allowed APK directory. |
| launch_appA | Start an installed app (launcher activity unless |
| screenshotA | Capture the screen as PNG image content, or save it and return the file path. |
| logcatA | Read the logcat buffer (non-blocking dump), size-capped. |
| dump_uiA | Dump the current screen's UI hierarchy (uiautomator) as a JSON tree: class, text, resource_id, content_desc, bounds [x1,y1,x2,y2] and flags (clickable, scrollable, ...). |
| tapA | Tap at (x, y), or on the element found by ONE selector (text, resource_id or content_desc), resolved through a fresh UI dump and tapped at its center. |
| input_textA | Type text into the focused field. Tap the field first; fails if nothing is focused. |
| press_keyB | Send one allowlisted key event. |
| run_test_suiteA | Run a pre-configured test suite by name (exported ANDROID_SERIAL = serial). Only suites declared in the server config can run; arguments cannot be changed. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 10 tools
Each tool targets a distinct Android QA action: UI inspection, imaging, device discovery, installation, launching, logging, interaction, and suite execution. The only mild overlap is dump_ui vs screenshot (both observe the screen) and tap/input_text/press_key (all input), but descriptions make the boundaries clear.
Most names are snake_case verb_noun (dump_ui, list_devices, install_apk, launch_app, run_test_suite), but several are bare nouns (screenshot, logcat, tap, input_text, press_key) where the verb is implicit. Still readable, but the pattern is not uniform.
Ten tools is well-scoped for an Android UI-testing control surface; each maps to a distinct step in a device/QA workflow with no filler tools.
Core interaction and observation are covered, but lifecycle coverage is gappy: no uninstall, no force-stop/clear-data, no swipe/scroll or long-press gesture, no wait_for_element, and no way to pull files or clear logcat. Agents doing real UI flows will hit dead ends on scrolling and element waiting.