Provides tools for controlling Android devices over ADB, including reading logcat, clearing logs, inspecting the current UI hierarchy, listing installed packages, and running safe allowlisted shell commands.
Android ADB MCP Server is a Model Context Protocol (MCP) server that lets AI assistants — such as Claude and OpenCode, or VS Code through its Copilot/agent integration — control Android devices over ADB securely. It exposes tools to read logcat, inspect the current UI hierarchy, list installed packages, and run restricted shell commands, all gated by an allowlist that mitigates arbitrary command execution.
A note on terminology: Claude and OpenCode are AI assistants. VS Code is not an AI — it is a code editor that hosts AI assistants (GitHub Copilot, and MCP-capable extensions) and is itself an MCP client. The server works with any MCP-capable client.
Node.js v18+ (tested up to Node.js 26).
ADB installed and reachable via the system PATH (adb version must work), or located via ADB_PATH / ANDROID_HOME / standard SDK paths.
USB debugging enabled on the Android device (Developer options → USB debugging).
git clone https://github.com/Neem2004/android-mcp-server.git
cd android-mcp-server
npm installnpm run buildThis produces the compiled code in the dist/ folder.
⚠️ Important:
dist/is generated locally and is not committed to the repository. You must runnpm run buildbefore configuring your MCP client, or the server will fail to start.
💡 Quick start (published on npm): you can skip the clone and build entirely — the server is published as
@neem2004/android-mcp-serverand includes the compileddist/. Run it directly withnpx -y @neem2004/android-mcp-server, as shown in the configs below. The absolute path form targets a local clone (replaceYOUR_PATH_TOwith its location).
Each MCP client keeps its servers in a different file, with a different format. Below are the three most common setups, each with the published-package form (npx) and the local-clone alternative.
File: opencode.json at your project root, or ~/.config/opencode/opencode.json (global).
{
"mcp": {
"android": {
"type": "local",
"command": ["npx", "-y", "@neem2004/android-mcp-server"],
"enabled": true
}
}
}Local clone alternative — "command": ["node", "YOUR_PATH_TO/android-mcp-server/dist/index.js"].
File: %APPDATA%\Claude\claude_desktop_config.json (Windows) or ~/Library/Application Support/Claude/claude_desktop_config.json (macOS).
{
"mcpServers": {
"android": {
"command": "npx",
"args": ["-y", "@neem2004/android-mcp-server"]
}
}
}Local clone alternative — "command": "node" with "args": ["YOUR_PATH_TO/android-mcp-server/dist/index.js"].
File: .vscode/mcp.json in your workspace (or via the MCP: Open User Configuration command). VS Code uses servers as the top-level key (not mcpServers).
{
"servers": {
"android": {
"type": "stdio",
"command": "npx",
"args": ["-y", "@neem2004/android-mcp-server"]
}
}
}Local clone alternative — "command": "node" with "args": ["YOUR_PATH_TO/android-mcp-server/dist/index.js"].
Development note: instead of the compiled build you can run TypeScript directly via
tsxby replacing the argument withsrc/index.tsand usingnpx tsxas the command. Prefer the compiled build for reliability.
npm test # runs the unit test suite
npm run build # compiles TypeScript to dist/
npm run dev # runs the server directly via tsx (development)Tool | Description | Arguments |
| Dumps the |
|
| Clears the device log buffer | — |
| Returns the current UI hierarchy (XML/text) | — |
| Lists installed packages |
|
| Runs a safe allowlisted shell command |
|
This server prioritizes safety over arbitrary command execution:
Shell allowlist: adb_execute_shell only accepts commands whose prefix is authorized (getprop, dumpsys, pm list). Anything else is rejected with a descriptive error. Command chaining (&&, ||, ;, |) and injection metacharacters are also blocked.
No root: no superuser privileges are requested; it works on standard ADB APIs.
Commands run via execFile (no intermediate shell), avoiding metacharacter injection.
The logic lives in
src/adb/security.ts; review it before broadening permissions.
If you do not have ADB yet:
Windows: download the official platform-tools and add its folder to your system PATH.
macOS / Linux: install via your package manager (e.g. brew install android-platform-tools, apt install adb).
Verify with:
adb devicesYour device should appear as device (not unauthorized/offline). The server will use ADB_PATH, then ANDROID_HOME/ANDROID_SDK_ROOT, then standard SDK locations, before falling back to adb on the PATH.
This project is 100% open source and independently maintained. If Android ADB MCP Server saves your team time or improves your automation workflows, please consider supporting its continued development.
🔗 GitHub Sponsors: Sponsor Neem2004
💼 Companies: corporate sponsorship funds new tools, security hardening, and priority support.
Every contribution, however small, helps keep the project active, documented, and secure. Thank you for your support!
ISC
Related MCP server: mobile-debug-mcp
Android ADB MCP Server es un servidor del Model Context Protocol (MCP) que permite a asistentes de IA —como Claude y OpenCode, o VS Code mediante su integración con Copilot/agente— controlar dispositivos Android vía ADB de forma segura. Expone herramientas para leer el logcat, inspeccionar la jerarquía de la UI, listar paquetes instalados y ejecutar comandos shell restringidos, todo a través de una lista blanca que mitiga los riesgos de ejecución arbitraria.
Nota sobre terminología: Claude y OpenCode son asistentes de IA. VS Code no es una IA — es un editor de código que aloja asistentes de IA (GitHub Copilot y extensiones con soporte MCP) y que además es un cliente MCP. El servidor funciona con cualquier cliente compatible con MCP.
Node.js v18+ (probado hasta Node.js 26).
ADB instalado y accesible en el PATH del sistema (adb version debe funcionar), o localizado vía ADB_PATH / ANDROID_HOME / rutas estándar del SDK.
Depuración USB activada en el dispositivo Android (Opciones de desarrollador → Depuración USB).
git clone https://github.com/Neem2004/android-mcp-server.git
cd android-mcp-server
npm installnpm run buildEsto genera el código compilado en la carpeta dist/.
⚠️ Importante:
dist/se genera localmente y no se sube al repositorio. Debes ejecutarnpm run buildantes de configurar tu cliente MCP, o el servidor no arrancará.
💡 Inicio rápido (publicado en npm): puedes saltarte el clonado y la compilación — el servidor está publicado como
@neem2004/android-mcp-servere incluye eldist/compilado. Ejecútalo directamente connpx -y @neem2004/android-mcp-server, como muestran las configuraciones de abajo. La forma de ruta absoluta apunta a un clon local (reemplazaTU_RUTApor su ubicación).
Cada cliente MCP guarda sus servidores en un archivo distinto, con un formato propio. A continuación están las tres configuraciones más comunes, cada una con la forma de paquete publicado (npx) y la alternativa de clon local.
Archivo: opencode.json en la raíz de tu proyecto, o ~/.config/opencode/opencode.json (global).
{
"mcp": {
"android": {
"type": "local",
"command": ["npx", "-y", "@neem2004/android-mcp-server"],
"enabled": true
}
}
}Alternativa de clon local — "command": ["node", "TU_RUTA/android-mcp-server/dist/index.js"].
Archivo: %APPDATA%\Claude\claude_desktop_config.json (Windows) o ~/Library/Application Support/Claude/claude_desktop_config.json (macOS).
{
"mcpServers": {
"android": {
"command": "npx",
"args": ["-y", "@neem2004/android-mcp-server"]
}
}
}Alternativa de clon local — "command": "node" con "args": ["TU_RUTA/android-mcp-server/dist/index.js"].
Archivo: .vscode/mcp.json en tu workspace (o mediante el comando MCP: Open User Configuration). VS Code usa servers como clave raíz (no mcpServers).
{
"servers": {
"android": {
"type": "stdio",
"command": "npx",
"args": ["-y", "@neem2004/android-mcp-server"]
}
}
}Alternativa de clon local — "command": "node" con "args": ["TU_RUTA/android-mcp-server/dist/index.js"].
Nota de desarrollo: en lugar del build compilado puedes ejecutar TypeScript directamente con
tsxreemplazando el argumento porsrc/index.tsy usandonpx tsxcomo comando. Para máxima fiabilidad, prefiere el build compilado.
npm test # ejecuta la suite de tests unitarios
npm run build # compila TypeScript a dist/
npm run dev # ejecuta el servidor directamente con tsx (desarrollo)Tool | Descripción | Argumentos |
| Vuelca el buffer de |
|
| Limpia el buffer de logs del dispositivo | — |
| Devuelve la jerarquía de la UI actual (XML/texto) | — |
| Lista los paquetes instalados |
|
| Ejecuta un comando shell seguro (lista blanca) |
|
Este servidor prioriza la seguridad frente a la ejecución arbitraria de comandos:
Lista blanca de comandos shell: adb_execute_shell solo acepta comandos cuyo prefijo esté autorizado (getprop, dumpsys, pm list). Cualquier otra cosa se rechaza con un error descriptivo. También se bloquean encadenamientos (&&, ||, ;, |) y metacaracteres de inyección.
Sin root: no se solicitan privilegios de superusuario; se trabaja sobre las APIs estándar de ADB.
Los comandos se ejecutan mediante execFile (sin pasar por un shell intermedio), evitando la inyección de metacaracteres.
La lógica vive en
src/adb/security.ts; revísalo antes de ampliar los permisos.
Si aún no tienes ADB:
Windows: descarga los platform-tools oficiales y agrega su carpeta al PATH del sistema.
macOS / Linux: instala con tu gestor de paquetes (p. ej. brew install android-platform-tools, apt install adb).
Verifica con:
adb devicesTu dispositivo debe aparecer como device (no unauthorized/offline). El servidor usará ADB_PATH, luego ANDROID_HOME/ANDROID_SDK_ROOT, luego rutas estándar del SDK, antes de caer a adb en el PATH.
Este proyecto es 100% open source y se mantiene de forma independiente. Si Android ADB MCP Server ahorra tiempo a tu equipo o mejora tus flujos de automatización, considera apoyar su desarrollo continuo.
🔗 GitHub Sponsors: Patrocina a Neem2004
💼 Empresas: el patrocinio corporativo financia nuevas herramientas, mejoras de seguridad y soporte prioritario.
Toda contribución, por pequeña que sea, ayuda a mantener el proyecto activo, documentado y seguro. ¡Gracias por tu apoyo!
ISC
Permanently clears the device logcat buffer (logcat -c) and returns a confirmation message. All buffered log entries are lost; subsequent dumps start fresh. Run it before capturing a clean log stream. / Limpia permanentemente el buffer de logcat del dispositivo (logcat -c) y devuelve un mensaje de confirmación. Se pierden todas las entradas en buffer; los dumps posteriores empiezan desde cero. Ejecútalo antes de capturar un stream de logs limpio.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it declares the operation is permanent, that all buffered entries are lost, that future dumps start from zero, and that the return value is a confirmation message. It does not cover failure modes (no device connected, permission errors), so it falls just short of full disclosure.
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 English text is front-loaded and tight, but the entire description is duplicated in Spanish, so roughly half the content is redundant for any single-language agent. The core content earns its place; the verbatim translation does not.
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 zero-parameter, no-annotation, no-output-schema tool, the description covers purpose, destructive impact, ordering guidance, and the response shape. Only edge-case behavior (what happens on a disconnected device) is unaddressed, which is a minor gap given the tool's simplicity.
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 tool takes zero parameters, so the baseline is 4. There is nothing for the description to compensate for, and it correctly adds no parameter detail.
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?
States a specific verb and resource ('Permanently clears the device logcat buffer'), names the underlying command (logcat -c), and implies its counterpart by contrasting with 'subsequent dumps start fresh'. An agent can distinguish this from the sibling adb_get_logcat without opening any schema.
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?
'Run it before capturing a clean log stream' gives an explicit when-to-use condition that implicitly routes the agent to adb_get_logcat afterwards. It stops short of naming the sibling tool or stating when not to call it, but the sequencing guidance is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the current UI hierarchy of the Android device as XML/text via uiautomator. Tries /dev/tty first and falls back to /sdcard/window_dump.xml. May return empty when no window is focused. Useful to understand the visible layout. / Devuelve la jerarquía de la UI actual del dispositivo como texto/XML vía uiautomator. Prueba /dev/tty primero y cae a /sdcard/window_dump.xml como respaldo. Puede devolver vacío cuando no hay ventana enfocada. Útil para entender el layout visible.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does meaningful work: it discloses the internal fallback chain (/dev/tty first, then /sdcard/window_dump.xml) and a real failure mode (may return empty when no window is focused). It does not state permissions or whether the device/ADB must be connected, which keeps it short of 5.
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 content is front-loaded and the English sentence is efficient, but the entire description is duplicated verbatim in Spanish, roughly doubling the token cost with zero added information for an agent that reads either language. No other waste is present.
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?
There is no output schema, so the description must cover the return value, and it does: XML/text, with the caveat that an empty result means no focused window. For a zero-parameter, read-only inspection tool with a fallback path already described, this is essentially complete; only connection/permission prerequisites are unstated.
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 tool takes zero parameters, so there are no parameter semantics to explain and the baseline is 4. The description correctly does not invent parameters or claim configurable options that the empty schema does not support.
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?
States a specific verb and resource: returns the current UI hierarchy of the Android device as XML/text via uiautomator. An agent can tell this apart from the logcat/package/shell siblings without opening a schema. It does not explicitly name those siblings or contrast with them, which keeps it at 4 rather than 5.
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?
"Useful to understand the visible layout" gives implied usage context, so the agent knows this is a layout-inspection tool. However there is no explicit when-to-use vs. when-not guidance and no alternative named (e.g., adb_execute_shell running uiautomator directly), leaving the selection decision to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Runs a read-only shell command on the Android device, restricted to an allowlist of safe prefixes: getprop (read system properties), dumpsys (dump services) and pm list (list packages). Anything else — including command chaining (&&, ||, ;, |) and injection metacharacters — is rejected with a descriptive error. / Ejecuta un comando shell de solo lectura en el dispositivo Android, restringido a la lista blanca de prefijos seguros: getprop (propiedades del sistema), dumpsys (volcado de servicios) y pm list (listado de paquetes). Cualquier otra cosa —incluidos encadenamientos (&&, ||, ;, |) y metacaracteres de inyección— se rechaza con un error descriptivo.
| Name | Required | Description | Default |
|---|---|---|---|
| command | Yes | Shell command to execute. Must start with one of the allowlisted prefixes: getprop, dumpsys or pm list. / Comando shell a ejecutar. Debe comenzar con uno de los prefijos permitidos: getprop, dumpsys o pm list. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it declares the operation is read-only, lists the exact permitted prefixes, and explicitly states that chaining operators and injection metacharacters are rejected with a descriptive error. It omits return-value/pagination shape, so it stops short of a 5.
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?
Each language block is front-loaded and free of wasted words, leading with the read-only constraint before the rejection rules. The full English/Spanish duplication roughly doubles the length, which is a minor conciseness cost.
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 single-parameter read-only tool with no output schema or annotations, the description covers safety profile, scope, and error behavior adequately. It does not describe what a successful command returns, but that gap is small given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the pattern itself already enforces the allowlist, so the schema does the heavy lifting. The description's allowlist restatement and the schema examples add no meaning beyond what the structured field already conveys, keeping this at the baseline.
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?
States a specific verb and resource ('Runs a read-only shell command on the Android device') and enumerates the exact allowlisted prefixes (getprop, dumpsys, pm list), which lets an agent distinguish it from siblings like adb_get_logcat or adb_dump_hierarchy.
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 sharply delimits what is in scope (allowlisted prefixes) and what is rejected, which is useful context. However, it never names an alternative sibling or states conditions for choosing this tool over adb_list_packages, whose 'pm list' functionality overlaps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Dumps and exits the Android logcat buffer (logcat -d; not a stream), returning newline-separated lines with blank lines removed. Optionally filters by tag, minimum log level and the last N lines. Use filter_tag alone for 'tag:'; log_level only takes effect together with filter_tag. / Vuelca y cierra el buffer de logcat del dispositivo (logcat -d; no es un stream), devolviendo líneas separadas por saltos de línea y omitiendo las vacías. Filtra opcionalmente por tag, nivel mínimo de log y las últimas N líneas. filter_tag solo produce 'tag:'; log_level solo tiene efecto junto con filter_tag.
| Name | Required | Description | Default |
|---|---|---|---|
| lines | No | Number of last lines to return (defaults to the full buffer). / Número de últimas líneas a retornar (por defecto, el buffer completo). | |
| log_level | No | Minimum log level to include (V=verbose … F=fatal). Requires filter_tag to take effect; ignored otherwise. / Nivel mínimo de log a incluir (V=verbose … F=fatal). Requiere filter_tag para tener efecto; se ignora si no va. | |
| filter_tag | No | Only include entries whose tag matches this log tag (e.g. MyApp). / Incluye solo entradas cuyo tag coincida (p. ej. MyApp). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden and does well: it discloses that the command exits rather than streams, returns newline-separated lines with blanks removed, defaults to the full buffer, and notes the log_level/filter_tag dependency. It omits auth/device-connection prerequisites, keeping it short of a 5.
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 core behavior is front-loaded and the sentences are tight in English. The fully duplicated Spanish translation doubles the length, which is redundant for an agent but not wasteful in content.
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?
With no output schema and no annotations, the description must explain return format, and it does (newline-separated lines, blanks removed, full-buffer default). Combined with 100% schema coverage and simple flat parameters, this is nearly complete, missing only device/permission context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description restates the cross-parameter rule (log_level requires filter_tag) and default behavior (full buffer), which the schema already documents, adding little net new meaning.
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?
States a specific verb (dumps) and resource (Android logcat buffer) and clarifies the mechanism (logcat -d; not a stream). This cleanly distinguishes it from sibling adb_clear_logcat and from streaming tools, so an agent can differentiate without opening a schema.
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?
Explains how to use the filters ('Use filter_tag alone for tag:*'; log_level only with filter_tag), which is usage context, but never states when to choose this over siblings like adb_execute_shell or adb_clear_logcat. Usage is implied rather than routed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists the packages installed on the Android device as one 'package:' line each (third-party only by default). Optionally filters by a case-insensitive name substring and includes system packages. / Lista los paquetes instalados del dispositivo con una línea 'package:' por cada uno (solo de terceros por defecto). Filtra opcionalmente por subcadena del nombre sin distinguir mayúsculas e incluye paquetes de sistema.
| Name | Required | Description | Default |
|---|---|---|---|
| filter | No | Only list packages whose name contains this text (case-insensitive). / Lista solo paquetes cuyo nombre contenga este texto (sin distinguir mayúsculas). | |
| include_system | No | If true, include system packages; if false or omitted, only third-party packages are listed. / Si es true, incluye paquetes de sistema; si es false u omitido, solo lista paquetes de terceros. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose the key behavioral facts: the default filter to third-party packages, the per-package line format, and case-insensitive matching. It stops short of stating the device-connection precondition or what happens when no device is attached, which are the main remaining unknowns for this kind of ADB tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The content is front-loaded and each clause is useful, but the description is given twice (English and Spanish), doubling the token footprint without adding information for an agent. The bilingual duplication is defensible for localization yet pure redundancy from a selection standpoint.
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 two-optional-parameter read tool with no output schema, the description covers the operation, defaults, filtering, and exact return line shape, which is most of what an agent needs. Only the environmental precondition (a connected/unlocked device) and failure behavior are absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: both 'filter' and 'include_system' are fully documented with defaults, examples, and case-sensitivity semantics in the schema itself. The description restates that same information rather than adding syntax, edge cases, or interaction rules, so the baseline 3 applies.
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 a specific verb and resource ('Lists the packages installed on the Android device') and even specifies the exact output line format ('package:<name>' one per line). It is the only listing/packages tool among the siblings, so an agent can place it immediately against adb_get_logcat, adb_dump_hierarchy, and adb_execute_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?
It clearly states the default scope (third-party only) and the two ways to narrow or widen results (case-insensitive substring filter, include_system). It does not, however, say when an alternative should be preferred — e.g., that adb_execute_shell is the route for other package operations — so the guidance is contextual rather than exclusive.
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.2adb_execute_shell1 field changedInput schema / properties / command / titleAdded value: +"command"adb_get_logcat5 fields changedInput schema / properties / filter_tag / titleAdded value: +"filter_tag"Input schema / properties / lines / maximumAdded value: +1000Input schema / properties / lines / titleAdded value: +"lines"Input schema / properties / log_level / descriptionPrevious value: -"Minimum log level to include (V=verbose … F=fatal). Requires filter_tag to take effect. / Nivel mínimo de log a incluir (V=verbose … F=fatal). Requiere filter_tag para tener efecto."New value: +"Minimum log level to include (V=verbose … F=fatal). Requires filter_tag to take effect; ignored otherwise. / Nivel mínimo de log a incluir (V=verbose … F=fatal). Requiere filter_tag para tener efecto; se ignora si no va."Input schema / properties / log_level / titleAdded value: +"log_level"adb_list_packages2 fields changedInput schema / properties / filter / titleAdded value: +"filter"Input schema / properties / include_system / titleAdded value: +"include_system"v1.0.1adb_execute_shell3 fields changedInput schema / properties / command / descriptionPrevious value: -"Comando shell a ejecutar (solo comandos permitidos)."New value: +"Shell command to execute. Must start with one of the allowlisted prefixes: getprop, dumpsys or pm list. / Comando shell a ejecutar. Debe comenzar con uno de los prefijos permitidos: getprop, dumpsys o pm list."Input schema / properties / command / examplesAdded value: +[
+ "getprop ro.build.version.release",
+ "dumpsys battery",
+ "pm list packages -3"
+]Input schema / properties / command / patternAdded value: +"^(getprop|dumpsys|pm list)(\\s|$)"adb_get_logcat8 fields changedInput schema / properties / filter_tag / descriptionPrevious value: -"Filtra entradas por tag (etiqueta de log)."New value: +"Only include entries whose tag matches this log tag (e.g. MyApp). / Incluye solo entradas cuyo tag coincida (p. ej. MyApp)."Input schema / properties / filter_tag / examplesAdded value: +[
+ "MyApp",
+ "ActivityManager"
+]Input schema / properties / lines / defaultAdded value: +200Input schema / properties / lines / descriptionPrevious value: -"Número de últimas líneas a retornar."New value: +"Number of last lines to return (defaults to the full buffer). / Número de últimas líneas a retornar (por defecto, el buffer completo)."Input schema / properties / lines / examplesAdded value: +[
+ 200,
+ 1000
+]Input schema / properties / lines / minimumAdded value: +1Input schema / properties / log_level / descriptionPrevious value: -"Nivel mínimo de log a incluir."New value: +"Minimum log level to include (V=verbose … F=fatal). Requires filter_tag to take effect. / Nivel mínimo de log a incluir (V=verbose … F=fatal). Requiere filter_tag para tener efecto."Input schema / properties / log_level / examplesAdded value: +[
+ "D",
+ "E"
+]adb_list_packages5 fields changedInput schema / properties / filter / descriptionPrevious value: -"Filtra los paquetes por texto en el nombre."New value: +"Only list packages whose name contains this text (case-insensitive). / Lista solo paquetes cuyo nombre contenga este texto (sin distinguir mayúsculas)."Input schema / properties / filter / examplesAdded value: +[
+ "com.example",
+ "google"
+]Input schema / properties / include_system / defaultAdded value: +falseInput schema / properties / include_system / descriptionPrevious value: -"Si es true, incluye paquetes de sistema (sin -3)."New value: +"If true, include system packages; if false or omitted, only third-party packages are listed. / Si es true, incluye paquetes de sistema; si es false u omitido, solo lista paquetes de terceros."Input schema / properties / include_system / examplesAdded value: +[
+ true,
+ false
+]v1.0.0adb_clear_logcatadb_dump_hierarchyadb_execute_shelladb_get_logcatadb_list_packagesScored across 5 tools
Tools mostly target distinct actions/resources, but adb_execute_shell's allowlist includes 'pm list', which overlaps with adb_list_packages, creating a minor risk of misselection. The descriptions do clarify the specialized tools, so boundaries are largely clear.
All tools use the adb_ prefix followed by a verb_noun pattern (get_logcat, clear_logcat, dump_hierarchy, list_packages, execute_shell), showing consistent naming throughout.
Five tools is well-scoped for a read-only ADB diagnostic server; each tool has a clear purpose and no bloat.
The server covers logcat capture/clearing, UI hierarchy, package listing, and a restricted shell for getprop/dumpsys/pm list, but lacks operations like screenshot or direct UI interaction. For a read-only diagnostic scope, coverage is mostly complete with minor gaps.
Remote MCP for Android CLI agent build gate, structured receipts, audit logs, and reviewer-ready evi
MCP server for static security analysis of Android source code
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.
