Bastante sorprendido de que este repositorio haya alcanzado las 50 estrellas (!) el ecosistema es bastante generoso a veces, ¡gracias por marcarlo como favorito!
He estado trabajando en algo que es más rápido, más escalable y que también funciona con iOS, eche un vistazo a mobile-device-mcp.
Y deje también una ⭐ :)
Un servidor MCP (Model Context Protocol) para interactuar con dispositivos Android a través de ADB. Esta herramienta basada en TypeScript proporciona un puente entre los modelos de IA y la funcionalidad de los dispositivos Android.
Related MCP server: Ultimate Android MCP
📱 Gestión de dispositivos - Listar e interactuar con dispositivos Android conectados
📦 Instalación de aplicaciones - Desplegar archivos APK en dispositivos conectados
📋 Registro (Logging) - Acceder a los registros del dispositivo a través de logcat
🔄 Transferencia de archivos - Enviar y recibir archivos entre el dispositivo y el host
📸 Interacción con la interfaz de usuario - Capturar capturas de pantalla y analizar la jerarquía de la interfaz de usuario
🔧 Ejecución de comandos de shell - Ejecutar comandos personalizados en el dispositivo
Node.js (se recomienda v16 o superior, probado con Node.js v16, v18 y v20)
ADB (Android Debug Bridge) instalado y en su PATH
Un dispositivo Android o emulador conectado mediante USB o red con la depuración USB habilitada
Permiso para acceder al dispositivo (autorización de depuración aceptada en el dispositivo)
Para instalar el servidor de dispositivos Android ADB para Claude Desktop automáticamente a través de 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-mcpEl servidor utiliza las rutas predeterminadas de ADB. Para una ubicación de ADB personalizada:
export ADB_PATH=/path/to/adb
npx adb-mcpAñada la configuración del servidor MCP de ADB:
{
"mcpServers": {
"adb": {
"command": "npx",
"args": [
"adb-mcp"
]
}
}
}IMPORTANTE: El servidor debe estar ejecutándose antes de usar cualquier herramienta ADB.
Inicie el servidor usando:
npx adb-mcpDebería ver:
[INFO] ADB MCP Server connected and readyMantenga esta ventana de terminal abierta mientras utiliza las herramientas ADB.
Todas las herramientas están disponibles con la siguiente convención de nombres:
adb_devices - Listar dispositivos conectados
adb_shell - Ejecutar comandos de shell en un dispositivo
adb_install - Instalar un archivo APK usando una ruta de archivo local
adb_package_manager - Ejecutar comandos del Administrador de paquetes (pm) - listar paquetes, conceder/revocar permisos, gestionar aplicaciones
adb_activity_manager - Ejecutar comandos del Administrador de actividades (am) - iniciar actividades, transmitir intents, controlar el comportamiento de la aplicación
adb_logcat - Ver los registros del dispositivo con filtrado opcional
adb_pull - Extraer archivos de un dispositivo
adb_push - Enviar archivos a un dispositivo
dump_image - Tomar una captura de pantalla de la pantalla actual
inspect_ui - Obtener la jerarquía de la interfaz de usuario en formato XML (más útil para la interacción con IA)
Si las herramientas no funcionan:
Problemas del servidor:
Asegúrese de que el servidor se esté ejecutando (npx adb-mcp)
Compruebe la salida del servidor en busca de mensajes de error
Pruebe con registros detallados: LOG_LEVEL=3 npx adb-mcp
Elimine los procesos colgados:
ps aux | grep "adb-mcp" | grep -v grep
luego kill -9 [PID]
Conexión del dispositivo:
Verifique la conexión con adb_devices
Si aparece "unauthorized", acepte la autorización de depuración en el dispositivo
Compruebe las conexiones USB/red
Intente reiniciar ADB: adb kill-server && adb start-server
Problemas de ADB:
Verifique la instalación de ADB: adb version
Configuración del dispositivo:
Use un emulador (fue construido usando uno), para dispositivos reales quizás intente esto:
Asegúrese de que la depuración USB esté habilitada
Para versiones más nuevas de Android, habilite "Depuración USB (ajustes de seguridad)"
Pruebe con un puerto USB o cable diferente
o hágamelo saber en un issue
Android 8.0 y superior
Clientes MCP incluyendo Claude en Cursor IDE
Fue construido en macOS pero debería ejecutarse en cualquier sistema compatible con POSIX (Linux, etc.).
No lo probé en Windows pero quizás funcione.
¡Las contribuciones son bienvenidas! Envíe un Pull Request.
Para cambios importantes, abra un issue para discutirlo primero.
Por supuesto, también puede hacer un fork
Nota: este proyecto fue vibe-coded así que si detecta algo extraño... bueno, ahora ya lo sabe 🙂
Este proyecto está bajo la Licencia MIT - consulte el archivo LICENSE para obtener más detalles.
Construido con 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.
v1.0.0adb_activity_manageradb_package_manageradb_devicesadb_installadb_logcatadb_pulladb_pushadb_shelldump_imageinspect_uiScored across 10 tools
Each 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.
Control real Android and iOS devices with LLM agents — tap, swipe, type, automate flows.
Cloud Android phones for AI agents: create a phone, read the screen, tap, type, install APKs, park.
Drive real devices from your AI Coding tool. Embed a client SDK (Unity, Godot, Flutter, iOS/macOS, Android, React Native, Web) in your app, then capture screenshots, traverse the UI tree, inject taps and key events, and run automated test tasks on the physical device over a secure relay.
Disposable cloud Android emulators for coding agents: run an APK or PR build, tap, type, screenshot.
