This server lets an AI agent inspect and control Android emulators or physical devices via ADB, enabling a Chrome DevTools-style UI automation workflow.
List connected devices (android_list_devices): Enumerate all ADB-connected emulators and physical devices, including offline and unauthorized ones.
Capture UI hierarchy (android_take_snapshot): Capture a compact semantic UI Automator tree to identify and target UI nodes by resource ID, text, content description, class, and state flags.
Take screenshots (android_take_screenshot): Capture the current Android display as a PNG image.
Inspect app state (android_get_app_state): Retrieve the foreground package/activity, process state, and display metadata.
Tap the screen (android_tap): Tap explicit screen coordinates or a safely revalidated node from the latest snapshot (verifying the node still occupies the same bounds before acting).
Type text (android_type_text): Type ADB-safe ASCII text into the focused UI field, with an option to clear existing content first.
Swipe gestures (android_swipe): Perform a swipe gesture between two screen coordinates with a configurable duration.
Press keys (android_press_key): Send Android key events by name (e.g., Back, Home, Enter, Delete, directional keys) or by numeric keycode.
Wait for UI state (android_wait_for): Poll the semantic UI hierarchy until a matching node exists, disappears, or reaches a specific state (enabled, checked, selected, focused).
Read app logs (android_get_logs): Retrieve bounded, filtered logcat output scoped to a specific application's current process IDs, with configurable log level and line limits.
Allows interaction with Android devices (emulators or physical devices) via ADB, enabling UI inspection, tapping, text input, swiping, key events, and log retrieval.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Android DevTools MCP take a snapshot of the current UI"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server that lets an agent inspect and operate an already-running Android emulator or physical device through ADB.
It provides a Chrome-DevTools-style workflow:
Capture a semantic UI snapshot or screenshot.
Identify a UI node.
Tap the revalidated node, type text, swipe, or press a key.
Inspect the resulting UI, foreground activity, and application logs.
The server talks to Android through ADB, not directly to QEMU. This keeps the same interface usable with Android Studio emulators, headless emulators, third-party QEMU frontends, and physical devices.
Node.js 20 or later
Android SDK Platform Tools with adb available on PATH, or ADB_PATH
set to the executable
A booted device visible in adb devices -l
USB debugging authorization accepted for physical devices
The server attaches to existing devices. It does not start AVDs, install APKs, or launch applications.
Related MCP server: Android MCP
npm install
npm run build
node dist/cli.jsThe process uses MCP stdio, so its standard output is reserved for protocol messages. Operational messages are written to standard error.
Example MCP client configuration for this checkout:
{
"mcpServers": {
"android-devtools": {
"command": "node",
"args": [
"<path-to-repo>/dist/cli.js"
],
"env": {
"ANDROID_SERIAL": "emulator-5554"
}
}
}
}ANDROID_SERIAL is optional when exactly one ready device is connected. Use
ADB_PATH when adb is not on PATH.
Tool | Purpose |
| List ready, offline, and unauthorized ADB devices |
| Return a compact semantic UI hierarchy |
| Return the current display as PNG |
| Inspect foreground activity, process, and display state |
| Tap coordinates or a revalidated snapshot node |
| Clear and type into the focused field |
| Perform a coordinate-based swipe |
| Send Android key events |
| Wait for a selector and semantic state |
| Return bounded logcat lines for an app's current PIDs |
Snapshot selectors use exact AND matching over resource ID, text, content description, class, and state flags. Node IDs are scoped to one snapshot. Before a node tap, the server captures a fresh hierarchy and verifies that the same semantic node still occupies the same bounds. It returns a stale or ambiguous-target error instead of tapping when that check fails.
npm run check
npm test
npm run buildThere is also an opt-in smoke test for a disposable emulator. It sends the Home key and reads the current launcher's logs:
$env:ANDROID_MCP_TEST_SERIAL = "emulator-5554"
npm run test:deviceUI Automator exposes the accessibility/semantic tree, not Android Studio's private Layout Inspector data.
Canvas-rendered interfaces, games, protected windows, and some WebViews may only be inspectable through screenshots and coordinates.
Compose elements need usable semantics to appear as distinct nodes.
Text entry intentionally accepts only ADB-safe ASCII: letters, numbers,
spaces, and .,_@+-/:=. Unicode input requires an optional device-side
input method or instrumentation component and is not part of this release.
Network tracing, CPU/memory profiling, frame timing, AVD lifecycle, and APK management are outside the current black-box scope.
Get the foreground package/activity, optional package process state, and display metadata.
| Name | Required | Description | Default |
|---|---|---|---|
| serial | No | ADB device serial. Required when multiple devices are connected. | |
| package | No | Android package name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds context by specifying what is retrieved (foreground package/activity, process state, display metadata), which aligns with the annotations and provides additional behavioral detail beyond the structured data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It efficiently communicates the tool's purpose and scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with 2 optional parameters and no output schema. The description adequately covers the return values (foreground package/activity, process state, display metadata), and the schema handles parameter documentation. No additional details are necessary for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds minor value by mentioning 'optional package process state,' which hints at the package parameter's purpose, but does not elaborate beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' and identifies the exact resources: 'foreground package/activity, optional package process state, and display metadata.' This clearly distinguishes the tool from siblings like android_get_logs or android_take_screenshot, which target different data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives, nor does it mention exclusions or prerequisites. The purpose implies usage for retrieving foreground app state, but no direct guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read bounded logcat output filtered to the requested or foreground application's current process IDs.
| Name | Required | Description | Default |
|---|---|---|---|
| level | No | ||
| serial | No | ADB device serial. Required when multiple devices are connected. | |
| package | No | ||
| maxLines | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds that output is 'bounded' and 'filtered to current process IDs,' which provides useful context beyond annotations but does not elaborate on rate limits or system impact. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 18 words, front-loading the key action and scope. Every word contributes, and there is no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, high-quality annotations, and lack of output schema, the description provides sufficient context for an agent to understand the tool's behavior and limitations (bounded, filtered). Slightly more detail on parameter defaults or output format would push it to a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low (25%), but the description clarifies that the 'package' parameter filters logs and that 'maxLines' imposes a bound. This adds meaning beyond the schema, though level and serial are not individually explained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Read'), resource ('logcat output'), and scope ('bounded, filtered to requested or foreground application's current process IDs'). It effectively distinguishes the tool from siblings like android_take_screenshot or android_tap, as none of those handle logs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when logs for a specific or foreground app are needed) but does not explicitly state when not to use it or provide alternatives. However, since no sibling tool performs a similar function, the guidance is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all ADB-connected emulators and physical devices, including offline and unauthorized targets.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as read-only, idempotent, and non-destructive. The description adds valuable behavioral context by specifying that it includes offline and unauthorized targets, which goes beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately states the action and scope, with no unnecessary words. It is well front-loaded and earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of an output schema, the description could hint at the return format (e.g., device attributes). However, the mention of 'offline and unauthorized targets' implies state information, making it fairly complete for a simple list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters and schema coverage is 100%, so no parameter information is needed. The baseline for 0 parameters is 4, and the description does not require additional parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'list', the resource 'ADB-connected emulators and physical devices', and specifies the scope 'including offline and unauthorized targets', which effectively differentiates it from sibling action-oriented tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool (listing devices), but does not explicitly state when not to use it or mention alternative tools. However, the sibling list contains only action tools, making the purpose distinct.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Press Back, Home, Enter, Delete, a directional key, a KEYCODE_* name, or a numeric Android keycode.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | ||
| serial | No | ADB device serial. Required when multiple devices are connected. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=true, but the description does not elaborate on potential side effects, such as navigating away from an app or deleting content. It relies entirely on the annotation without adding context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that efficiently conveys the tool's purpose and parameter options without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with 2 parameters and no output schema, the description is adequate but lacks details on error handling, behavior on invalid keys, and when serial is required (only context from schema).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning beyond the schema by listing acceptable values for the 'key' parameter (named keys, KEYCODE_*, numeric). This compensates for the 50% schema coverage, though the 'serial' parameter remains only described in schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool presses Android keys, listing specific examples like Back, Home, Enter, Delete, directional keys, KEYCODE_* names, or numeric keycodes, distinguishing it from screen interaction tools like tap and swipe.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides examples of keys but does not explicitly state when to use this tool versus alternatives (e.g., for text input use android_type_text), nor does it mention when not to use it or any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Perform a swipe gesture between two screen coordinates.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | ||
| from | Yes | ||
| serial | No | ADB device serial. Required when multiple devices are connected. | |
| durationMs | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true, but the description adds no further behavioral context (e.g., screen coordinate system, gesture speed, effect on UI state). The description provides no extra value beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with a single sentence front-loading the action. However, some brevity is lost due to missing details that could be included without verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, nested objects, no output schema), the description is incomplete. It fails to explain coordinate conventions, duration semantics, serial usage, or potential side effects beyond the annotation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 25% (only serial has a description). The description clarifies that 'from' and 'to' are screen coordinates, but does not explain durationMs (units, optionality) or the coordinate system origin. This adds some meaning but insufficiently compensates for the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (perform a swipe gesture) and the specific context (between two screen coordinates), distinguishing it from sibling tools like android_tap or android_press_key.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor any exclusions or prerequisites. The agent receives no help in choosing between swipe and other gesture tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Capture the current Android display as a PNG image.
| Name | Required | Description | Default |
|---|---|---|---|
| serial | No | ADB device serial. Required when multiple devices are connected. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, indicating a safe read operation. The description adds no extra behavioral details beyond the mere action, such as how the image is returned or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 10 words, concise and front-loaded. Every word earns its place with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description should clarify the return format (e.g., base64 data, file path). It only states the output is a PNG image but does not specify how the agent will receive it, leaving ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema already describes the serial parameter adequately. The description does not add any additional parameter semantics, so it meets the baseline but adds no extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Capture the current Android display as a PNG image,' specifying the action and output format. However, it does not differentiate from sibling tools like android_take_snapshot, which may serve a similar purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool vs. alternatives. It does not mention prerequisites, such as a connected device, or scenarios to avoid.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Capture a compact UI Automator hierarchy. Use its snapshot and node IDs for safe node-targeted taps.
| Name | Required | Description | Default |
|---|---|---|---|
| serial | No | ADB device serial. Required when multiple devices are connected. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds context about the output being a 'compact UI Automator hierarchy' with 'node IDs', but does not elaborate on behavioral traits like performance or limitations. This adds modest value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences that are front-loaded with the action and include a practical follow-up use case. Every word earns its place; no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should clarify the return format (e.g., XML string containing node IDs). It mentions 'snapshot and node IDs' but does not specify the data structure, leaving ambiguity for the agent. It covers the basic purpose and use case but lacks detail on the output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a well-described optional 'serial' parameter. The description does not add any additional meaning beyond the schema, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it captures a compact UI Automator hierarchy and specifies its use for safe node-targeted taps using snapshot and node IDs, effectively distinguishing it from siblings like android_take_screenshot (image capture) and android_tap (action).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for obtaining UI structure before tapping ('Use its snapshot and node IDs for safe node-targeted taps'), providing clear context. However, it does not explicitly state when not to use this tool or how it differs from alternatives like android_take_screenshot for visual inspection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tap either explicit screen coordinates or a node from the latest snapshot. Node taps are revalidated before acting.
| Name | Required | Description | Default |
|---|---|---|---|
| x | No | ||
| y | No | ||
| nodeId | No | ||
| serial | No | ADB device serial. Required when multiple devices are connected. | |
| snapshotId | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructive behavior; description adds revalidation check for node taps. However, lacks explanation of failure modes, coordinate bounds, or interaction with snapshots.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with two modes, second sentence adds key behavioral detail. No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema and 5 parameters with limited description; missing details on return values, error handling, and the role of snapshotId.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With only 20% schema coverage, description explains that x/y are coordinates and nodeId is from snapshot, adding semantic grouping. Does not cover serial parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool taps Android UI either by coordinates or node from snapshot, distinguishing two use cases. It is specific and matches the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs siblings (like android_press_key, android_swipe). Does not mention prerequisites or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Type ADB-safe ASCII text into the focused UI node. Optionally clear its existing content first.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | ||
| clear | No | ||
| serial | No | ADB device serial. Required when multiple devices are connected. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true. The description adds context about 'ADB-safe ASCII text' and optional clear, which are helpful beyond annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with main action, no wasted words. Extremely concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core functionality and optional clear. However, it omits guidance on the 'serial' parameter (needed for multiple devices) and does not mention return values or errors, which is acceptable given no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is low (33%), but the description explains the 'clear' parameter's purpose. While 'text' and 'serial' are not elaborated, the tool name and context sufficiently imply their roles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verb 'Type' and resource 'focused UI node', clearly distinguishing from siblings like android_tap and android_swipe. It concisely states the action and optional behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternatives are provided. While the purpose is clear, the description does not contrast with sibling tools like android_press_key for text input scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Poll the semantic UI until matching nodes exist, disappear, or have the requested state.
| Name | Required | Description | Default |
|---|---|---|---|
| state | Yes | ||
| serial | No | ADB device serial. Required when multiple devices are connected. | |
| selector | Yes | ||
| timeoutMs | No | ||
| pollIntervalMs | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, indicating a safe read-only operation. Description adds polling behavior details (until nodes exist, disappear, or have requested state). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One succinct sentence front-loads the core purpose. No extraneous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema and description omits return value (e.g., success indicator, timeout behavior). For a polling tool, this is a gap. Annotations cover safety but not completion semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 20% (only 'serial' has a description). Description does not explain parameters like 'selector', 'timeoutMs', or 'pollIntervalMs' beyond the indicator of polling. Nested 'selector' object lacks guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Poll' and resource 'semantic UI', clearly stating the action and scope. It distinguishes from sibling tools (e.g., android_tap, android_type_text) which perform direct actions rather than waiting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use or avoid this tool versus alternatives. The context of polling is implied but not elaborated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0android_get_app_stateandroid_get_logsandroid_list_devicesandroid_press_keyandroid_swipeandroid_take_screenshotandroid_take_snapshotandroid_tapandroid_type_textandroid_wait_forScored across 10 tools
Each tool has a clearly distinct purpose: device listing, app state, logs, input methods (tap, swipe, key, type), UI capture (screenshot, snapshot), and UI waiting. No overlaps.
All tools follow the consistent prefix 'android_' and use snake_case with verb_noun pattern (e.g., get_app_state, press_key, take_screenshot). Minor exception with 'wait_for' but still consistent pattern.
10 tools is well-scoped for Android UI automation, covering essential actions without being too many or too few.
Covers core UI interaction (tap, swipe, type, key press), device info, logging, screenshots, and UI hierarchy snapshots. Missing actions like long press or scroll, but these can be worked around.
Control real Android and iOS devices with LLM agents — tap, swipe, type, automate flows.
Drive real devices from your AI Coding tool. Embed a client SDK (Unity, Godot, Flutter, iOS/macOS, Android, React Native, Web) in your app, then capture screenshots, traverse the UI tree, inject taps and key events, and run automated test tasks on the physical device over a secure relay.
Drive real Android & iOS devices and web browsers from natural language for mobile + web QA. 290+ tools across device control, app management, automation sessions, browser automation, and flow recording / replay. Bearer-auth — get a token at robotactions.com → Profile → API Tokens.
Melaya is a remote MCP server. It gives an assistant hands on your own Android phone and browser: it reads the screen through the accessibility tree, then taps, types and navigates inside the apps and sites you allow-list, with no per-app API. It also builds, schedules and runs agent pipelines across 6k+ connected tools. OAuth 2.1, nothing to install.
