Static source inference · medium confidence · evidence: structured output
No deprecated protocol patterns detected
Summary
This server provides 33 tools for Android device control via ADB and scrcpy. While all tools have explicit registrations with schemas and descriptions present, there are significant quality gaps that prevent a higher score. Tool naming follows verb_noun conventions (e.g., android.input.tap, android.app.start), which is good. However, descriptions are frequently under-detailed, parameter descriptions are minimal or missing context, output schemas are not documented, and error handling guidance is absent. The server exposes multiple high-risk operations (shell execution, file system modification) with minimal safeguards. Compared to production baselines (avg tool desc 194 chars, avg params 4), many tools here have descriptions in the 50-100 char range without actionable context. Schema definitions are present but lean, no explicit output documentation, no pagination guidance for list operations, no guidance on retryability or error recovery.
Missing output schema documentation: No tool explicitly documents what fields are returned or their types. LLMs cannot infer response structure, forcing them to guess field names for chaining or summarization.
No pagination or result limiting guidance: List operations (e.g., android.app.list, android.files.list, android.system.dumpUiHierarchy) do not document max result count, pagination support, or overflow behavior. Large results could exhaust context windows without explicit limits.
Dangerous operations lack confirmation or dry-run support: android.system.shell (arbitrary command execution), android.files.push (filesystem modification), android.wifi.connect (network changes), and android.screen.unlock (security bypass) carry high risk but offer no confirmation, dry-run, or rollback mechanism.
Recommendations
Document output schemas for all tools: For each tool, add a 'Returns' section specifying field names, types, and semantics. Examples: android.app.list should return {apps: [{name: string, package: string, version: string}], total: number}; android.files.list should return {files: [{name: string, size: number, type: 'file'|'dir', modified: ISO8601}], path: string, total: number}.
Add pagination support to list operations: Modify android.app.list, android.files.list, and android.system.dumpUiHierarchy to accept optional limit and offset parameters, and return a total_count field. Document max result limits (e.g., 50 per call).
Implement confirmation/dry-run for high-risk operations: Add optional confirm: boolean parameter to android.system.shell and android.files.push. When true, return a preview of what would execute without committing. For android.wifi.connect and android.screen.unlock, add a 'dry_run' response showing what changes would occur.
Enhance parameter descriptions with validation rules: For android.input.tap/swipe/pinch, add 'X and Y are screen pixel coordinates, 0 to device_width/device_height respectively. Coordinates are device-specific, call android.devices.info first for exact dimensions.' For android.input.keyevent, link to Android keycode reference or provide an enum of common codes (KEYCODE_BACK=4, KEYCODE_HOME=3, etc.). For android.input.scroll, clarify 'Positive hscroll moves right, negative moves left. Values are scroll units, typically 1-10.'
Add error recovery guidance: For android.app.start, document: 'Returns error if package not found (call android.app.list first to verify), lacks permissions, or device is locked (call android.screen.unlock first).' For android.network.tcpip, document: 'Requires device to support TCP/IP mode. On older Android versions, may fail, check ro.build.version.sdk first via android.devices.info.'
Score history
Overall score trend
↑ 17 points across a rubric change (v1 → v2)
57/100
Scored
Grade
Overall
Spec posture
Rubric
2026-09-22
D
57
2025-06-18+
v2
2026-03-09
F
40
-
v1
83/100
Returns the output of adb devices -l (parsed).
android.files.listread only50/100
List files in a directory on the device.
android.files.pullread only50/100
Pull a file from the device to local system.
android.files.pushwrite50/100
Push a local file to the device. WARNING: Can modify device filesystem. Ensure paths are correct.
android.input.dragDropwritesource verified72/100
Drag and drop gesture. Drags from start coordinates to end coordinates over a specified duration.
android.input.inputTextwrite50/100
Input text on the device.
android.input.keyeventwritesource verified68/100
Send a keycode event to the device.
android.input.longPresswritesource verified77/100
Long press at a specific coordinate.
android.input.pinchwritesource verified72/100
Pinch gesture (zoom in/out). Simulates a pinch using gesture control.
android.input.scrollwrite50/100
Scroll on the device screen.
android.input.swipewritesource verified80/100
Swipes from (x1,y1) to (x2,y2). Uses fast scrcpy control protocol when stream is active, otherwise falls back to adb shell input.
android.input.tapwritesource verified78/100
Taps at coordinates (x,y). Uses fast scrcpy control protocol (~5ms) when stream is active, otherwise falls back to adb shell input (~100-300ms).
Parameter descriptions are insufficient: Many parameters lack actionable guidance. Examples: android.input.keyevent has no list of valid keycodes; android.input.scroll lacks explanation of positive/negative scroll direction semantics; android.files.push and android.files.pull omit path format or encoding notes.
No error handling or recovery guidance: Tool descriptions do not indicate which errors are retryable, what causes common failures, or how to recover. Example: android.app.start lacks guidance on 'package not found' or permission errors; android.network.tcpip does not explain prerequisites or common failure modes.
No idempotency guarantees or side-effect warnings: Tools like android.screen.wake, android.screen.sleep, android.input.tap lack clarity on idempotency. Is calling wake twice safe? Agents may retry on transient failures, risking duplicate effects.
Minimal input validation hints: Tools do not specify acceptable ranges, formats, or enum values for parameters. Examples: android.input.tap/swipe lack coordinate bounds (is 0-2560 valid? device-specific?); android.input.pinch lacks guidance on distance units (pixels? percentage?); android.wifi.connect omits SSID encoding or special character handling.
No permission or scope declarations: The server does not indicate which tools require device-level permissions, user authorization, or adb authentication. Agents cannot reason about least-privilege configurations.
android.system.shell and android.files.push lack injection/sanitization notes: Both tools accept free-form user input (shell commands, file paths) without documented mitigation for injection attacks. Agents could pass malicious payloads inadvertently via prompt injection.
Gesture parameters lack coordinate system explanation: Tools like android.input.pinch, android.input.dragDrop, and android.input.swipe use (x, y) coordinates but do not clarify the coordinate system (absolute screen pixels? relative to app window? scaled to device resolution?).
Clarify idempotency and retry semantics: Add to tool descriptions: Tools like android.screen.wake, android.screen.sleep, and android.input.tap are idempotent (safe to call multiple times with same parameters). Tools like android.input.swipe and android.input.pinch have timing side effects (repeated calls may cause multiple gestures), do not retry automatically without user confirmation.
Document permission and scope requirements: Add a 'Requires' field to descriptions. Examples: 'Requires: adb shell access'; 'Requires: Android Settings permission for WiFi'; 'Requires: Device Developer Options enabled for shell execution.'
Add injection safety notes: For android.system.shell and android.files.push, add warnings: 'This tool executes arbitrary commands/paths. Sanitize user input to prevent shell injection (e.g., escape special characters, validate paths). Do not interpolate unsanitized user input into commands.' Provide examples of safe vs unsafe usage.
Specify coordinate system and units: For all gesture tools, document: 'Coordinates are device screen pixels in absolute positioning (0,0 = top-left). Device resolution varies, call android.devices.info → ro.display.resolution first. Duration is in milliseconds (e.g., 300ms for a standard swipe).'
Add discovery tool descriptions: Enhance android.devices.list and android.app.list descriptions to note: 'Call this first to enumerate available devices or packages, especially if using serial numbers or package names in subsequent calls.'
Return chaining-friendly responses: Ensure tools that return IDs/references include them for downstream calls. Example: android.app.list should return both package name (for android.app.start/stop) and version info; android.files.list should return full paths usable directly in android.files.pull.
Cap and document result limits: Add to tool descriptions: 'Returns up to 50 results (configurable). Use limit and offset parameters for pagination if more results needed.'
Enhance android.vision.startStream and android.vision.stopStream descriptions: Document the resource URI format (android://device/<serial>/frame/latest.jpg) and explain how clients subscribe to frame updates via resource notifications.