Controlar Android sin ADB es posible si el propio móvil expone las acciones que necesitas. He desarrollado Mi Android MCP, una app Android en Java nativo que permite leer la pantalla, hacer capturas e interactuar con otras aplicaciones mediante accesibilidad Android. El control viaja por una red privada Tailscale y puede conectarse a un modelo local de Ollama.
Lo he probado en un Moto g04 real con Android 14, controlando Reddit y otras apps a través de Tailscale, sin tocar ADB. En este artículo explico la arquitectura y la puesta en marcha del proyecto: una forma de automatizar Android sin USB, sin depuración por red y sin depender de proveedores de IA de pago.
Qué es MCP y qué aporta a la automatización Android
MCP significa Model Context Protocol. Es un protocolo que permite a una aplicación cliente descubrir y utilizar herramientas expuestas por un servidor. El modelo propone una acción; el software que lo conecta con el servidor se encarga de solicitar su ejecución. La documentación de arquitectura de MCP describe esta separación entre cliente, servidor y herramientas.
En mi proyecto, el servidor está dentro del teléfono. MCP da acceso a nueve herramientas concretas, como leer el estado de la pantalla o pulsar atrás. No es el modelo de IA ni sustituye los permisos de Android: la capacidad de actuar procede del servicio de accesibilidad que activa el usuario.
Por qué controlar Android sin ADB
ADB es una herramienta de desarrollo útil. El motivo para prescindir de ella aquí es operativo: quiero controlar el móvil desde el PC por una red privada, sin mantener una conexión de depuración.
Los flujos habituales con ADB, scrcpy o Appium tienen otros objetivos y requisitos. Para situar las diferencias, la documentación de ADB explica la depuración por USB y por red; scrcpy ofrece visualización y control; y el driver UiAutomator2 de Appium está orientado a automatización y pruebas.
| Aspecto | Enfoque habitual con ADB | Mi Android MCP |
|---|---|---|
| Vía de control | Conexión de depuración; puede servir de base a otras herramientas | Servicio de accesibilidad de Android |
| Conexión en este proyecto | No se utiliza | HTTP en la IP privada Tailscale del móvil, puerto 8765 |
| Preparación del teléfono | Configurar la depuración correspondiente | Instalar la app, activar accesibilidad y conectar Tailscale |
| Interfaz para automatizar | Depende de la herramienta elegida | Nueve herramientas MCP |
| Decisiones con IA | Es una integración adicional | Lanzador Python conectado a Ollama local |
No hace falta presentar ADB como una mala opción para elegir otra arquitectura. Aquí elimino esa dependencia porque las operaciones necesarias caben dentro del servicio de accesibilidad. Si necesitas el enfoque de pruebas, también he escrito una guía práctica de Appium para Android.
Arquitectura: del móvil al modelo local
La solución tiene cinco piezas con responsabilidades distintas:
- Teléfono Android: ejecuta las aplicaciones que quiero controlar.
- Accesibilidad Android: permite inspeccionar la interfaz y realizar las acciones disponibles.
- Mi Android MCP: app nativa con paquete
es.david.androidmcp; aloja el servidor MCP sobre HTTP en el puerto8765. - Red privada Tailscale: conecta el ordenador con la IP privada del teléfono.
- Android local: lanzador Python en el ordenador que conecta Ollama con el MCP del móvil.
Vista desde la lectura de pantalla, la cadena es móvil → accesibilidad → servidor MCP → Tailscale → lanzador Python → modelo local. Una acción recorre el camino de vuelta y termina en el servicio de accesibilidad.
Accesibilidad es la única vía de control
La app utiliza el servicio de accesibilidad para leer la pantalla, hacer capturas, tocar, deslizar, escribir, pulsar atrás o inicio y abrir apps. Android documenta estas capacidades y sus condiciones en la referencia de AccessibilityService.
Esto no equivale a tener acceso ilimitado al teléfono. La información de interfaz depende de lo que exponga cada app a accesibilidad, y Android puede restringir capturas de contenido protegido. Una pantalla difícil de interpretar sigue siendo un límite que la automatización debe gestionar.
MCP y Ollama son piezas separadas
El servidor Android ofrece herramientas; el modelo decide cuál conviene utilizar a partir del estado recibido. Puedo probar las herramientas desde un cliente MCP antes de introducir IA en el recorrido. Así distingo un problema de conexión de una decisión incorrecta del modelo.
Las nueve herramientas MCP disponibles
| Herramienta | Función |
|---|---|
android_get_screen_state | Lee el estado de pantalla disponible mediante accesibilidad. |
android_screenshot | Obtiene una captura de la pantalla. |
android_tap | Realiza un toque en pantalla. |
android_swipe | Ejecuta un deslizamiento. |
android_click_element | Pulsa un elemento de la interfaz identificado mediante accesibilidad. |
android_type_text | Escribe texto en la interfaz. |
android_back | Ejecuta la acción Atrás. |
android_home | Ejecuta la acción Inicio. |
android_open_app | Abre una aplicación. |
Esta tabla describe funciones, no un contrato de argumentos. Para construir llamadas, hay que usar el esquema que exponga cada herramienta en la versión instalada.
Este MCP no incorpora Appium, XPath, ADB ni enlaces profundos. Tampoco transfiere archivos ni genera códigos 2FA. Abrir una aplicación no significa poder saltar directamente a cualquier pantalla interna.
Seguridad: red privada, token Bearer y validación de origen
El servidor solo escucha en la IP privada de Tailscale. No queda escuchando en todas las interfaces del teléfono ni necesita un puerto público en el router. Tailscale proporciona conectividad privada y cifra el tráfico entre dispositivos, según su documentación de funcionamiento.
Además, el servidor exige un token de acceso Bearer y aplica validación de origen. Son controles complementarios: la red limita desde dónde se llega al servicio y el token autentica las peticiones. La validación de origen añade una comprobación, pero no sustituye al token ni a las restricciones de red.
HTTP describe el transporte del servidor; en este diseño, el tráfico entre ordenador y móvil viaja dentro de Tailscale. No hay que convertir esa dirección privada en un endpoint público para controlar el móvil a distancia.
El permiso de accesibilidad permite actuar sobre la interfaz. Conviene concederlo solo a la app que has decidido instalar y mantener el token fuera de capturas, repositorios y registros compartidos.
Puesta en marcha paso a paso
Esta guía presupone que dispones de la app y del lanzador del proyecto. Describe la configuración real; no presupone una descarga pública ni un instalador que no he documentado aquí.
1. Instalar Mi Android MCP en el teléfono
Instala el paquete es.david.androidmcp mediante el instalador de Android. Esta instalación y el control posterior no requieren ADB. La prueba descrita corresponde al Moto g04 con Android 14; no es una certificación de compatibilidad con todos los fabricantes y versiones.
2. Activar el servicio de accesibilidad
En los ajustes de accesibilidad del móvil, activa el servicio de Mi Android MCP. La ubicación y los avisos pueden variar según el dispositivo y el método de instalación. Comprueba que Android lo mantiene habilitado antes de intentar ejecutar acciones.
3. Conectar el móvil y el PC a Tailscale
Conecta ambos equipos a tu red privada y comprueba que la política de acceso permite al ordenador llegar al móvil. El servidor debe utilizar la IP Tailscale del teléfono y el puerto 8765, no la IP de su Wi-Fi ni una dirección pública.
4. Conectar el cliente MCP y comprobar las herramientas
Con el servidor en ejecución, configura el cliente con la dirección MCP del proyecto, el token Bearer y el origen admitido por el servidor. Utiliza la ruta HTTP y la configuración de la versión instalada: el puerto por sí solo no documenta la ruta del endpoint.
Primero comprueba que aparecen las nueve herramientas. Después solicita android_get_screen_state y prueba una acción sencilla, como android_home. Vuelve a leer el estado para confirmar el resultado antes de automatizar un flujo completo.
5. Preparar Ollama y Android local en el ordenador
Con Ollama instalado, puedes descargar el modelo del ejemplo:
ollama pull qwen3:4b
Configura el lanzador Python Android local para usar ese modelo y la conexión MCP del móvil. El modelo se ejecuta en el ordenador; el servidor de control está en el teléfono. La primera descarga necesita conectividad, y la velocidad de respuesta dependerá del hardware y del contexto.
No hace falta contratar una API de IA para este recorrido. Eso no elimina el consumo de recursos del equipo ni convierte en offline a Reddit u otras aplicaciones que necesitan Internet.
6. Comenzar con una tarea pequeña y verificable
Empieza por abrir una app, leer la pantalla y volver a inicio. Después añade un deslizamiento o escritura de texto. Revisa el estado tras cada acción: que una llamada termine no demuestra por sí solo que la interfaz haya alcanzado el objetivo.
Cómo automatizar el móvil con IA local
Android local sigue un ciclo: leer → decidir → ejecutar → verificar. Lee el estado, pide al modelo una decisión JSON estructurada, ejecuta la acción mediante MCP y vuelve a comprobar la pantalla. Incluye recuperación ante bloqueos y protección contra acciones repetidas.
Ollama permite restringir la forma de una respuesta con un esquema JSON, como explica su guía de salidas estructuradas. Una respuesta bien formada sigue pudiendo elegir una acción equivocada; por eso la verificación importa tanto como el formato.
Usar qwen3:4b en este ejemplo no implica atribuirle interpretación visual de capturas. La lectura del estado de accesibilidad y la herramienta de captura son capacidades distintas. Tampoco publico un JSON de llamada inventado: sus campos deben coincidir con los que acepte el lanzador.
La protección contra repeticiones importa cuando una pantalla no cambia. Si el modelo insiste en la misma acción, el sistema debe gestionar el bloqueo en vez de acumular toques. Esa recuperación no garantiza resolver cualquier interfaz o interrupción.
Ejemplo práctico: recorrer Reddit sin ADB
He probado el control de Reddit en el Moto g04 con Android 14 a través de Tailscale. Un recorrido sencillo para entender las herramientas sería el siguiente; es una secuencia ilustrativa, no un registro literal de una ejecución:
- Abrir Reddit con
android_open_app. - Consultar
android_get_screen_statepara saber qué pantalla está visible. - Identificar un control de navegación disponible y pulsarlo con
android_click_element. - Si el flujo incluye un campo de búsqueda, enfocarlo y utilizar
android_type_text. - Deslizar con
android_swipecuando haga falta y volver a leer la pantalla. - Consultar
android_screenshotsi se necesita una captura para revisar el estado. - Volver atrás con
android_backo terminar en inicio conandroid_home.
Los controles concretos dependen de la versión de Reddit y de la pantalla actual. La automatización debe observar ese estado en cada paso. La prueba demuestra el control de un dispositivo real en esa configuración; no aporta una tasa de éxito medida ni garantiza que cualquier flujo funcione sin intervención.
Qué comprobar antes de encargar un piloto Android
Primero comprobaría si la aplicación ofrece una API que cubra el proceso. Si existe, compararía esa integración con mantener un flujo que depende de pantallas. Este enfoque merece una prueba cuando el trabajo debe realizarse en la app y las acciones necesarias están disponibles por accesibilidad.
MCP tampoco obliga a que un modelo decida cada paso. Si el recorrido es estable, empezaría por una secuencia controlada y añadiría IA solo donde aporte una decisión útil. La guía de agentes frente a workflows desarrolla esa elección.
Antes de ampliar a más dispositivos, propondría estas pruebas sobre la combinación concreta de móvil, versión de Android, app y cliente MCP. Son criterios para un futuro encargo, no resultados medidos del proyecto:
| Prueba | Evidencia que pediría |
|---|---|
| Leer y actuar | El control necesario aparece en el estado y la pantalla posterior confirma el resultado. |
| Pantalla inesperada | Un diálogo, cierre de sesión o control ausente detiene el flujo y deja un motivo para revisión. |
| Conexión interrumpida | Al recuperar la red se comprueba el estado antes de repetir una acción de resultado incierto. |
| Permiso desactivado | La falta de accesibilidad se detecta y no se registra la tarea como completada. |
| Decisión del modelo | La acción propuesta respeta el alcance y un límite de intentos; el formato JSON por sí solo no basta. |
| Operación continuada | Se registra tiempo por tarea, intervención manual y fallos por causa con una muestra acordada. |
Para un ejemplo hipotético de consulta del estado de un pedido, el objetivo sería obtener el estado correcto y dejar evidencia. Abrir la app no bastaría. Si desaparece el pedido o caduca la sesión, el resultado debe quedar pendiente de revisión, no marcarse como resuelto.
Separaría tareas terminadas sin ayuda, recuperadas por una persona y fallidas. También acordaría quién mantiene el flujo cuando cambie la app. El caso SwimUpvote documenta colas y trazabilidad en otra plataforma; no acredita capacidad ni compatibilidad de este MCP con una flota.
Preguntas para decidir si encaja
¿MCP sustituye a Appium?
No son alternativas equivalentes: MCP expone herramientas y Appium automatiza aplicaciones. Incluso existe un servidor MCP del proyecto Appium. Mi implementación utiliza accesibilidad en el teléfono; no incorpora Appium. La elección depende del recorrido y de las pruebas que necesites.
¿Funciona en cualquier Android?
La prueba documentada es un Moto g04 con Android 14. Validaría cada combinación de dispositivo y app antes de incluirla en el alcance. Una interfaz accesible en una versión puede cambiar en la siguiente.
¿Necesito IA de pago o una descarga pública?
El recorrido descrito usa Ollama en el ordenador y no requiere una API de IA de pago. Sí necesita el equipo, la app y el lanzador del proyecto. Esta página no ofrece una descarga pública; la disponibilidad de esos componentes debe aclararse antes de preparar una implantación.
Del caso técnico al alcance de tu proceso
Este caso documenta herramientas MCP para un dispositivo Android. Si lo que necesitas es conectar un asistente con un CRM, ERP o sistema interno, la guía de desarrollo MCP a medida y pruebas de entrega explica cómo acotar ese otro proyecto. La implementación del móvil no demuestra compatibilidad con esos sistemas.
Para valorar un piloto, necesitaría conocer la app, los modelos de teléfono, el recorrido manual, las acciones permitidas y qué resultado aceptarías. El presupuesto debe separar validación inicial, implementación y mantenimiento; puedes usar la guía para comparar propuestas de software para revisar esas partidas.
Si quieres aplicar este enfoque a un proceso de tu negocio, consulta mis servicios de automatización e IA aplicada o cuéntame el recorrido que necesitas automatizar. Puedo revisar contigo si conviene una integración, un flujo por pantalla o una prueba acotada antes de ampliar el alcance.