Controlar dispositivos Android con IA a través del Protocolo de Contexto de Modelo
DroidMind es un potente puente entre los asistentes de IA y los dispositivos Android, que permite el control, la depuración y el análisis de sistemas mediante lenguaje natural. Al implementar el Protocolo de Contexto de Modelo (MCP), DroidMind permite que los modelos de IA interactúen directamente con los dispositivos Android a través de ADB de forma segura y estructurada. Al utilizarse como parte de un flujo de trabajo de codificación con agentes, DroidMind permite que el asistente compile y depure con el dispositivo directamente en el bucle.
📱 Control de dispositivos : conéctese a dispositivos a través de USB o TCP/IP, ejecute comandos de shell, reinicie
📊 Análisis del sistema : inspeccione las propiedades del dispositivo, vea información del hardware, analice los registros del sistema
🔍 Acceso al sistema de archivos : explore el contenido del directorio y administre archivos en los dispositivos
📷 Diagnóstico visual : captura de pantalla del dispositivo para análisis y depuración
📦 Administración de aplicaciones : instalar, desinstalar, iniciar, detener y borrar datos de aplicaciones en dispositivos conectados
🔄 Compatibilidad con múltiples dispositivos : controle y cambie entre múltiples dispositivos conectados
👆 Automatización de la interfaz de usuario : interactúe con el dispositivo mediante toques, deslizamientos, ingreso de texto y pulsaciones de teclas.
🔍 Inspección de aplicaciones : vea manifiestos de aplicaciones, preferencias compartidas y registros específicos de la aplicación
🔒 Marco de seguridad : proteja los dispositivos con una validación de comandos integral
💬 Integración con MCP : conexión perfecta con Claude, Cursor, Cline y más
Related MCP server: MCP Android Agent
# Clone the repository
git clone https://github.com/hyperbliss/droidmind.git
cd droidmind
# Set up a virtual environment with UV
uv venv .venv
source .venv/bin/activate # On Windows: .venv\Scripts\activate
# Install dependencies with UV
uv syncPython 3.13 o superior
Dispositivo Android con depuración USB habilitada
ADB (Android Debug Bridge) instalado y en PATH
Gestor de paquetes UV (recomendado para la gestión de dependencias)
Para control de red: dispositivo Android con ADB sobre TCP/IP habilitado
Ejecute DroidMind como servidor para conectar asistentes de IA a través de MCP:
# Start DroidMind as a network server
droidmind --transport sseInicie DroidMind en modo SSE:
droidmind --transport sseConecte su asistente de IA utilizando la URI del protocolo MCP:
sse://localhost:4256/sse¡La IA ahora puede controlar tus dispositivos Android a través del lenguaje natural!
devices://list - Lista todos los dispositivos conectados
device://{serial}/properties - Obtener propiedades detalladas del dispositivo
logs://{serial}/logcat - Obtener registros recientes del dispositivo
logs://{serial}/anr - Obtener rastros de aplicaciones que no responden (ANR)
logs://{serial}/crashes - Obtener registros de fallos de la aplicación
logs://{serial}/battery - Obtener estadísticas e historial de la batería
logs://{serial}/app/{package} - Obtener registros específicos de la aplicación
fs://{serial}/list/{path} - Lista el contenido del directorio en el dispositivo
fs://{serial}/read/{path} - Leer el contenido del archivo desde el dispositivo
fs://{serial}/stats/{path} - Obtener estadísticas detalladas de archivos/directorios
app://{serial}/{package}/manifest - Obtener el contenido de AndroidManifest.xml
app://{serial}/{package}/data - Lista los archivos en el directorio de datos de la aplicación
app://{serial}/{package}/shared_prefs - Obtener las preferencias compartidas de la aplicación
devicelist - Lista todos los dispositivos Android conectados
device_properties : obtiene las propiedades detalladas de un dispositivo específico
device_logcat : obtiene la salida reciente de logcat de un dispositivo
list_directory - Lista el contenido de un directorio en el dispositivo
connect_device - Conectarse a un dispositivo a través de TCP/IP
disconnect_device - Desconectarse de un dispositivo Android
shell_command - Ejecuta un comando de shell en el dispositivo
install_app - Instalar un APK en el dispositivo
uninstall_app - Desinstalar una aplicación del dispositivo
start_app - Iniciar una aplicación en el dispositivo
stop_app - Fuerza la detención de una aplicación en el dispositivo
clear_app_data - Borrar datos y caché de la aplicación
list_packages - Lista los paquetes instalados en el dispositivo
get_app_manifest : obtiene el contenido de AndroidManifest.xml para una aplicación
get_app_permissions - Obtener los permisos solicitados por una aplicación
get_app_activities - Obtener actividades definidas en una aplicación
get_app_info - Obtener información detallada sobre una aplicación
reboot_device - Reinicia el dispositivo (normal, recuperación o cargador de arranque)
screenshot - Obtener una captura de pantalla de un dispositivo
capture_bugreport : genera un informe de errores completo del dispositivo
dump_heap - Crea un volcado de montón desde un proceso en ejecución para el análisis de memoria
push_file - Sube un archivo al dispositivo
pull_file - Descargar un archivo desde el dispositivo
delete_file - Elimina un archivo o directorio del dispositivo
create_directory - Crea un directorio en el dispositivo
file_exists - Comprueba si existe un archivo en el dispositivo
read_file - Lee el contenido de un archivo en el dispositivo
write_file - Escribe contenido de texto en un archivo en el dispositivo
file_stats - Obtener información detallada sobre un archivo o directorio
tap - Toca la pantalla del dispositivo en coordenadas específicas
swipe - Realizar un gesto de deslizar de un punto a otro en la pantalla
input_text - Ingrese texto en el dispositivo como si fuera un teclado
press_key - Presiona una tecla de hardware o software (por ejemplo, INICIO, ATRÁS, VOLUMEN)
start_intent - Iniciar una actividad de la aplicación usando una intención de Android
Con un asistente de IA conectado a DroidMind, prueba estas consultas:
"Enumera todos los dispositivos Android conectados y muéstrame sus propiedades"
"Conéctate a mi teléfono en 192.168.1.100 y comprueba el estado de la batería"
"Toma una captura de pantalla de mi Pixel y muéstrame qué hay en pantalla actualmente"
"Comprobar el espacio de almacenamiento disponible en mi dispositivo"
"Muéstrame los rastros de ANR y los registros de fallos de mi dispositivo"
"Mira los registros recientes y dime si hay algún error"
"Instala este archivo APK en mi dispositivo y dime si se instaló correctamente"
"Muéstrame una lista de todas las aplicaciones instaladas en mi teléfono"
"Reiniciar mi dispositivo en modo de recuperación"
"¿Qué versión de Android tiene mi teléfono?"
"Comprueba si mi dispositivo está rooteado e indícame su nivel de parche de seguridad"
"Muéstrame el archivo de manifiesto de com.android.settings"
"Comprueba las preferencias compartidas de mi aplicación"
Pulsa el icono de Configuración en las coordenadas 500,1000.
Desliza el dedo hacia abajo desde la parte superior de la pantalla para abrir la barra de notificaciones.
"Ingrese mi contraseña en el campo de texto actual"
"Presione el botón Atrás tres veces para volver a la pantalla de inicio"
"Abre la aplicación Configuración iniciando el paquete com.android.settings"
DroidMind incluye un marco de seguridad integral para proteger sus dispositivos y al mismo tiempo permitir que los asistentes de IA sean expresivos:
Validación de comandos : todos los comandos de shell se validan con una lista de comandos seguros permitidos
Evaluación de riesgos : los comandos se clasifican por nivel de riesgo (SEGURO, BAJO, MEDIO, ALTO, CRÍTICO)
Sanitización de comandos : la entrada se desinfecta para evitar ataques de inyección de comandos
Rutas protegidas : los directorios del sistema y las rutas críticas están protegidos contra modificaciones
Registro completo : todos los comandos se registran con su nivel de riesgo para auditoría.
Detección de patrones sospechosos : se bloquean los comandos con patrones potencialmente peligrosos
Seguridad de comandos ADB : manejo especial para comandos específicos de ADB con validación asíncrona adecuada
El sistema de seguridad está diseñado para ser lo suficientemente permisivo como para permitir operaciones comunes y, al mismo tiempo, prevenir acciones destructivas. Los comandos de alto riesgo mostrarán advertencias a los usuarios antes de su ejecución, y las operaciones críticas se bloquearán por completo sin necesidad de una anulación explícita.
DroidMind utiliza UV para la gestión de dependencias y los flujos de trabajo de desarrollo. UV es un gestor y solucionador de paquetes de Python rápido y fiable.
# Update dependencies
uv sync
# Run tests
pytest
# Run linting
ruff check .
# Run type checking
mypy .¡Agradecemos sus contribuciones! No dude en enviar una solicitud de incorporación de cambios.
Bifurcar el repositorio
Crea tu rama de funciones ( git checkout -b feature/amazing-feature )
Configura tu entorno de desarrollo con UV
Realiza tus cambios
Ejecutar pruebas y linting
Confirme sus cambios ( git commit -m 'Add some amazing feature' )
Empujar a la rama ( git push origin feature/amazing-feature )
Abrir una solicitud de extracción
Este proyecto está licenciado bajo la licencia Apache: consulte el archivo de LICENCIA para obtener más detalles.
Creado por Stefanie Jane 🌠
Si te resulta útil DroidMind, cómprame un 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.
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-uiScored across 8 tools
The 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.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Melaya is a remote MCP server. It gives an assistant hands on your own Android phone and browser: it reads the screen through the accessibility tree, then taps, types and navigates inside the apps and sites you allow-list, with no per-app API. It also builds, schedules and runs agent pipelines across 6k+ connected tools. OAuth 2.1, nothing to install.
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.
