Agent Droid Bridge is a FastMCP server that gives AI agents programmatic control over Android devices and emulators via ADB. It exposes the following capabilities:
Screen Interaction: Tap and swipe at pixel coordinates, type text into focused input fields, and send key events (Back, Home, Enter, Delete, etc.)
UI Inspection: Capture screenshots as base64 PNG images or retrieve the full XML UI hierarchy to locate elements, read text, and find resource IDs
Efficient UI Monitoring: Take lightweight UI snapshots and poll for screen changes using a snapshot token, avoiding unnecessary full hierarchy transfers
App & Device Control: Launch apps by package/activity component name and list all connected devices with their serial numbers, state, and model names
Arbitrary ADB Commands: Execute any ADB or ADB shell command, safely parsed via shlex to prevent shell injection
Multi-Device Handling: Auto-detects a single connected device or requires explicit serial specification when multiple devices are present
Provides programmatic control over Android devices and emulators, enabling AI agents to interact with screens via taps and swipes, inspect UI hierarchies, capture screenshots, and execute ADB commands.
Agent Droid Bridge is an MCP server that connects AI agents to Android devices and emulators over ADB. It is built for mobile automation, app testing, dynamic analysis, and reverse engineering: exposing the full surface of ADB as structured tools that any MCP-compatible AI client can call directly. If ADB can do it, an agent can do it.
Purpose-built tools return structured, minimal responses. No raw XML dumps, no wasted context — agents stay fast across long sessions.
The demo above runs through a few straightforward tasks to show what a connected agent can do, and this is just scratching the surface:
Installs the Paint app, opens it, and draws a house by calculating pixel coordinates for the walls and roof
Opens the device browser, searches for "MCP Wikipedia", navigates to the result page, and takes a screenshot
Opens the Calculator, computes 1337 × 42, and extracts the result to the host machine
Opens Contacts, creates a new entry with a name and phone number, and confirms it saved
Opens the Calendar and schedules an appointment for a specific date
Opens Settings and toggles dark mode
Extracts the Calculator APK from the device to the host machine
Installs Notepad, writes a one-sentence summary of every task completed, and takes a final screenshot
Related MCP server: scrcpy-mcp
Tools
14 built-in tools for screen capture, UI inspection, text reading, element extraction, touch and swipe input, text entry, keycode events, app launching, ADB commands, and device inspection
app_manager pack adds 9 tools for package management, app lifecycle, APK extraction, permissions, and intent injection. Load it with ADB_EXTRA_TOOL_PACKS=app_manager
Tool availability is reflected in the server's startup instructions. Agents receive an accurate catalog at connect time
Device handling
Auto-detects a single connected device; prompts for selection when multiple devices are present
Runs over stdio, compatible with any MCP-capable AI client
Structured responses instead of raw XML dumps, keeping agent context lean across long automation runs
Security
Two execution modes: unrestricted (full ADB access, optional denylist) and restricted (allowlist-only, blocks everything not explicitly permitted)
Set ADB_ALLOW_SHELL=false to disable all shell commands regardless of mode
Hide specific tools from the agent with ADB_DENIED_TOOLS
All commands parsed via shlex. No shell injection possible
Observability
Optional session recorder logs every tool call, ADB command, and security event to structured JSONL files. Enable with MCP_LOG_ENABLED=true and MCP_LOG_DIR
Mobile QA and test automation Automate UI flows across real devices and emulators without modifying the app or writing test code. Tap, swipe, type, read screen content, take screenshots — all from a natural language prompt.
App security research Extract APKs, inspect declared permissions, fire arbitrary intents, and observe runtime behavior on screen. No instrumentation, no jailbreak required.
Dynamic analysis Launch apps in controlled states, drive UI interactions, capture screen state at each step, and pull artifacts — all scriptable through an AI agent.
Development and debugging Install builds, verify UI states, check app info, and run ADB commands without leaving your coding environment.
uvx agent-droid-bridgeNo cloning or virtual environments needed. Requires Python 3.11+ and ADB installed on your host.
uvx is provided by uv. If you don't have it: curl -LsSf https://astral.sh/uv/install.sh | sh
To install from source instead, see docs/setup.md — Option B.
To verify the install: uvx agent-droid-bridge --help
Install ADB — see docs/setup.md for platform-specific instructions
Connect an Android device or start an emulator
Add the server to your MCP client config:
{
"mcpServers": {
"agent-droid-bridge": {
"command": "uvx",
"args": ["agent-droid-bridge"],
"env": {
"ADB_EXECUTION_MODE": "unrestricted",
"ADB_ALLOW_SHELL": "true",
"ADB_PATH": "adb",
"ADB_EXTRA_TOOL_PACKS": "",
"MCP_LOG_ENABLED": "false",
"MCP_LOG_DIR": "~/logs/agent-droid-bridge"
}
}
}
}To enable session logging, set MCP_LOG_ENABLED to "true" and update MCP_LOG_DIR to a writable path on your machine.
Variable | Default | Description |
|
| Security mode. |
|
| Set to |
|
| Path to the ADB binary. Replace with a full path if |
| (empty) | Comma-separated list of extra tool packs to load. Set to |
|
| Set to |
| (none) | Directory where session logs are written. Required when |
Prompt your agent to use the agent-droid-bridge MCP tools
Full setup guide and environment variable reference: docs/setup.md
Tool | What it does |
| Returns the current screen as an XML UI hierarchy |
| Captures the screen as a base64-encoded PNG |
| Sends a tap gesture at pixel coordinates |
| Sends a swipe gesture between two points over a given duration |
| Types text into the focused input field |
| Sends an Android keycode event (Back, Home, Enter, etc.) |
| Launches an app by its |
| Runs an arbitrary ADB or ADB shell command |
| Lists all Android devices currently visible to ADB with their serial, state, and model |
| Takes a lightweight UI snapshot and returns a token for use with |
| Polls for a UI change after an action; accepts a snapshot token as baseline; returns hierarchy only when requested |
| Parses the UI hierarchy and returns structured elements with coordinates and interaction properties; supports |
| Returns all visible text on screen sorted top-to-bottom, as plain text |
| Returns structured device information — identity, security posture, and hardware specs — in a single call; supports |
Optional packs extend the core toolset. Enable them by setting ADB_EXTRA_TOOL_PACKS in your MCP client config. See docs/extra-tool-packs.md.
app_manager
Package management, app lifecycle control, APK extraction, permission management, and intent injection.
Tool | What it does |
| Lists installed packages with optional filtering, search, and detail levels |
| Returns full static metadata for a single installed app |
| Installs an APK from a host path onto the device |
| Removes an installed app by package name |
| Extracts the installed APK from the device to the host |
| Grants, revokes, checks, or lists runtime permissions for an app |
| Launches an app by package name, auto-resolving the launcher activity |
| Controls app runtime state — stop, clear data, clear cache, enable, disable |
| Fires an intent at a component via |
Full parameter reference: docs/tools.md
Configure the server entirely from your MCP client's env block. No files to edit. The env block in the Quick Start above covers the most common settings. For the full reference including security filtering, tool visibility, and timeouts, see docs/configuration.md.
To use a YAML config file instead, set ADB_CONFIG_SOURCE=yaml. See docs/configuration.md for details.
Session recording is separate. Enable it with MCP_LOG_ENABLED=true and MCP_LOG_DIR. Full reference: docs/logging.md.
File | Description |
Prerequisites, installation, and MCP client configuration | |
Full parameter reference for all tools | |
Reference for environment variables and | |
Session recorder — log files, levels, retention, and activation | |
Extra tool packs — enabling packs, the pack contract, and writing your own | |
Common setup issues and ADB problems | |
Common multi-tool workflows with examples | |
Release history and version changes |
Contributions are welcome. See CONTRIBUTING.md for guidelines on setup, code standards, and submitting pull requests.
To report a security vulnerability, follow the process in SECURITY.md — do not open a public issue.
Polls the UI hierarchy after an action and returns when the screen content changes or the timeout is reached. Returns changed status and elapsed time. By default, omits the XML hierarchy for efficiency — set return_hierarchy=True to receive the full hierarchy.
For efficient change detection: call snapshot_ui before the action, perform the action, then call detect_ui_change with baseline_token. Only use without baseline_token when you need to wait for a slow transition (loading screens, animations). Do not use to read the current screen state — use get_ui_hierarchy for that.
| Name | Required | Description | Default |
|---|---|---|---|
| timeout_seconds | No | Maximum seconds to poll for a UI change. | |
| baseline_token | No | Token returned by snapshot_ui, captured before the action. When provided, compares current UI against that snapshot — use this for reliable change detection without loading XML into context. When omitted, captures a fresh baseline at call time. | |
| return_hierarchy | No | When False (default), returns only changed and elapsed_seconds — no XML. Set to True to include the full UI hierarchy in the response. Only set True when you need to read element data immediately after the change. | |
| device_serial | No | Android device serial (e.g. 'emulator-5554' or '192.168.1.10:5555'). Omit only when a single device is connected. If the tool returns a multi-device error: STOP. Present the device list to the user verbatim and wait for their explicit choice. Do NOT retry with a guessed or inferred serial — this is a hard requirement. Once the user provides a serial, use it for every subsequent call in this session. To switch devices mid-session, ask the user first. |
| Name | Required | Description |
|---|---|---|
| changed | Yes | |
| hierarchy | No | |
| elapsed_seconds | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure and does so effectively. It explains polling behavior, timeout handling, efficiency considerations (omitting XML by default), and the need for device serial management in multi-device scenarios. It doesn't cover rate limits or authentication needs, but provides substantial operational context beyond basic functionality.
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 perfectly structured and concise. Every sentence earns its place: first sentence states core functionality, second explains efficiency trade-off, third provides usage pattern, fourth specifies alternative use case, and fifth gives exclusion rule. No wasted words, front-loaded with the most important information.
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 (polling, change detection, device management) and the presence of an output schema (which handles return values), the description is complete. It covers purpose, usage patterns, efficiency considerations, device management requirements, and distinctions from sibling tools, providing all necessary context for an agent to use this tool correctly.
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 100% schema description coverage, the baseline is 3. The description adds some context about parameter usage (e.g., explaining when to use baseline_token vs not, and efficiency implications of return_hierarchy), but doesn't provide significant semantic value beyond what's already documented in the comprehensive schema descriptions.
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's purpose with specific verbs ('polls', 'returns when the screen content changes') and resources ('UI hierarchy'), distinguishing it from siblings like get_ui_hierarchy (for reading current state) and snapshot_ui (for capturing baselines). It explicitly defines what the tool does: monitoring UI changes after an action with timeout handling.
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 explicit guidance on when to use this tool vs alternatives. It specifies: use with baseline_token for efficient change detection after snapshot_ui, use without baseline_token only for slow transitions, and do not use for reading current screen state (use get_ui_hierarchy instead). This covers both proper usage scenarios and clear exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The output of an ADB command. Parsed safely via shlex and never passed to a system shell.
| Name | Required | Description | Default |
|---|---|---|---|
| command | Yes | ADB command to execute. Parsed safely — no shell injection possible. | |
| use_shell | No | When True, runs as an Android shell command (adb shell ...). When False, runs as a top-level ADB command (adb devices, adb install, etc.). | |
| device_serial | No | Android device serial (e.g. 'emulator-5554' or '192.168.1.10:5555'). Omit only when a single device is connected. If the tool returns a multi-device error: STOP. Present the device list to the user verbatim and wait for their explicit choice. Do NOT retry with a guessed or inferred serial — this is a hard requirement. Once the user provides a serial, use it for every subsequent call in this session. To switch devices mid-session, ask the user first. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses safety traits (parsed safely via shlex, no shell injection) and implies execution behavior, but doesn't cover rate limits, auth needs, or error handling beyond device serial instructions in the schema. It adds useful context beyond the schema.
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, efficient sentence with zero waste, front-loaded with the core purpose. It's appropriately sized and structured without unnecessary elaboration.
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 3 parameters, 100% schema coverage, and an output schema (implied by 'Has output schema: true'), the description is reasonably complete. It covers safety aspects but could benefit from more context on tool scope versus siblings. The output schema likely handles return values, reducing the need for description details.
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 schema already documents all parameters thoroughly. The description doesn't add meaning beyond what the schema provides, such as explaining parameter interactions or usage examples. Baseline 3 is appropriate when schema does the heavy lifting.
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 states the tool executes an ADB command and mentions safe parsing via shlex, but it's vague about what ADB commands are (Android Debug Bridge) and doesn't clearly distinguish from siblings like press_key or type_text which are specific ADB operations. It doesn't specify the verb+resource combination explicitly.
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 versus sibling tools like press_key or type_text, which are specific ADB operations. The description lacks explicit when/when-not instructions or alternatives, leaving usage context unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the current Android screen as an XML UI hierarchy.
Use this when you need to locate element coordinates, read text, or find resource IDs to interact with. Do not call this after every action — only call it when you actually need to read screen content. To check if the screen changed after an action, use snapshot_ui before the action and detect_ui_change after.
| Name | Required | Description | Default |
|---|---|---|---|
| device_serial | No | Android device serial (e.g. 'emulator-5554' or '192.168.1.10:5555'). Omit only when a single device is connected. If the tool returns a multi-device error: STOP. Present the device list to the user verbatim and wait for their explicit choice. Do NOT retry with a guessed or inferred serial — this is a hard requirement. Once the user provides a serial, use it for every subsequent call in this session. To switch devices mid-session, ask the user first. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well by explaining key behavioral aspects: it returns XML format, should be used sparingly for performance reasons, and has a specific use case pattern with sibling tools. It doesn't mention error handling or performance characteristics beyond usage frequency.
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?
Perfectly structured with three focused sentences: purpose statement, usage guidance, and alternative approach. Every sentence adds value with zero redundancy or fluff. The most important information (what it returns) comes first.
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?
Complete for a read-only tool with good annotations (though none provided) and output schema. The description covers purpose, usage patterns, performance considerations, and relationships with sibling tools. With output schema handling return values, no additional information is needed.
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 schema already fully documents the single parameter. The description adds no parameter-specific information beyond what's in the schema, meeting the baseline expectation for high schema 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 tool's purpose with specific verb ('Returns') and resource ('current Android screen as an XML UI hierarchy'). It distinguishes from siblings by focusing on XML hierarchy extraction rather than screenshots, change detection, or direct interaction.
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?
Explicit guidance is provided: 'Use this when you need to locate element coordinates, read text, or find resource IDs to interact with.' It also specifies when NOT to use it ('Do not call this after every action') and names an alternative approach ('use snapshot_ui before the action and detect_ui_change after').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
An Android app launched by its component name (package/activity).
| Name | Required | Description | Default |
|---|---|---|---|
| component | Yes | Android component in 'package/activity' format, e.g. 'com.android.settings/.Settings'. | |
| device_serial | No | Android device serial (e.g. 'emulator-5554' or '192.168.1.10:5555'). Omit only when a single device is connected. If the tool returns a multi-device error: STOP. Present the device list to the user verbatim and wait for their explicit choice. Do NOT retry with a guessed or inferred serial — this is a hard requirement. Once the user provides a serial, use it for every subsequent call in this session. To switch devices mid-session, ask the user first. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes the tool's behavior regarding device selection, error handling, and session persistence for the 'device_serial' parameter, though it doesn't cover aspects like permissions, side effects, or rate limits.
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 highly concise and front-loaded, stating the core purpose in a single sentence. The detailed usage guidelines are efficiently integrated into the parameter descriptions in the schema, avoiding redundancy and maintaining clarity.
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 (device management, error handling) and the presence of an output schema (which reduces need to describe return values), the description is mostly complete. It covers key behavioral aspects but lacks details on permissions, side effects, or Android-specific constraints.
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 schema already documents both parameters thoroughly. The description adds minimal semantic context beyond the schema, such as implying the tool's focus on Android apps, but doesn't provide additional parameter insights beyond what's in the structured data.
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's purpose as launching an Android app using a component name, specifying the format. It distinguishes itself from siblings like 'press_key' or 'tap_screen' by focusing on app launching, though it doesn't explicitly contrast with all siblings.
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 includes explicit usage guidance by specifying when to omit the 'device_serial' parameter ('only when a single device is connected') and provides detailed error-handling instructions for multi-device scenarios, including a hard requirement to stop and present options to the user.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
All Android devices currently visible to ADB, with their serial numbers, connection state, and model names.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It describes what the tool returns (device list with specific attributes) but doesn't disclose behavioral traits like whether this requires ADB setup, if it's a real-time snapshot, error handling, or performance characteristics. It adds basic context but lacks operational details.
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, well-structured sentence that efficiently conveys the tool's purpose, scope, and output. Every word earns its place with no redundancy or wasted information.
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 (0 parameters, no annotations, but has an output schema), the description is reasonably complete. It explains what the tool does and what data it returns. With an output schema present, the description doesn't need to detail return values, but could benefit from more behavioral context.
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 0 parameters with 100% schema description coverage. The description doesn't need to explain parameters, and it appropriately focuses on the tool's function. A baseline of 4 is applied for zero-parameter tools, as there's nothing to compensate for.
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's purpose with specific verb+resource: 'list' (verb) 'Android devices' (resource). It distinguishes from siblings by specifying 'currently visible to ADB' and listing the data returned (serial numbers, connection state, model names), which is distinct from UI interaction or command execution 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 implies usage context: when you need to see all connected Android devices via ADB. It doesn't explicitly state when NOT to use it or name alternatives, but the context is clear enough for an agent to infer this is for device discovery rather than interaction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A key event sent to the Android device using the given keycode integer.
| Name | Required | Description | Default |
|---|---|---|---|
| keycode | Yes | Android keycode integer. Common: BACK=4, HOME=3, ENTER=66, RECENTS=187, TAB=61, DEL=67. | |
| device_serial | No | Android device serial (e.g. 'emulator-5554' or '192.168.1.10:5555'). Omit only when a single device is connected. If the tool returns a multi-device error: STOP. Present the device list to the user verbatim and wait for their explicit choice. Do NOT retry with a guessed or inferred serial — this is a hard requirement. Once the user provides a serial, use it for every subsequent call in this session. To switch devices mid-session, ask the user first. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the tool's behavior as sending a key event, implying an action on the device. The input schema adds critical behavioral context, such as error handling for multi-device scenarios and session persistence, which compensates well for the lack of 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, efficient sentence that directly states the tool's purpose without waste. It is front-loaded and appropriately sized, earning its place by clearly conveying the core functionality.
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 (device interaction), no annotations, and an output schema (which handles return values), the description combined with the detailed input schema provides complete context. The schema covers all parameters, usage rules, and error scenarios, making it fully adequate.
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 schema fully documents parameters. The description adds no additional meaning beyond implying keycode usage, but the schema provides examples and constraints. Baseline 3 is appropriate as the schema handles parameter semantics effectively.
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 ('sent to the Android device') and resource ('key event'), specifying it uses a keycode integer. However, it doesn't differentiate from siblings like 'tap_screen' or 'type_text' beyond the general 'key event' concept, making it clear but not sibling-distinctive.
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 explicitly states when to use this tool ('sent to the Android device using the given keycode integer'), and the input schema provides detailed guidance on device_serial usage, including when to omit it, error handling, and session management. This offers clear context and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Takes a lightweight snapshot of the current UI state and returns a short token.
Use this before performing an action (tap, swipe, launch, key press) when you only need to confirm the screen changed afterward — not read its content. Pass the returned token to detect_ui_change as baseline_token. This avoids loading the full XML hierarchy into context unnecessarily. Do not use this when you need to read or interact with screen elements — use get_ui_hierarchy for that.
| Name | Required | Description | Default |
|---|---|---|---|
| device_serial | No | Android device serial (e.g. 'emulator-5554' or '192.168.1.10:5555'). Omit only when a single device is connected. If the tool returns a multi-device error: STOP. Present the device list to the user verbatim and wait for their explicit choice. Do NOT retry with a guessed or inferred serial — this is a hard requirement. Once the user provides a serial, use it for every subsequent call in this session. To switch devices mid-session, ask the user first. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes the tool's behavior: it returns a short token rather than full UI content, explains how the token should be used with detect_ui_change, and clarifies that this avoids loading the full XML hierarchy. It doesn't mention performance characteristics, error conditions, or authentication needs, but provides substantial operational 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?
The description is efficiently structured with four sentences that each serve a distinct purpose: stating the core function, explaining when to use it, describing the token's purpose, and providing exclusion criteria. There's no wasted text, and key information appears early.
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 moderate complexity, 100% schema coverage, and the presence of an output schema (which handles return values), the description provides excellent contextual completeness. It explains the tool's purpose, usage guidelines, behavioral characteristics, and relationship to sibling tools without needing to repeat schema information.
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 schema already fully documents the single parameter (device_serial). The description doesn't add any parameter-specific information beyond what's in the schema. This meets the baseline expectation when schema coverage is complete.
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's purpose with specific verbs ('takes a lightweight snapshot of the current UI state') and distinguishes it from sibling tools ('not read its content', 'use get_ui_hierarchy for that'). It explicitly contrasts with get_ui_hierarchy for reading/interacting with screen elements.
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 explicit guidance on when to use this tool ('before performing an action... when you only need to confirm the screen changed') and when not to use it ('Do not use this when you need to read or interact with screen elements'). It names the alternative tool (get_ui_hierarchy) and explains the purpose of the returned token for detect_ui_change.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A swipe gesture on the Android screen from (x1,y1) to (x2,y2) over the given duration.
| Name | Required | Description | Default |
|---|---|---|---|
| x1 | Yes | Start X coordinate | |
| y1 | Yes | Start Y coordinate | |
| x2 | Yes | End X coordinate | |
| y2 | Yes | End Y coordinate | |
| duration_ms | No | Swipe duration in milliseconds | |
| device_serial | No | Android device serial (e.g. 'emulator-5554' or '192.168.1.10:5555'). Omit only when a single device is connected. If the tool returns a multi-device error: STOP. Present the device list to the user verbatim and wait for their explicit choice. Do NOT retry with a guessed or inferred serial — this is a hard requirement. Once the user provides a serial, use it for every subsequent call in this session. To switch devices mid-session, ask the user first. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It mentions the action but doesn't disclose critical traits like whether this requires device interaction permissions, if it's synchronous/asynchronous, error handling for invalid coordinates, or side effects on the UI state.
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, efficient sentence with zero wasted words. It front-loads the core action and directly lists the key parameters without unnecessary elaboration, making it easy to parse quickly.
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 tool with 6 parameters, 100% schema coverage, and an output schema, the description is minimally adequate. However, as a device interaction tool with no annotations, it lacks context about prerequisites, error conditions, and behavioral expectations that would help an agent use it correctly in practice.
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%, providing detailed parameter documentation. The description adds minimal value beyond the schema, only implying that parameters define a swipe gesture from start to end points over time, which is already evident from parameter names and schema descriptions.
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 ('swipe gesture') and target ('Android screen'), specifying coordinates and duration. It distinguishes from siblings like tap_screen or press_key by describing a swipe motion, but doesn't explicitly differentiate from similar gesture tools that might exist.
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 about when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., device connectivity), appropriate contexts, or comparisons to other interaction tools like tap_screen or execute_adb_command.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A PNG screenshot of the current Android device screen with width, height, and base64-encoded image data.
| Name | Required | Description | Default |
|---|---|---|---|
| device_serial | No | Android device serial (e.g. 'emulator-5554' or '192.168.1.10:5555'). Omit only when a single device is connected. If the tool returns a multi-device error: STOP. Present the device list to the user verbatim and wait for their explicit choice. Do NOT retry with a guessed or inferred serial — this is a hard requirement. Once the user provides a serial, use it for every subsequent call in this session. To switch devices mid-session, ask the user first. |
| Name | Required | Description |
|---|---|---|
| image | Yes | |
| width | Yes | |
| format | Yes | |
| height | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It describes the output format but fails to mention critical behavioral aspects such as whether this operation requires specific device states, if it's read-only or has side effects, potential performance impacts, or error handling. The description is purely output-focused without operational 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?
The description is a single, efficient sentence that directly states the tool's output without unnecessary words. It's appropriately sized and front-loaded with the core functionality.
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 that there's an output schema (which presumably describes the return structure), the description doesn't need to explain return values. However, for a tool with no annotations and potential device interaction complexity, the description is minimal—it covers the output but lacks context about when and how to use it effectively with sibling tools.
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 schema fully documents the single parameter. The description adds no parameter information beyond what's in the schema, maintaining the baseline score of 3 since the schema handles all parameter documentation.
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 what the tool does ('A PNG screenshot of the current Android device screen') with specific details about the output format (PNG, width, height, base64-encoded image data). It distinguishes from siblings like 'snapshot_ui' by focusing on raw screen capture rather than UI analysis, though the distinction could be more explicit.
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 versus alternatives like 'snapshot_ui' or 'detect_ui_change'. The input schema includes detailed instructions about device selection, but the description itself lacks explicit usage context or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A tap gesture at the given pixel coordinates on the Android screen.
| Name | Required | Description | Default |
|---|---|---|---|
| x | Yes | X coordinate in screen pixels | |
| y | Yes | Y coordinate in screen pixels | |
| device_serial | No | Android device serial (e.g. 'emulator-5554' or '192.168.1.10:5555'). Omit only when a single device is connected. If the tool returns a multi-device error: STOP. Present the device list to the user verbatim and wait for their explicit choice. Do NOT retry with a guessed or inferred serial — this is a hard requirement. Once the user provides a serial, use it for every subsequent call in this session. To switch devices mid-session, ask the user first. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the basic action. It doesn't disclose behavioral traits like whether this requires device accessibility services, what happens on invalid coordinates, if it waits for UI response, or potential side effects. The schema's device_serial description adds some behavioral context about multi-device handling.
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?
Single sentence with zero waste - every word contributes to understanding the tool's function. Front-loaded with the core action, appropriately sized for a simple gesture tool.
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 3-parameter tool with no annotations but 100% schema coverage and an output schema, the description is minimally adequate. It covers the basic action but lacks context about Android-specific requirements, error conditions, or interaction patterns with sibling tools. The schema compensates for parameter documentation, but behavioral context is sparse.
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 parameters are fully documented in the schema. The description adds no additional parameter semantics beyond implying coordinate-based interaction. Baseline 3 is appropriate when the schema does the heavy lifting, though the description could have explained coordinate system orientation or tap duration.
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 specific action ('tap gesture') and target resource ('Android screen'), with precise scope ('at the given pixel coordinates'). It distinguishes from siblings like swipe_screen (continuous gesture) or press_key (keyboard input), providing unambiguous 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 implies usage context (Android device interaction) but doesn't explicitly state when to use this versus alternatives like detect_ui_change or get_ui_hierarchy. However, the input schema's device_serial parameter description provides strong operational guidance about device selection and error handling, which compensates partially.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Text input into the currently focused Android input field.
Spaces are encoded automatically.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Text to type into the focused input field. | |
| device_serial | No | Android device serial (e.g. 'emulator-5554' or '192.168.1.10:5555'). Omit only when a single device is connected. If the tool returns a multi-device error: STOP. Present the device list to the user verbatim and wait for their explicit choice. Do NOT retry with a guessed or inferred serial — this is a hard requirement. Once the user provides a serial, use it for every subsequent call in this session. To switch devices mid-session, ask the user first. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and adds valuable behavioral context: it specifies that spaces are encoded automatically (a key implementation detail) and the input schema provides extensive device_serial handling instructions. However, it doesn't mention error conditions beyond the multi-device case or performance characteristics.
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 with zero waste - the first states core functionality, the second adds crucial behavioral detail about space encoding. Every word earns its place and the information is front-loaded appropriately.
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 moderate complexity, 100% schema coverage, and presence of an output schema, the description provides complete context. It covers the core functionality, adds behavioral details, and the schema handles parameter documentation thoroughly. No significant gaps remain for agent understanding.
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 100% schema description coverage, the baseline is 3. The description adds context about the 'text' parameter's purpose ('into the focused input field') and the schema provides rich semantics for device_serial including multi-device error handling. This exceeds baseline but doesn't fully explain all parameter interactions.
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 specific action ('Text input') and target ('currently focused Android input field'), distinguishing it from siblings like tap_screen or press_key. It precisely defines the verb+resource combination without ambiguity.
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 context (when an Android input field is focused) but doesn't explicitly state when to use alternatives like press_key for special keys or tap_screen for navigation. It provides clear operational context but lacks explicit comparison with sibling tools.
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. Dates show when Glama detected each change.
v0.1.1detect_ui_changeexecute_adb_commandget_ui_hierarchylaunch_applist_devicespress_keysnapshot_uiswipe_screentake_screenshottap_screentype_textEach tool has a clearly distinct purpose with no overlap: detect_ui_change monitors for changes, get_ui_hierarchy reads screen content, snapshot_ui captures state tokens, and actions like tap_screen, swipe_screen, type_text, press_key, launch_app, take_screenshot, list_devices, and execute_adb_command each handle specific interactions. Descriptions explicitly differentiate usage scenarios, preventing misselection.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., detect_ui_change, get_ui_hierarchy, tap_screen). This uniformity makes the set predictable and easy to understand, with no deviations in style or convention.
With 11 tools, this server is well-scoped for Android device automation, covering essential actions like UI interaction, navigation, input, and device management. Each tool serves a clear role without redundancy, making the count appropriate for the domain.
The toolset provides complete coverage for Android automation: UI reading (get_ui_hierarchy), change detection (detect_ui_change, snapshot_ui), interactions (tap_screen, swipe_screen, type_text, press_key), app control (launch_app), device management (list_devices, execute_adb_command), and visual feedback (take_screenshot). No obvious gaps exist for core workflows.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Control real Android and iOS devices with LLM agents — tap, swipe, type, automate flows.
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.
Human-input bridge for AI agents with voice-first answer links, MCP tools, and HTTP APIs.
MCP server for building and testing AI agents with multi-model experimentation and insights.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Neverlow512/agent-droid-bridge'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
