The ADB MCP Server is a tool that provides a bridge between AI models and Android devices via ADB using MCP. With this server, you can:
Device Management: List and interact with connected Android devices
App Installation: Deploy APK files to devices
Logging: Access and filter device logs through logcat
File Transfer: Push files to devices and pull files from devices, with base64 encoding options
UI Interaction: Capture screenshots and analyze UI hierarchy in XML format
Shell Command Execution: Run custom commands on devices
Configuration: Customize ADB paths and server settings for flexibility
Provides tools for interacting with Android devices via ADB, including device management, app installation, logging, file transfer, UI interaction, and shell command execution.
Serves as the runtime environment for the ADB MCP server, allowing communication between AI models and Android devices.
Enables execution of custom shell commands on Android devices for advanced device control and automation.
Used as the implementation language for the ADB MCP server, providing typed interfaces for Android device interactions.
Allows retrieval and analysis of Android UI hierarchy in XML format to understand and interact with device interfaces.
Click on "Install 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., "@ADB MCP Server take a screenshot of my connected device"
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.
Quite surprised that this repo reached 50 stars (!) the ecosystem is quite generous sometimes, thank you for starring it!
I've been working on something that is faster, more scalable and also works with iOS, take a look at mobile-device-mcp.
And leave some ⭐ too :)
An MCP (Model Context Protocol) server for interacting with Android devices through ADB. This TypeScript-based tool provides a bridge between AI models and Android device functionality.
Related MCP server: Ultimate Android MCP
📱 Device Management - List and interact with connected Android devices
📦 App Installation - Deploy APK files to connected devices
📋 Logging - Access device logs through logcat
🔄 File Transfer - Push and pull files between device and host
📸 UI Interaction - Capture screenshots and analyze UI hierarchy
🔧 Shell Command Execution - Run custom commands on the device
Node.js (v16 or higher recommended, tested with Node.js v16, v18, and v20)
ADB (Android Debug Bridge) installed and in your PATH
An Android device or emulator connected via USB or network with USB debugging enabled
Permission to access the device (accepted debugging authorization on device)
To install ADB Android Device Server for Claude Desktop automatically via Smithery:
npx -y @smithery/cli install @srmorete/adb-mcp --client claude# Clone the repository
git clone https://github.com/srmorete/adb-mcp.git
cd adb-mcp
# Install dependencies
npm install
# Build the TypeScript code
npm run build
# Run the server
npx adb-mcpThe server uses default ADB paths. For custom ADB location:
export ADB_PATH=/path/to/adb
npx adb-mcpAdd the ADB MCP server configuration:
{
"mcpServers": {
"adb": {
"command": "npx",
"args": [
"adb-mcp"
]
}
}
}IMPORTANT: The server must be running before using any ADB tools.
Start the server using:
npx adb-mcpYou should see:
[INFO] ADB MCP Server connected and readyKeep this terminal window open while using the ADB tools.
All tools are available with the following naming convention:
adb_devices - List connected devices
adb_shell - Execute shell commands on a device
adb_install - Install an APK file using a local file path
adb_package_manager - Execute Package Manager (pm) commands - list packages, grant/revoke permissions, manage apps
adb_activity_manager - Execute Activity Manager (am) commands - start activities, broadcast intents, control app behavior
adb_logcat - View device logs with optional filtering
adb_pull - Pull files from a device
adb_push - Push files to a device
dump_image - Take a screenshot of the current screen
inspect_ui - Get UI hierarchy in XML format (most useful for AI interaction)
If tools aren't working:
Server Issues:
Ensure the server is running (npx adb-mcp)
Check server output for error messages
Try detailed logs: LOG_LEVEL=3 npx adb-mcp
Kill hanging processes:
ps aux | grep "adb-mcp" | grep -v grep
then kill -9 [PID]
Device Connection:
Verify connection with adb_devices
If "unauthorized", accept debugging authorization on device
Check USB/network connections
Try restarting ADB: adb kill-server && adb start-server
ADB Issues:
Verify ADB installation: adb version
Device Setup:
Use an emulator (it was built using one), for real devices maybe try this:
Ensure USB debugging is enabled
For newer Android versions, enable "USB debugging (Security settings)"
Try different USB port or cable
or let me know in an issue
Android 8.0 and higher
MCP clients including Claude in Cursor IDE
Was built on macOS but should run on any POSIX compatible (Linux etc).
Did not try on Windows but maybe it works.
Contributions are welcome! Submit a Pull Request.
For major changes, open an issue to discuss first.
You can, of course, also fork it
Note: this project was vibe-coded so if you spot some weird stuff... well now you know 🙂
This project is licensed under the MIT License - see the LICENSE file for details.
Built with Model Context Protocol (MCP)
Executes Activity Manager (am) commands on a connected Android device. Supports starting activities, broadcasting intents, force-stopping packages, and other 'am' subcommands. Specify the subcommand (e.g. 'start', 'broadcast', 'force-stop') and arguments as you would in adb shell am. Example: amCommand='start', amArgs='-a android.intent.action.VIEW -d http://www.example.com'
| Name | Required | Description | Default |
|---|---|---|---|
| amCommand | Yes | Activity Manager subcommand, e.g. 'start', 'broadcast', 'force-stop', etc. | |
| amArgs | No | Arguments for the am subcommand, e.g. '-a android.intent.action.VIEW' | |
| device | No | Specific device ID (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description carries full burden. It mentions it executes commands on a connected device, implying connectivity requirement and potential side effects (e.g., force-stopping packages). However, it does not detail error scenarios, prerequisites, or specific behavioral traits like idempotency.
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 short sentences plus an example. Every part is useful: explains purpose, lists supported actions, and gives concrete example. No 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?
For a simple tool with 3 parameters and no output schema, the description covers the main use case, connectivity requirement, and example. Lacks details on return values or error handling, but overall sufficient.
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 descriptions for all three parameters. The description adds value by explaining the concept of subcommands and providing an example usage, enriching understanding beyond the schema's basic definitions.
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 execution of Activity Manager commands on Android device, lists supported subcommands like start, broadcast, force-stop, and gives an example. Distinguishes from sibling ADB tools which handle different operations.
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 explains what the tool does but does not explicitly state when to use it versus alternatives like adb_shell or adb_package_manager. It implies usage for am commands but lacks explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists all connected Android devices and emulators with their status and details. Use this tool to identify available devices for interaction, verify device connections, and obtain device identifiers needed for other ADB commands. Returns a table of device IDs with connection states (device, offline, unauthorized, etc.). Useful before running any device-specific commands to ensure the target device is connected.
| Name | Required | Description | Default |
|---|---|---|---|
| random_string | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that it returns a table of device IDs with connection states and that it is useful for verification. No side effects implied.
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?
Description is slightly verbose (three sentences) but each sentence adds value. Could be shortened slightly without losing 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?
Adequately explains return type and usage context. However, missing explanation of the optional parameter and no output schema details. Good for a simple list operation.
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?
Input schema has an undocumented optional 'random_string' parameter. Description does not explain this parameter, leaving ambiguity. With 0% schema coverage, description should clarify if it expects arguments.
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?
Clearly states it lists connected Android devices and emulators with status and details. Distinguishes from sibling tools like adb_install or adb_shell which are device-specific actions.
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?
Explicitly says to use before device-specific commands to verify connections and obtain identifiers. Provides clear context but does not mention when not to use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Installs an Android application (APK) on a connected device or emulator. Use this for deploying applications, testing new builds, or updating existing apps. Provide the local path to the APK file for installation. Automatically handles the installation process, including replacing existing versions. Specify a device ID when working with multiple connected devices.
| Name | Required | Description | Default |
|---|---|---|---|
| apkPath | Yes | Local path to the APK file | |
| device | No | Specific device ID (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that it automatically replaces existing versions, but does not mention potential side effects like app data handling, required device authorization, or failure scenarios. With no annotations, the description carries the burden but only partially addresses it.
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?
Three concise sentences: first defines core action, second lists use cases, third provides parameter guidance. No unnecessary words, front-loaded.
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?
Covers the tool's purpose, parameters, and typical use cases. Lacks details on return value (e.g., success/error messages) and prerequisites (e.g., device must be connected), but these are not demanded by the lack of output schema. Adequate for a simple 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?
Schema coverage is 100%, baseline 3. The description adds value by explaining the device parameter is optional but useful for multiple connected devices, which is not inferred from the schema alone.
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 installs APKs on connected devices/emulators, with specific use cases (deploying, testing, updating), and is distinct from sibling tools like adb_pull or adb_push.
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?
Explicitly lists use cases (deploying, testing, updating) and mentions device ID when multiple devices are connected. However, it does not state when not to use it or suggest alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieves Android system and application logs from a connected device. Ideal for debugging app behavior, monitoring system events, and identifying errors. Supports filtering by log tags or expressions to narrow down relevant information. Results can be limited to a specific number of lines, making it useful for both brief checks and detailed analysis. Use when troubleshooting crashes, unexpected behavior, or performance issues.
| Name | Required | Description | Default |
|---|---|---|---|
| filter | No | Logcat filter expression (optional) | |
| device | No | Specific device ID (optional) | |
| lines | No | Number of lines to return (default: 50) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must disclose behavioral traits. It implies a read-only operation ('retrieves') but does not discuss potential side effects (e.g., buffer clearing), permissions, or output stream behavior.
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?
Three sentences, each with distinct value: purpose, use cases, and parameter explanation. No wasted words, front-loaded with core function.
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 no output schema, the description covers purpose, use cases, and key parameters. Could mention continuous log nature or device qualification, but generally complete.
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 descriptions, so baseline 3. The description adds context: 'filter by log tags or expressions' clarifies the filter parameter's semantics, improving over the schema alone.
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 'Retrieves Android system and application logs' with a specific verb and resource. It differentiates from siblings like adb_shell or adb_devices by focusing on log retrieval.
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?
Provides clear use cases: debugging, monitoring, error identification. Mentions when to use (troubleshooting crashes, performance issues) but does not explicitly list when not to use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Executes Package Manager (pm) commands on a connected Android device. Supports listing packages, installing/uninstalling apps, managing permissions, and other 'pm' subcommands. Common commands include: 'list packages', 'install', 'uninstall', 'grant', 'revoke', 'clear', 'enable', 'disable'. Example: pmCommand='list', pmArgs='packages -3' (lists third-party packages) or pmCommand='grant', pmArgs='com.example.app android.permission.CAMERA'
| Name | Required | Description | Default |
|---|---|---|---|
| pmCommand | Yes | Package Manager subcommand, e.g. 'list', 'install', 'uninstall', 'grant', 'revoke', etc. | |
| pmArgs | No | Arguments for the pm subcommand, e.g. 'packages', 'com.example.app android.permission.CAMERA' | |
| device | No | Specific device ID (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool executes pm commands including install/uninstall (destructive actions), but lacks details on required device state, permissions, or error conditions. Given no annotations, it provides minimal behavioral 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 concise (4 sentences) and front-loaded with key information. It efficiently conveys purpose and examples without superfluous text.
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 fails to mention output format (likely raw command output) or explain optional 'device' parameter behavior. Given no output schema, this omission leaves the agent uncertain about expected return values.
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?
While schema coverage is 100%, the description adds concrete examples (e.g., pmCommand='list', pmArgs='packages -3') that clarify parameter combinations and expected usage patterns, enhancing understanding beyond schema definitions.
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 executes Package Manager commands on an Android device and lists supported operations. However, it does not differentiate from the sibling tool 'adb_install', which also handles installation/uninstallation, potentially causing confusion.
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 like 'adb_install' or 'adb_shell'. The description does not mention any context-dependent selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Transfers a file from a connected Android device to the server. Use this to retrieve app data files, logs, configurations, or any accessible file from the device. The file content can be returned as base64-encoded data or as a success message. Requires the full path to the file on the device. Useful for data extraction, log collection, and backing up device files.
| Name | Required | Description | Default |
|---|---|---|---|
| remotePath | Yes | Remote file path on the device | |
| device | No | Specific device ID (optional) | |
| asBase64 | No | Return file content as base64 (default: true) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must disclose behavior. It mentions return formats (base64 or success message), which adds value. Does not specify permission requirements or side effects, but for a file transfer tool this is acceptable.
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?
Three sentences, no wasted words, front-loaded with action verb. Every sentence adds 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 no annotations and no output schema, the description covers the tool's purpose, usage, and return format. Could mention response structure but is 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 coverage is 100%, baseline 3. Description adds meaning by explaining the need for a full path and clarifying the asBase64 parameter's role in returning content vs success message.
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 'Transfers a file from a connected Android device to the server' and lists specific use cases like data extraction and log collection, distinguishing it from siblings like adb_push and adb_logcat.
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 explains when to use the tool (retrieve files, logs, etc.) and requires the full path, but does not explicitly exclude cases where alternative tools like adb_logcat might be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Transfers a file from the server to a connected Android device. Useful for uploading test data, configuration files, media content, or any file needed on the device. The file must be provided as base64-encoded content. Requires specifying the full destination path on the device where the file should be placed. Use this when setting up test environments, restoring backups, or modifying device files.
| Name | Required | Description | Default |
|---|---|---|---|
| fileBase64 | Yes | Base64 encoded file content to push | |
| remotePath | Yes | Remote file path on the device | |
| device | No | Specific device ID (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It specifies that file content must be base64-encoded and that a full destination path is required, but it does not mention behavior on file overwrite, permissions, error conditions, or whether intermediate directories are created. This is adequate but not comprehensive.
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 concise with three sentences, front-loading the core action and purpose. Every sentence adds value, though it could be slightly more structured (e.g., separate usage guidelines from parameter details). Overall it is efficient and focused.
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 three parameters, no output schema, and no annotations, the description covers the basic purpose and usage. However, it lacks details on return values (e.g., success/failure messages), error handling, prerequisites (device connected and authorized), and behavior on existing files. It is minimally complete for a simple file transfer 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 input schema has 100% coverage, so the baseline is 3. The description reinforces parameter semantics by restating that the file must be base64-encoded and that the full path is required, but adds no new details beyond the schema descriptions. It does not clarify the optional 'device' parameter further.
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 action ('Transfers a file from the server to a connected Android device') and distinguishes it from siblings like adb_pull (pull files) and adb_install (install APKs). It provides specific use cases (uploading test data, configuration files, media content) and explicitly mentions file transfer direction.
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 when-to-use guidance: 'Useful for uploading test data, configuration files, media content...' and 'Use this when setting up test environments, restoring backups, or modifying device files.' While it doesn't explicitly state when not to use or list alternatives, the context is clear enough for typical usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Executes a shell command on a connected Android device or emulator. Use this for running Android system commands, managing files and permissions, controlling device settings, or interacting with Android components. Supports all standard shell commands available on Android (ls, pm, am, settings, etc.). Specify a device ID to target a specific device when multiple devices are connected.
| Name | Required | Description | Default |
|---|---|---|---|
| command | Yes | Shell command to execute on the device | |
| device | No | Specific device ID (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description covers basic functionality but does not disclose potential risks like destructive commands or permission requirements. Adequate but not thorough for a powerful shell tool.
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?
Three succinct sentences, front-loaded with core purpose. No extraneous information; every sentence 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?
Does not mention that the tool returns command output (stdout/stderr). With no output schema, this is a gap. Otherwise covers input and usage scenarios. Moderately complete.
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?
Adds value beyond schema by explaining 'command' accepts all standard shell commands and 'device' is optional for targeting specific devices. Schema coverage is 100%, but description enriches understanding.
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?
Clearly states the tool executes a shell command on Android devices, with specific verb 'executes' and resource 'shell command on Android device'. Distinguishes from siblings like adb_install or adb_logcat which are more specific.
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?
Provides clear context for when to use: running system commands, managing files, controlling settings. Mentions device targeting when multiple devices are connected. However, lacks explicit exclusions vs sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Captures the current screen of a connected Android device. FOR HUMAN VIEWING ONLY: This tool provides a visual image that cannot be easily processed programmatically. The screenshot shows exactly what appears on the device screen at the moment of capture. The default behavior returns a success message. Use asBase64=true to get the image as base64-encoded data. No additional parameters required beyond an optional device ID. Use when you need to visually verify UI elements for human inspection only. NOTE: For programmatic analysis or to identify UI elements, use inspect-ui instead.
| Name | Required | Description | Default |
|---|---|---|---|
| device | No | Specific device ID (optional) | |
| asBase64 | No | Return image as base64 (default: false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses default success message and asBase64 behavior, but does not explicitly state that the operation is read-only or non-destructive. Annotations are absent, so description carries full burden.
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?
Well-structured with clear purpose first, then usage note. Slightly verbose but each sentence adds value. Could be tightened slightly.
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, yet description adequately explains return behaviors (default success, asBase64=true gives image data). Also provides alternative tool context. Complete for a tool with 2 optional params.
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%, so description adds minimal value beyond restating optional device ID and asBase64 parameter. 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?
Clearly states 'Captures the current screen of a connected Android device' and specifies 'FOR HUMAN VIEWING ONLY', distinguishing it from sibling 'inspect-ui' for programmatic analysis.
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?
Explicitly tells when to use ('visually verify UI elements for human inspection') and when not to use ('for programmatic analysis, use inspect-ui instead').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Captures the complete UI hierarchy of the current screen as an XML document. This provides structured XML data that can be parsed to identify UI elements and their properties. Essential for UI automation, determining current app state, and identifying interactive elements. Returns the UI structure including all elements, their IDs, text values, bounds, and clickable states. This is significantly more useful than screenshots for AI processing and automation tasks.
| Name | Required | Description | Default |
|---|---|---|---|
| device | No | Specific device ID (optional) | |
| outputPath | No | Custom output path on device (default: /sdcard/window_dump.xml) | |
| asBase64 | No | Return XML content as base64 (default: false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It describes the output (XML with elements, IDs, text, bounds, clickable states) but does not explicitly state that the tool is read-only or disclose any side effects, though the read-only nature is implied.
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 four sentences long and front-loaded with the primary action. It is fairly concise, though some sentences could be tightened without losing meaning.
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 (3 optional params, no output schema), the description adequately covers the return format and use cases. It lacks details on error handling or edge cases, but these are not critical for a UI capture 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?
Schema description coverage is 100%, so the schema already documents all three parameters. The description adds no additional meaning beyond the schema, meeting the baseline expectation of 3.
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 explicitly states it 'captures the complete UI hierarchy' as an XML document, with a specific verb and resource. It also highlights its utility over screenshots, differentiating it clearly from sibling tools like adb commands.
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 notes it is 'essential for UI automation, determining current app state, and identifying interactive elements' and explicitly states it is more useful than screenshots. While it does not list alternatives or when not to use, it provides clear use cases.
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.
v1.0.0adb_activity_manageradb_package_manageradb_devicesadb_installadb_logcatadb_pulladb_pushadb_shelldump_imageinspect_uiEach tool targets a distinct ADB functionality, from device listing and file transfer to UI inspection and package management, with no overlapping purposes.
Most tools follow 'adb_' prefix, but 'dump_image' and 'inspect_ui' lack the prefix, creating a minor inconsistency in an otherwise predictable pattern.
With 10 tools, the collection covers essential ADB operations without being excessive or insufficient, well-scoped for typical device management tasks.
The set covers major ADB workflows including device management, app installation, logging, file transfer, and UI inspection, though a dedicated uninstall tool is absent.
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.
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.
Human-input bridge for AI agents with voice-first answer links, MCP tools, and HTTP APIs.
Control Android TV from any AI. 38 MCP tools: playback, recap, recommend, smart-home, schedules.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/srmorete/adb-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
