Я очень удивлен, что этот репозиторий набрал 50 звезд (!), экосистема иногда бывает очень щедрой, спасибо, что поставили звезду!
Я работаю над чем-то более быстрым, масштабируемым и работающим с iOS, взгляните на mobile-device-mcp.
И не забудьте поставить ⭐ :)
Сервер MCP (Model Context Protocol) для взаимодействия с устройствами Android через ADB. Этот инструмент на базе TypeScript обеспечивает мост между моделями ИИ и функциональностью устройств Android.
Related MCP server: Ultimate Android MCP
📱 Управление устройствами - Список подключенных устройств Android и взаимодействие с ними
📦 Установка приложений - Развертывание APK-файлов на подключенных устройствах
📋 Логирование - Доступ к логам устройства через logcat
🔄 Передача файлов - Копирование файлов между устройством и хостом
📸 Взаимодействие с UI - Создание скриншотов и анализ иерархии UI
🔧 Выполнение команд оболочки - Запуск пользовательских команд на устройстве
Node.js (рекомендуется v16 или выше, протестировано с Node.js v16, v18 и v20)
Установленный ADB (Android Debug Bridge), добавленный в ваш PATH
Устройство Android или эмулятор, подключенный через USB или сеть с включенной отладкой по USB
Разрешение на доступ к устройству (подтвержденная авторизация отладки на устройстве)
Чтобы установить ADB Android Device Server для Claude Desktop автоматически через 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-mcpСервер использует пути ADB по умолчанию. Для указания собственного расположения ADB:
export ADB_PATH=/path/to/adb
npx adb-mcpДобавьте конфигурацию сервера ADB MCP:
{
"mcpServers": {
"adb": {
"command": "npx",
"args": [
"adb-mcp"
]
}
}
}ВАЖНО: Сервер должен быть запущен перед использованием любых инструментов ADB.
Запустите сервер с помощью:
npx adb-mcpВы должны увидеть:
[INFO] ADB MCP Server connected and readyДержите это окно терминала открытым во время использования инструментов ADB.
Все инструменты доступны со следующим соглашением об именовании:
adb_devices - Список подключенных устройств
adb_shell - Выполнение команд оболочки на устройстве
adb_install - Установка APK-файла с использованием локального пути к файлу
adb_package_manager - Выполнение команд диспетчера пакетов (pm) - список пакетов, предоставление/отзыв разрешений, управление приложениями
adb_activity_manager - Выполнение команд диспетчера действий (am) - запуск действий, широковещательная рассылка намерений, управление поведением приложений
adb_logcat - Просмотр логов устройства с дополнительной фильтрацией
adb_pull - Копирование файлов с устройства
adb_push - Копирование файлов на устройство
dump_image - Создание скриншота текущего экрана
inspect_ui - Получение иерархии UI в формате XML (наиболее полезно для взаимодействия с ИИ)
Если инструменты не работают:
Проблемы с сервером:
Убедитесь, что сервер запущен (npx adb-mcp)
Проверьте вывод сервера на наличие сообщений об ошибках
Попробуйте подробные логи: LOG_LEVEL=3 npx adb-mcp
Завершите зависшие процессы:
ps aux | grep "adb-mcp" | grep -v grep
затем kill -9 [PID]
Подключение устройства:
Проверьте подключение с помощью adb_devices
Если статус "unauthorized", подтвердите авторизацию отладки на устройстве
Проверьте USB/сетевые подключения
Попробуйте перезапустить ADB: adb kill-server && adb start-server
Проблемы с ADB:
Проверьте установку ADB: adb version
Настройка устройства:
Используйте эмулятор (проект был создан с его использованием), для реальных устройств попробуйте следующее:
Убедитесь, что отладка по USB включена
Для новых версий Android включите "Отладка по USB (настройки безопасности)"
Попробуйте другой USB-порт или кабель
или сообщите мне в issue
Android 8.0 и выше
Клиенты MCP, включая Claude в Cursor IDE
Был создан на macOS, но должен работать на любой POSIX-совместимой системе (Linux и т.д.).
Не тестировался на Windows, но возможно будет работать.
Вклад приветствуется! Отправляйте Pull Request.
Для серьезных изменений сначала откройте issue для обсуждения.
Вы, конечно, можете сделать форк
Примечание: этот проект был создан в стиле vibe-coded, так что если заметите что-то странное... ну, теперь вы знаете 🙂
Этот проект лицензирован по лицензии MIT - подробности см. в файле LICENSE.
Создано с использованием 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.
