The DroidMind server enables AI-assisted control and management of Android devices via ADB through the Model Context Protocol (MCP).
Capabilities include:
Device Management: Connect/disconnect devices, list connected devices, retrieve properties, and reboot
App Control: Install, uninstall, start, stop apps, clear data, and list installed packages
File Operations: Push, pull, list, read, write, delete files/directories and check existence
System Analysis: Access logcat, capture bug reports, and dump process heap
UI Automation: Take screenshots, simulate taps, swipes, text input, and key presses
Shell Commands: Execute ADB shell commands with security validation
Intent Handling: Start app activities with custom intents
Security: Command validation, risk assessment, and sanitization to protect the device
Enables control and interaction with Android devices through ADB, including device management, file system access, app installation, UI automation, system analysis, and debugging features.
Integrates with GitHub for repository management, allowing users to clone the DroidMind repository and contribute through GitHub's pull request workflow.
Integrates with Ko-fi for donations, allowing users to support the project creator by purchasing energy drinks.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@DroidMind take a screenshot of my device and save it to my computer"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Control Android devices with AI through the Model Context Protocol
DroidMind is a powerful bridge between AI assistants and Android devices, enabling control, debugging, and system analysis through natural language. By implementing the Model Context Protocol (MCP), DroidMind allows AI models to directly interact with Android devices via ADB in a secure, structured way. When used as part of an agentic coding workflow, DroidMind can enable your assistant to build and debug with your device directly in the loop.
DroidMind empowers AI assistants to:
📱 Manage Devices: Connect via USB/TCP-IP, list devices, view properties, and reboot.
📊 Analyze Systems: Access logs (logcat, ANR, crash, battery), capture bug reports, and dump heap.
📂 Handle Files: Browse, read, write, push, pull, delete, and manage device files/directories.
📦 Control Apps: Install, uninstall, start, stop, clear data, and inspect app details (manifest, permissions, activities).
🖼️ Automate UI: Perform taps, swipes, text input, and key presses.
🐚 Execute Shell Commands: Run ADB shell commands with a security-conscious framework.
🔒 Operate Securely: Benefit from command validation, risk assessment, and sanitization.
💬 Integrate Seamlessly: Connect with any MCP-compatible client (Claude, Cursor, Cline, etc.).
For a detailed list of capabilities, see the User Manual and MCP Reference.
Related MCP server: MCP Android Agent
uvx)For the fastest way to integrate DroidMind with an MCP-compatible IDE (like Cursor), you can configure it to run DroidMind directly from its GitHub repository using uvx. This method does not require you to manually clone or install DroidMind first.
Add the following to your IDE's MCP configuration (e.g., .cursor/mcp.json for Cursor):
{
"mcpServers": {
"droidmind": {
"command": "uvx",
"args": [
"--from",
"git+https://github.com/hyperb1iss/droidmind",
"droidmind",
"--transport",
"stdio" // The default and preferred mode for most IDE integrations
]
}
}
}Your IDE will be configured to launch DroidMind on demand. Full instructions for this setup are in the Quick Start Guide.
Python 3.13 (3.14 not yet supported)
uv (Python package manager)
Android device with USB debugging enabled
ADB (Android Debug Bridge) installed and in your system's PATH
For detailed instructions on setting up DroidMind, including the quick IDE integration with uvx (covered in the Quick Start), manual installation from source, or using Docker, please see our comprehensive Installation Guide.
How you run DroidMind depends on your setup:
IDE Integration (via uvx): Your IDE automatically manages running DroidMind as configured in its MCP settings (e.g., mcp.json). See the Quick Start Guide.
Manual Installation: After installing from source, you can run DroidMind directly.
Stdio (for direct terminal interaction or some IDE setups):
droidmind --transport stdioSSE (for web UIs or AI assistants like Claude Desktop):
droidmind --transport sseThis usually starts a server at sse://localhost:4256/sse.
Docker: Refer to the Docker Guide for commands to run DroidMind in a container.
Refer to the Installation Guide for more details on running DroidMind in different environments.
DroidMind can also be run using Docker for a consistent, containerized environment. This is particularly useful for deployment and isolating dependencies.
For comprehensive instructions on building the Docker image and running DroidMind in a container with stdio or SSE transport, including notes on ADB device access, please refer to our Docker Guide.
With an AI assistant connected to DroidMind, you can make requests like:
"List all connected Android devices and show their properties."
"Take a screenshot of my Pixel."
"Install this APK on emulator-5554."
"Show me the recent crash logs from your_device_serial."
"Tap the 'Next' button on the current screen of emulator-5554."
For more inspiration, check out our Example Queries and Workflows in the User Manual.
DroidMind incorporates a security framework to protect your devices:
Command Validation & Sanitization
Risk Assessment Categorization
Protected Path Operations
Comprehensive Logging
High-risk operations are flagged, and critical ones are blocked by default. Learn more in our Security Considerations chapter.
DroidMind uses uv for dependency management and development workflows.
# Install/update dependencies (creates/updates `.venv`)
uv sync --all-groups
# Run tests
uv run pytest
# Run linting
uv run ruff check .
# Run type checking
uv run pyrightContributions are welcome! Please feel free to submit a Pull Request.
Fork the repository.
Create your feature branch (git checkout -b feature/amazing-feature).
Set up your development environment with uv.
Make your changes.
Run tests, linting, and type checking.
Commit your changes (git commit -m 'Add some amazing feature').
Push to the branch (git push origin feature/amazing-feature).
Open a Pull Request.
This project is licensed under the Apache License - see the LICENSE file for details.
Created by Stefanie Jane 🌠
If you find DroidMind useful, buy me a Monster Ultra Violet ⚡️
Perform various application management operations on an Android device.
This single tool consolidates various app-related actions. The 'action' parameter determines the operation.
Args:
serial: Device serial number.
action: The specific app operation to perform.
ctx: MCP Context for logging and interaction.
package (Optional[str]): Package name for the target application. Required by most actions.
apk_path (Optional[str]): Path to the APK file (local to the server). Used by install_app.
reinstall (Optional[bool]): Whether to reinstall if app exists. Used by install_app.
grant_permissions (Optional[bool]): Whether to grant all requested permissions. Used by install_app.
keep_data (Optional[bool]): Whether to keep app data and cache directories. Used by uninstall_app.
activity (Optional[str]): Optional activity name to start. Used by start_app.
extras (Optional[dict[str, str]]): Optional intent extras. Used by start_intent.
include_system_apps (Optional[bool]): Whether to include system apps. Used by list_packages.
include_app_name (Optional[bool]): Whether to include app labels (best-effort). Used by list_packages.
include_apk_path (Optional[bool]): Whether to include APK paths. Used by list_packages.
max_packages (Optional[int]): Max packages to return. Used by list_packages.
Returns: A string message indicating the result or status of the operation.
Available Actions and their specific argument usage:
action="install_app"
Requires: apk_path
Optional: reinstall, grant_permissions
action="uninstall_app"
Requires: package
Optional: keep_data
action="start_app"
Requires: package
Optional: activity
3b. action="start_intent"
Requires: package, activity
Optional: extras
action="stop_app"
Requires: package
action="clear_app_data"
Requires: package
action="list_packages"
Optional: include_system_apps, include_app_name, include_apk_path, max_packages
action="get_app_manifest"
Requires: package
action="get_app_permissions"
Requires: package
action="get_app_activities"
Requires: package
action="get_app_info"
Requires: package
| Name | Required | Description | Default |
|---|---|---|---|
| serial | Yes | ||
| action | Yes | ||
| package | No | ||
| apk_path | No | ||
| reinstall | No | ||
| grant_permissions | No | ||
| keep_data | No | ||
| activity | No | ||
| extras | No | ||
| include_system_apps | No | ||
| include_app_name | No | ||
| include_apk_path | No | ||
| max_packages | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It details required vs optional parameters per action but does not disclose preconditions (e.g., device connection), side effects, or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a summary, parameter list, action list, and per-action details. Though lengthy, it is justified given the complexity of 11 actions; however, the inclusion of 'ctx' parameter not in schema is a minor inconsistency.
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 lack of annotations and low schema coverage, the description covers required/optional params per action and notes the return type. However, it omits device prerequisites, error scenarios, and includes an undocumented 'ctx' parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds significant meaning by explaining each parameter's purpose and mapping them to specific actions (e.g., 'apk_path' for install, 'package' for uninstall).
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 performs 'various application management operations on an Android device' and lists 11 specific actions, making it distinct from sibling tools like android-shell or android-ui.
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 that the tool consolidates app-related actions and lists each action with required parameters, but does not explicitly guide when to use this tool over alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Perform various device management operations on Android devices.
This single tool consolidates various device-related actions. The 'action' parameter determines the operation.
Args: action: The specific device operation to perform. ctx: MCP Context for logging and interaction. serial (Optional[str]): Device serial number. Required by most actions except connect/list. ip_address (Optional[str]): IP address for 'connect_device' action. port (Optional[int]): Port for 'connect_device' action (default: 5555). mode (Optional[str]): Reboot mode for 'reboot_device' action (default: "normal").
Returns: A string message indicating the result or status of the operation.
Available Actions and their specific argument usage:
action="list_devices"
No specific arguments required beyond ctx.
action="connect_device"
Requires: ip_address
Optional: port
action="disconnect_device"
Requires: serial
action="reboot_device"
Requires: serial
Optional: mode (e.g., "normal", "recovery", "bootloader")
action="device_properties"
Requires: serial
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | ||
| serial | No | ||
| ip_address | No | ||
| port | No | ||
| mode | No | normal |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral burden. It details each action's required and optional parameters and notes return type. However, it lacks disclosure of side effects (e.g., reboot disconnects device) and error cases. Still, it is fairly transparent, earning a 4.
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 well-structured with a brief intro, standard arg list, and a clear enumeration of actions with their specific arguments. Every sentence adds value; no fluff. Score 5 for efficient organization.
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 5 parameters, 5 actions, and no annotations, the description covers action-parameter dependencies and return type. It lacks error handling or examples, but is otherwise complete for a moderately complex tool. Score 4.
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 0%, so the description must compensate. It effectively maps parameters to actions, clarifying which parameters are needed for which operation. This adds significant meaning beyond the schema, though detailed constraints (e.g., valid formats) are omitted. Score 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it performs device management operations and lists actions via an enum. While it does not explicitly differentiate from sibling tools like android-shell or android-diag, the action list provides clarity on scope. A score of 4 reflects clear purpose with minor sibling differentiation gap.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by enumerating actions but does not provide explicit when-to-use or when-not-to-use guidance compared to siblings. No alternatives or exclusions are mentioned. Score 3 for implied but unguided usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Perform diagnostic operations like capturing bug reports or heap dumps.
Args: ctx: MCP Context. serial: Device serial number. action: The diagnostic action to perform. output_path: Optional. Path to save the output file. For bugreport: host path for adb to write the .zip. If empty, a temp file is used & summarized. For dump_heap: local path to save the .hprof. If empty, a temp file is used. include_screenshots: For CAPTURE_BUGREPORT. Default True. package_or_pid: For DUMP_HEAP. App package name or process ID. native: For DUMP_HEAP. True for native (C/C++) heap, False for Java. Default False. timeout_seconds: Max time for the operation. If 0, action-specific defaults are used (bugreport: 300s, dump_heap: 120s).
Returns: A string message indicating the result or path to the output.
| Name | Required | Description | Default |
|---|---|---|---|
| serial | Yes | ||
| action | Yes | ||
| output_path | No | ||
| include_screenshots | No | ||
| package_or_pid | No | ||
| native | No | ||
| timeout_seconds | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It explains that output_path defaults to a temp file and is summarized, and mentions timeout defaults. However, it does not disclose potential side effects like performance impact or device lock requirements. It is adequate but not fully transparent.
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 well-structured with separate Args and Returns sections, and front-loads the purpose. It is detailed but not excessively verbose; every sentence adds value. Minor redundancy in separately explaining actions, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 params, no annotations, output schema exists), the description covers all parameters, default behaviors, and return value. It omits prerequisites like device connectivity and error handling, but is reasonably complete for an AI agent.
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?
Despite 0% schema description coverage, the description adds meaning to all parameters: serial, action, output_path, include_screenshots, package_or_pid, native, and timeout_seconds. It explains defaults and behavior for optional paths. This compensates well for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Perform diagnostic operations like capturing bug reports or heap dumps.' It uses a specific verb and resource, and distinguishes from sibling tools that focus on other aspects like app, device, file, log, screenshot, shell, and UI. This leaves no ambiguity about the tool's purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lacks explicit guidance on when to use this tool versus alternatives. It does not mention context such as troubleshooting device issues or any exclusions. The intended usage is only implied by the parameter descriptions, but no explicit when-to-use or when-not-to-use advice is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Perform file and directory operations on an Android device.
This single tool consolidates various file system actions. The 'action' parameter determines the operation.
Args: serial: Device serial number. action: The specific file operation to perform. See available actions below. ctx: MCP Context for logging and interaction. path (Optional[str]): General path argument on the device. Used by: list_directory, delete_file, create_directory, file_exists, file_stats. Can also be used by read_file and write_file as an alternative to 'device_path'. local_path (Optional[str]): Path on the DroidMind server machine. Used by: push_file (source), pull_file (destination). device_path (Optional[str]): Path on the Android device. Used by: push_file (destination), pull_file (source), read_file (source), write_file (destination). If 'path' is also provided for read/write, 'device_path' takes precedence. content (Optional[str]): Text content to write. Used by: write_file. max_size (Optional[int]): Maximum file size in bytes for read_file (default: 100KB). Used by: read_file.
Returns: Union[str, bool]: A string message indicating the result or status for most actions. Returns a boolean for the 'file_exists' action.
Available Actions and their specific argument usage:
action="list_directory": Lists contents of a directory.
Requires: path (directory path on device).
Returns: Formatted string of directory contents.
action="push_file": Uploads a file from the local server to the device.
Requires: local_path (source on server), device_path (destination on device).
Returns: String message confirming upload.
action="pull_file": Downloads a file from the device to the local server.
Requires: device_path (source on device), local_path (destination on server).
Returns: String message confirming download.
action="delete_file": Deletes a file or directory from the device.
Requires: path (path to delete on device).
Returns: String message confirming deletion.
action="create_directory": Creates a directory on the device.
Requires: path (directory path to create on device).
Returns: String message confirming creation.
action="file_exists": Checks if a file or directory exists on the device.
Requires: path (path to check on device).
Returns: True if exists, False otherwise.
action="read_file": Reads the contents of a file from the device.
Requires: device_path (or path) for the file on device.
Optional: max_size (defaults to 100KB).
Returns: String containing file contents or error message.
action="write_file": Writes text content to a file on the device.
Requires: device_path (or path) for the file on device, content (text to write).
Returns: String message confirming write.
action="file_stats": Gets detailed statistics for a file or directory.
Requires: path (path on device).
Returns: Markdown-formatted string of file/directory statistics.
| Name | Required | Description | Default |
|---|---|---|---|
| serial | Yes | ||
| action | Yes | ||
| path | No | ||
| local_path | No | ||
| device_path | No | ||
| content | No | ||
| max_size | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description fully covers behavior: explains each action, parameter precedence (device_path over path), defaults (max_size=100KB), and return types. Destructive operations are implied by action names.
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 sections and bullet points, front-loaded with purpose. Slightly verbose due to repeated 'Used by' lines, but every sentence adds value for an agent.
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 7 parameters, 2 required, no annotations, and an output schema exists, the description provides complete guidance for all actions, including parameter mapping and return types, ensuring correct invocation.
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 has 0% parameter descriptions; description compensates thoroughly by explaining each parameter's purpose, which actions use them, precedence rules, and defaults, adding significant meaning beyond the schema.
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 it performs file and directory operations on an Android device, listing 9 distinct actions, which differentiates it from sibling tools like android-app or android-shell.
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?
Usage context is implied through action descriptions, but no explicit guidance on when to use this tool versus alternatives (e.g., android-shell for commands) or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Perform various log retrieval operations on an Android device.
This single tool consolidates various log-related actions. The 'action' parameter determines the operation.
Args:
serial: Device serial number.
action: The specific log operation to perform.
ctx: MCP Context for logging and interaction.
package (Optional[str]): Package name for get_app_logs action.
lines (int): Number of lines to fetch for logcat actions (default: 1000).
filter_expr (Optional[str]): Logcat filter expression for get_device_logcat.
buffer (Optional[str]): Logcat buffer for get_device_logcat (default: "main").
format_type (Optional[str]): Logcat output format for get_device_logcat (default: "threadtime").
max_size (Optional[int]): Max output size for get_device_logcat (default: 100KB).
Returns: A string message containing the requested logs or status.
Available Actions and their specific argument usage:
action="get_device_logcat"
Optional: lines, filter_expr, buffer, format_type, max_size.
action="get_app_logs"
Requires: package.
Optional: lines.
action="get_anr_logs"
No specific arguments beyond serial and ctx.
action="get_crash_logs"
No specific arguments beyond serial and ctx.
action="get_battery_stats"
No specific arguments beyond serial and ctx.
| Name | Required | Description | Default |
|---|---|---|---|
| serial | Yes | ||
| action | Yes | ||
| package | No | ||
| lines | No | ||
| filter_expr | No | ||
| buffer | No | main | |
| format_type | No | threadtime | |
| max_size | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It describes each action and its parameters, but lacks details on performance implications, error conditions, or prerequisites (e.g., USB debugging enabled). For a read-heavy tool, 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 somewhat lengthy but well-structured with bullet points for each action, front-loading the purpose. Every sentence adds value, though a slightly more succinct summary of all actions could improve conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 parameters, 5 actions), the description covers all necessary usage details. The output schema is not described, but the return type ('string message') is mentioned. This is largely sufficient for an agent to decide and execute.
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 0%, yet the description adds significant meaning: it maps each parameter to specific actions, explains optional vs required, and provides defaults. This fully compensates for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it performs 'various log retrieval operations on an Android device' and lists five specific actions via the 'action' parameter. This distinguishes it from siblings like android-app, android-device, etc., which handle different domains.
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 that the 'action' parameter determines the operation and details which arguments are required or optional for each action. While it does not explicitly contrast with siblings, the context is sufficient for an agent to choose and invoke the tool correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a screenshot from a device.
Args: serial: Device serial number ctx: MCP context quality: JPEG quality (1-100, lower means smaller file size)
Returns: The device screenshot as an image
| Name | Required | Description | Default |
|---|---|---|---|
| serial | Yes | ||
| quality | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description only states it gets a screenshot but does not disclose behavioral traits such as whether the device needs to be unlocked, any side effects, or latency considerations. For a read operation, this minimal disclosure is insufficient.
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 and uses a structured Args/Returns format, front-loading the purpose. It is slightly verbose due to docstring conventions but remains efficient. The inclusion of 'ctx' parameter not in schema is a minor inconsistency.
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 (screenshot) and lack of output schema, the description adequately covers functionality, parameters, and return type. It could mention prerequisites like device connection, but overall completeness is satisfactory.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds value by explaining 'serial: Device serial number' and 'quality: JPEG quality (1-100, lower means smaller file size)'. It partially compensates for missing schema descriptions, though the 'ctx' parameter in the docstring is not in the schema.
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 'Get a screenshot from a device,' specifying the action and resource. It distinctly separates from sibling tools like android-app, android-device, etc., which focus on other device aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention contexts where a screenshot is appropriate or when to use other tools like android-shell or android-file.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a shell command on the device.
Args: serial: Device serial number command: Shell command to run max_lines: Maximum lines of output to return (default: 1000) Use positive numbers for first N lines, negative for last N lines Set to None for unlimited (not recommended for large outputs) max_size: Maximum output size in characters (default: 100000) Limits total response size regardless of line count
Returns: Command output
| Name | Required | Description | Default |
|---|---|---|---|
| serial | Yes | ||
| command | Yes | ||
| max_lines | No | ||
| max_size | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries full burden. It adds behavioral context about output limits (max_lines with sign logic, max_size, defaults) but does not disclose potential destructive effects, security implications, or error conditions of running shell commands.
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 structured with Args and Returns sections, making it easy to parse. Slightly verbose but each sentence adds value; no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that runs arbitrary commands, the description adequately covers input parameters but lacks details on output format (despite having output schema) and potential risks or prerequisites, such as device connectivity or authentication.
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 0%, so the description must compensate. It explains all four parameters: serial, command, max_lines (with positive/negative line logic and default), and max_size (default and limit). This adds significant meaning beyond the schema's type-only 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 the tool's purpose: 'Run a shell command on the device.' It uses a specific verb (Run) and resource (shell command) with context (on the device), and distinguishes from sibling tools that manage apps, devices, diagnostics, files, logs, screenshots, and UI.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor any conditions for appropriate use or exclusions. It only lists parameters without contextual usage advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Perform various UI interaction operations on an Android device.
Args: ctx: MCP Context. serial: Device serial number. action: The UI action to perform. x: X coordinate (for tap). y: Y coordinate (for tap). start_x: Starting X coordinate (for swipe). start_y: Starting Y coordinate (for swipe). end_x: Ending X coordinate (for swipe). end_y: Ending Y coordinate (for swipe). duration_ms: Duration of the swipe in milliseconds (default: 300). text: Text to input (for input_text). keycode: Android keycode to press (for press_key). package: Package name (for start_intent). activity: Activity name (for start_intent). extras: Optional intent extras (for start_intent).
Returns: A string message indicating the result of the operation.
| Name | Required | Description | Default |
|---|---|---|---|
| serial | Yes | ||
| action | Yes | ||
| x | No | ||
| y | No | ||
| start_x | No | ||
| start_y | No | ||
| end_x | No | ||
| end_y | No | ||
| duration_ms | No | ||
| text | No | ||
| keycode | No | ||
| package | No | ||
| activity | No | ||
| extras | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits. It only lists parameters and actions but does not describe side effects (e.g., app changes), prerequisites (e.g., unlocked device), or limitations.
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 structured as a docstring with Args and Returns sections, but it is somewhat lengthy and could be more concise by grouping related parameters.
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 14 parameters, no schema descriptions, and no annotations, the description provides basic parameter explanations but lacks usage context, error handling, or return value details beyond 'a string message'.
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 description adds meaning to each parameter (e.g., 'x: X coordinate (for tap)'), compensating for the 0% schema description coverage. However, it could provide more detail on ranges or formats.
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 performs various UI interaction operations on an Android device and lists the supported actions (tap, swipe, etc.). This distinguishes it from sibling tools like android-device or android-app.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description does not mention when not to use it or what other tools exist for different tasks.
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.0android-app6 fields changedInput schema / $defs / AppAction / enumPrevious value: -[
- "install_app",
- "uninstall_app",
- "start_app",
- "stop_app",
- "clear_app_data",
- "list_packages",
- "get_app_manifest",
- "get_app_permissions",
- "get_app_activities",
- "get_app_info"
-]New value: +[
+ "install_app",
+ "uninstall_app",
+ "start_app",
+ "start_intent",
+ "stop_app",
+ "clear_app_data",
+ "list_packages",
+ "get_app_manifest",
+ "get_app_permissions",
+ "get_app_activities",
+ "get_app_info"
+]Input schema / properties / extrasAdded value: +{
+ "anyOf": [
+ {
+ "additionalProperties": {
+ "type": "string"
+ },
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Extras"
+}Input schema / properties / include_apk_pathAdded value: +{
+ "default": true,
+ "title": "Include Apk Path",
+ "type": "boolean"
+}Input schema / properties / include_app_nameAdded value: +{
+ "default": false,
+ "title": "Include App Name",
+ "type": "boolean"
+}Input schema / properties / max_packagesAdded value: +{
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": 200,
+ "title": "Max Packages"
+}Output schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "result": {
+ "title": "Result",
+ "type": "string"
+ }
+ },
+ "required": [
+ "result"
+ ],
+ "title": "app_operationsOutput",
+ "type": "object"
+}android-device1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "result": {
+ "title": "Result",
+ "type": "string"
+ }
+ },
+ "required": [
+ "result"
+ ],
+ "title": "android_deviceOutput",
+ "type": "object"
+}android-diag1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "result": {
+ "title": "Result",
+ "type": "string"
+ }
+ },
+ "required": [
+ "result"
+ ],
+ "title": "android_diagOutput",
+ "type": "object"
+}android-file1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "result": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "boolean"
+ }
+ ],
+ "title": "Result"
+ }
+ },
+ "required": [
+ "result"
+ ],
+ "title": "file_operationsOutput",
+ "type": "object"
+}android-log1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "result": {
+ "title": "Result",
+ "type": "string"
+ }
+ },
+ "required": [
+ "result"
+ ],
+ "title": "android_logOutput",
+ "type": "object"
+}android-shell1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "result": {
+ "title": "Result",
+ "type": "string"
+ }
+ },
+ "required": [
+ "result"
+ ],
+ "title": "shell_commandOutput",
+ "type": "object"
+}android-ui1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "result": {
+ "title": "Result",
+ "type": "string"
+ }
+ },
+ "required": [
+ "result"
+ ],
+ "title": "android_uiOutput",
+ "type": "object"
+}android-appandroid-deviceandroid-diagandroid-fileandroid-logandroid-screenshotandroid-shellandroid-uiThe top-level tools are clearly categorized, but the internal actions within each mega-tool can overlap (e.g., start_intent appears in both android-app and android-ui), causing potential ambiguity for an agent. Additionally, the bundling of many operations under one tool name makes it less obvious which tool handles a specific action.
All tool names follow a consistent 'android-<category>' pattern, and internal actions use a uniform snake_case style. The naming is predictable and readable across the entire server.
With 8 tools, the count is reasonable for an Android device management server. However, the bundling of many actions into each tool makes the surface feel slightly under-tooled, though still within the effective range.
The tool set covers major areas: app management, device control, diagnostics, file operations, logs, screenshots, shell, and UI. Some gaps exist (e.g., network or settings management), but the core workflows for common Android tasks are well addressed.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
MCP server for building and testing AI agents with multi-model experimentation and insights.
The Telnyx MCP server is an official implementation of the Model Context Protocol that enables AI clients (like Claude Desktop, Cursor, and OpenAI Agents) to interact with Telnyx's telephony, messaging, and AI assistant APIs. It provides comprehensive capabilities including making and managing phone calls, sending SMS/MMS messages, purchasing and configuring phone numbers, creating AI assistants with custom instructions, managing cloud storage buckets, scraping and embedding website content, and handling integration secrets. The server exists as both a local implementation and a remotely hosted version, allowing developers to integrate real-world communication infrastructure directly into AI applications.
Remote MCP server for AI.TV creators — delegate account operations to your AI agent over MCP.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/hyperb1iss/droidmind'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
