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
Clears the device logcat buffer and returns a confirmation message. Use it before capturing a clean log stream. / Limpia el buffer de logcat del dispositivo y devuelve un mensaje de confirmación. Útil 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 provided, the description carries the full behavioral burden. It clearly discloses that the device logcat buffer is cleared and that a confirmation message is returned. The destructive effect is implied by the word 'clears,' which is transparent enough for this simple operation.
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 action is front-loaded and the text is short. The bilingual duplication adds some redundancy for an AI agent, but it remains compact and does not obscure the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, the description is complete: it states what the tool does, what it returns, and when to use it. No critical information is missing.
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 has zero parameters, so the description is not required to explain parameter meanings. The schema coverage is effectively 100%, and the description adds no unnecessary parameter noise.
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 action ('Clears the device logcat buffer') and its result ('returns a confirmation message'). This clearly distinguishes it from sibling tools like adb_get_logcat, which captures logs rather than clearing them.
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 explicitly says to use the tool 'before capturing a clean log stream,' giving clear contextual guidance. It does not explicitly name alternatives, but for a simple zero-parameter clear operation, this level of guidance is sufficient.
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. Useful for UI automation and understanding the visible layout. / Devuelve la jerarquía de la UI actual del dispositivo Android como texto/XML vía uiautomator. Útil para automatización de UI y entender el layout visible.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does reveal the output format (XML/text), the mechanism (uiautomator), and that it captures the 'current' hierarchy. However, it omits any caveats about device connectivity, potential latency, or the tool being a read-only snapshot, which would further help an agent set expectations.
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 portion is concise and front-loaded with the primary function. However, the entire description is duplicated in Spanish, adding no new information. This redundancy means not every sentence earns its place, reducing overall 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?
This is a parameterless, read-only introspection tool with no output schema. The description explains what it returns and why it is useful, which is adequate for an agent to select and invoke it. Missing details like output size or formatting nuances are minor given the low complexity and lack of required parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters and 100% schema description coverage, so there are no parameter semantics to clarify. With no parameters, the baseline is 4, and the description correctly says nothing about parameters.
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: 'Returns the current UI hierarchy of the Android device as XML/text via uiautomator.' This clearly distinguishes it from sibling tools that deal with logcat, packages, and shell execution. Even with bilingual repetition, the English portion alone is unambiguous and complete.
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 explicitly provides a use case: 'Useful for UI automation and understanding the visible layout.' It does not list alternatives or exclusions, but none of the sibling tools overlap in function, so the context is clear and sufficient for an agent to decide when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Runs a safe shell command on the Android device, restricted to an allowlist of read-only prefixes (getprop, dumpsys, pm list). Command chaining, pipes and injection metacharacters are rejected. / Ejecuta un comando shell seguro en el dispositivo Android, restringido a una lista blanca de prefijos de solo lectura (getprop, dumpsys, pm list). Se rechazan encadenamientos, tuberías y metacaracteres de inyección.
| 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 behavioral disclosure burden, and it does a solid job: it states the operation is read-only, restricted to an allowlist, and that chaining, pipes, and injection metacharacters are rejected. It stops short of describing output format or error handling, but the key safety-related behavior is clearly disclosed.
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 portion is short, front-loads purpose and restrictions, and includes a compact warning about rejected patterns. The Spanish repetition is redundant but compact and does not add significant noise.
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 one-parameter tool with a well-covered schema, the description plus schema is mostly complete: it explains what can be run and what will be rejected. It does not explain what the tool returns, how failures/errors are surfaced, or how to choose between this and specialized sibling tools, which leaves minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage: it documents the single command parameter with a pattern, examples, and a bilingual description. The main description adds rejection of chaining/pipes, but that is more about behavioral constraints than new parameter meaning, so the schema already does the heavy lifting.
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 identifies the action (Runs a safe shell command), the target (Android device), and the exact scope (read-only prefixes getprop, dumpsys, pm list). This makes it distinguishable from the logcat/dump sibling tools, though it does not explicitly compare itself to any sibling.
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 intended use is implied by the allowlist and 'safe/read-only' framing: arbitrary read-only shell queries that are not covered by specialized siblings. However, it never explicitly says when to prefer adb_list_packages or adb_get_logcat, so routing between this and overlapping siblings is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Dumps the Android device logcat buffer, optionally filtered by tag, minimum log level and limited to the last N lines. / Vuelca el buffer de logcat del dispositivo Android, opcionalmente filtrado por tag, nivel mínimo de log y limitado a las últimas N líneas.
| 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. / Nivel mínimo de log a incluir (V=verbose … F=fatal). Requiere filter_tag para tener efecto. | |
| 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?
With no annotations, the description carries the behavioral disclosure burden. It clearly indicates this is a dump/read operation, but it does not mention potential output size, default behavior when lines is omitted, or any prerequisites. The schema's lines default (200) conflicts with the phrase 'defaults to the full buffer,' adding ambiguity.
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 a single, front-loaded sentence with no filler. The bilingual translation is compact and mirrors the original without adding unnecessary detail or repetition beyond what localization requires.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with three optional parameters and no output schema, the description covers the core action and filters. It is slightly incomplete because it does not specify default line behavior, and the ambiguous lines default could confuse an agent, but overall it provides sufficient context to invoke the tool correctly.
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 parameter concepts (tag, minimum log level, last N lines) but adds no new meaning beyond the property names and schema descriptions. It does not mention the dependency that log_level requires filter_tag, although the schema does.
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 action ('Dumps') and resource ('Android device logcat buffer'), with clear filtering options. It implicitly distinguishes itself from sibling adb_clear_logcat by describing a read operation rather than a clear operation.
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 when to use the tool—when you need to read the logcat buffer—but it does not explicitly state when not to use it or mention alternatives such as adb_clear_logcat. No exclusions or comparative guidance is provided.
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 (third-party only by default), optionally filtered by a case-insensitive name substring and including system packages. / Lista los paquetes instalados del dispositivo Android (solo de terceros por defecto), con filtro opcional por subcadena del nombre sin distinguir mayúsculas y opción de incluir 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?
No annotations are provided, so the description carries the behavioral burden. It clearly discloses the default third-party-only behavior, the case-insensitive filter, and the include_system option. It does not explicitly state side-effect-freedom or output format, but 'Lists' strongly implies a read-only operation.
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 compact, front-loaded with the core action, and contains no filler. The bilingual repetition is reasonable and does not bloat the message.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter, no-output-schema tool, the description covers the behavior, defaults, and optional parameters. Nothing an agent needs to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents both parameters. The description adds little beyond the schema, mostly restating filter behavior and the default for include_system. This matches the baseline for full schema coverage.
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 uses a specific verb ('Lists') and resource ('packages installed on the Android device'), then clearly states default scope and optional behaviors. It is immediately distinguishable from the sibling tools, which target logcat, hierarchy, and shell execution.
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 makes the intended use clear: list installed packages, optionally filtered, optionally including system packages. It does not explicitly name alternatives or say when not to use it, but the sibling tools are distinct enough that little confusion remains.
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.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
Each tool targets a distinct ADB operation: logcat retrieval, logcat clearing, UI hierarchy extraction, package listing, and safe shell execution. There is no meaningful overlap, and even the two logcat tools are clearly complementary rather than redundant.
All tool names follow the exact same pattern: adb_ prefix plus a verb_noun combination (get_logcat, clear_logcat, dump_hierarchy, list_packages, execute_shell). This is fully consistent and makes the toolset easy to navigate.
With 5 tools, the server is well-scoped for a focused set of ADB inspection capabilities. Each tool fills a clear role without unnecessary bloat or redundancy, fitting comfortably within the ideal tool count range.
The set covers logcat and package inspection well, but it lacks essential ADB operations such as device management, package installation/uninstallation, screen capture, and UI interaction (tap/swipe/type), making UI automation a dead end after dumping the hierarchy. The restricted shell helps but is intentionally read-only, so the overall surface feels notably incomplete for a general ADB server.
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…
A TypeScript MCP server for Home Assistant, enabling programmatic management of entities, automati…