非常惊讶这个仓库竟然获得了 50 个星标（！），生态系统有时非常慷慨，感谢您的点赞！
我正在开发一个更快、更具可扩展性且支持 iOS 的项目，请查看 mobile-device-mcp。
也请留下一个 ⭐ 吧 :)
一个用于通过 ADB 与 Android 设备交互的 MCP（模型上下文协议）服务器。这个基于 TypeScript 的工具为 AI 模型和 Android 设备功能之间提供了桥梁。
Related MCP server: Ultimate Android MCP
📱 设备管理 - 列出并与已连接的 Android 设备交互
📦 应用安装 - 将 APK 文件部署到已连接的设备
📋 日志记录 - 通过 logcat 访问设备日志
🔄 文件传输 - 在设备和主机之间推送和拉取文件
📸 UI 交互 - 截取屏幕截图并分析 UI 层级
🔧 Shell 命令执行 - 在设备上运行自定义命令
Node.js（建议 v16 或更高版本，已在 Node.js v16、v18 和 v20 上测试）
已安装 ADB (Android Debug Bridge) 并将其添加到 PATH 中
通过 USB 或网络连接的 Android 设备或模拟器，并启用了 USB 调试
拥有访问设备的权限（已在设备上接受调试授权）
要通过 Smithery 自动为 Claude Desktop 安装 ADB Android Device Server：
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 - 在设备上执行 shell 命令
adb_install - 使用本地文件路径安装 APK 文件
adb_package_manager - 执行包管理器 (pm) 命令 - 列出包、授予/撤销权限、管理应用
adb_activity_manager - 执行活动管理器 (am) 命令 - 启动活动、广播意图、控制应用行为
adb_logcat - 查看设备日志，支持可选过滤
adb_pull - 从设备拉取文件
adb_push - 向设备推送文件
dump_image - 对当前屏幕进行截图
inspect_ui - 以 XML 格式获取 UI 层级（对 AI 交互最有用）
如果工具无法正常工作：
服务器问题：
确保服务器正在运行 (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 及更高版本
包括 Cursor IDE 中的 Claude 在内的 MCP 客户端
在 macOS 上构建，但应该可以在任何兼容 POSIX 的系统（Linux 等）上运行。
未在 Windows 上尝试，但可能可以运行。
欢迎贡献！请提交 Pull Request。
对于重大更改，请先开启一个 issue 进行讨论。
当然，你也可以 fork 本项目
注意： 这个项目是 vibe-coded（凭感觉编码）的，所以如果你发现一些奇怪的东西……嗯，现在你知道原因了 🙂
本项目采用 MIT 许可证 - 有关详细信息，请参阅 LICENSE 文件。
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
