Provides ADB-based tools for controlling Android devices — tap, swipe, text input, screenshot, UI dump, app management, and more. Enables AI agents to interact with Android devices programmatically.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@android-mcp take a screenshot of my device"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Android device automation MCP server for Hermes Agent. Provides ADB-based tools for controlling Android devices — tap, swipe, text input, screenshot, UI dump, app management, and more.
Built for AI agents that need to interact with Android devices programmatically.
Device Management — list, connect, disconnect devices; check connection state
Gestures — tap, swipe, long press, pinch, multi-touch
Input — text typing, key events, clipboard
Screenshots — capture device screen as PNG
UI Analysis — dump view hierarchy via uiautomator
App Control — launch, stop, list installed apps
Password Manager — store and retrieve app credentials locally
System Actions — unlock, lock, volume, power, airplane mode
Related MCP server: Android-MCP
# Clone the repository
git clone git@github.com:AsmanovLev/android-mcp.git
cd android-mcp
# Install dependencies
npm install
# Build
npm run buildAdd to your ~/.hermes/config.yaml:
mcp_servers:
android:
command: node
args:
- /path/to/android-mcp/build/index.jsThen restart Hermes Agent. The tools will be available with the mcp_android_* prefix.
{
"tool": "mcp_android_list_devices"
}{
"tool": "mcp_android_screenshot",
"arguments": { "save_to": "/tmp/screen.png" }
}{
"tool": "mcp_android_tap",
"arguments": { "x": 500, "y": 800 }
}{
"tool": "mcp_android_unlock",
"arguments": { "pin": "1234" }
}Tool | Description |
| List connected ADB devices |
| Capture device screen |
| Dump UI hierarchy via uiautomator |
| Tap at coordinates |
| Swipe from (x1,y1) to (x2,y2) |
| Type text via ADB |
| Send key event |
| Wake + swipe up + enter PIN |
| Launch app by package name |
| Force stop app |
| List installed packages |
| Store/retrieve app credentials |
# Watch mode
npm run dev
# Run tests
npm testDeepagent — AI agent by Hermes Agent
MIT
Download an APK from F-Droid by package name.
| Name | Required | Description | Default |
|---|---|---|---|
| output_dir | No | Output directory (default: /tmp) | |
| package_name | Yes | Package name to download |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It only states 'download an APK' but does not describe network usage, file saving (only schema hints output_dir), error handling, or permission requirements. This is insufficient for a download 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 a single, clear sentence with no unnecessary words. It is concise, but could be slightly improved by adding key behavioral details without becoming verbose.
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 has 2 parameters, no output schema, and no annotations, the description is too sparse. It lacks information about return values (e.g., file path), error scenarios, and side effects, leaving the agent under-informed.
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 coverage is 100% and both parameters have descriptions. The tool description adds no extra meaning beyond the schema (e.g., constraints on package_name format or default output_dir behavior), so baseline 3 is appropriate.
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 verb 'Download', the resource 'APK from F-Droid', and the method 'by package name'. It distinguishes from sibling tools like fdroid_search (which searches) and rustore_download (which downloads from Rustore), though it could be more explicit about the F-Droid source.
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. It does not mention prerequisites (e.g., package name must exist on F-Droid) or scenarios where it is not appropriate (e.g., if package is not found).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for Android apps on F-Droid by query.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (default: 10) | |
| query | Yes | Search query |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description fails to disclose any behavioral traits beyond the obvious search. It does not mention pagination, result ordering, case sensitivity, or any side effects, leaving the agent in the dark.
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, concise sentence with no wasted words. It is efficiently front-loaded with the key action and target.
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?
Despite having no output schema, the description does not explain the return format (e.g., list of app names, packages). It also omits default behavior for the limit parameter. More context is needed for a complete understanding.
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 adds no additional meaning to the parameters beyond what the schema already provides, but it does not hinder understanding.
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 verb 'search', the resource 'Android apps on F-Droid', and the input 'query'. It distinguishes this tool from siblings like fdroid_download and rustore_search by platform and action.
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 like rustore_search or when not to use it. The description is minimal and provides no context or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start an Android activity by intent (package/class, action, data URI, extras).
| Name | Required | Description | Default |
|---|---|---|---|
| action | No | Intent action (e.g., android.intent.action.VIEW) | |
| extras | No | JSON string of extra key-value pairs | |
| serial | No | ADB device serial (optional) | |
| package | No | Package name | |
| data_uri | No | Data URI for the intent | |
| class_name | No | Full class name (e.g., com.example/.MainActivity) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It implies starting an activity but does not disclose side effects (e.g., brings app to foreground), failure modes (e.g., activity not found), or requirements (e.g., ADB connection). This 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?
Single sentence is very concise, but omits the 'serial' parameter, which may lead to confusion. Still, the core purpose is clear with minimal waste.
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 6 parameters, no output schema, and no annotations, the description lacks context on how the tool fits into a workflow, what inputs are critical, or what return behavior to expect. It is minimal for practical agent use.
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 coverage is 100% with each parameter described. The description lists four of the six parameters in parentheses but adds no new details beyond the schema. Baseline 3 is appropriate.
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 verb 'Start' and resource 'Android activity by intent', listing key intent components. It distinguishes from siblings like mobile_button or mobile_type, but could be more explicit about what an Android activity is in context.
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 like mobile_app (if different), prerequisites (e.g., device unlocked), or when not to use it. The description only states functionality.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manage Android apps via ADB: install APK, start app by package, force-stop, uninstall, or list installed packages.
| Name | Required | Description | Default |
|---|---|---|---|
| file | No | Path to APK file (required for install) | |
| action | Yes | Operation | |
| serial | No | ADB device serial (optional) | |
| package | No | Package name (required for start/force-stop/delete; optional filter for list) | |
| return_screen | No | Capture screen after action (default: true) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses basic actions (install, start, etc.) but fails to mention side effects, permissions, error handling, or return values. Adequate but not detailed.
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, using a single sentence to list key actions. It is front-loaded with 'Manage Android apps via ADB' as a summary, but could be better structured with bullet points for clarity.
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 has 5 parameters and no output schema, the description is incomplete. It does not mention return formats (e.g., list output), prerequisites, or how actions interact with parameters like return_screen.
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 baseline is 3. The description adds no extra meaning beyond the schema; it merely lists action types. No details on parameter formats or behaviors.
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 manages Android apps via ADB with specific actions: install, start, force-stop, uninstall, list. It distinguishes from sibling tools like fdroid_download or mobile_activity_manager by specifying ADB and common app management operations.
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 lists actions but does not provide explicit guidance on when to use this tool versus alternatives. It implies usage for app management via ADB but lacks context on prerequisites (e.g., ADB connection) and 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.
Press a hardware/system button on the Android device: back, home, recent apps, menu, volume up/down, power, camera, or call.
| Name | Required | Description | Default |
|---|---|---|---|
| button | Yes | Button to press | |
| serial | No | ADB device serial (optional) | |
| return_screen | No | Capture screen after button press (default: true) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It states it presses a button but does not mention side effects (e.g., screen capture via return_screen) or prerequisites (e.g., ADB connection). The description could be more explicit about behavior.
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 sentence that front-loads the action and lists all relevant buttons. No wasted words and clearly structured.
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 tool with no output schema and high schema coverage, the description is fairly complete. It covers the core action and button options. However, it could mention the default screen capture behavior and the optional serial parameter for multi-device contexts.
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 baseline is 3. The description adds redundancy by listing buttons, but does not provide additional meaning for serial or return_screen beyond what the schema already describes.
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 action ('Press a hardware/system button') and lists the specific buttons (back, home, recent, etc.). This distinguishes it from sibling tools like mobile_gesture (touch gestures) and mobile_power (power management).
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 for pressing hardware buttons but does not explicitly state when to use this tool versus alternatives like mobile_gesture or mobile_power. No when-not or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List connected Android devices and optionally select one as the active device for all mobile tools.
| Name | Required | Description | Default |
|---|---|---|---|
| select | No | Device serial to select as the active device |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It discloses listing (read) and selection (write) but lacks details on permissions, session persistence, or error handling. Adequate but minimal.
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?
Single, clear sentence with no redundant words. Front-loaded and 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?
No output schema, so description should clarify return value (list of serials). Side effect of selecting is mentioned but not detailed. Implied but incomplete for a device management tool.
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 already explains the 'select' parameter. Tool description adds no extra meaning beyond schema, so baseline 3.
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 lists connected Android devices and optionally selects one as active. Resource and verb are specific, and it distinguishes from sibling tools (which are individual mobile actions).
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?
Indicates use before other mobile tools to set active device, providing clear context. However, no explicit when-not-to-use or comparison to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute gestures on the Android device: tap, swipe, long-press, drag, or multi-step gesture sequences.
| Name | Required | Description | Default |
|---|---|---|---|
| x | No | X coordinate | |
| y | No | Y coordinate | |
| x2 | No | End X (required for swipe/fastswipe/swipe-hold-*) | |
| y2 | No | End Y (required for swipe/fastswipe/swipe-hold-*) | |
| text | No | Find element by text and tap it (alternative to x/y) | |
| delay | No | Delay before this step (ms) | |
| action | Yes | Gesture type | |
| serial | No | ADB device serial (optional) | |
| duration | No | Duration in ms | |
| return_screen | No | Capture screen after gesture (default: true) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behaviors, but it only says 'execute gestures' without mentioning side effects, failure scenarios, permissions, or whether it is destructive. The schema describes parameters like return_screen, but the description adds no behavioral context.
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 very concise with a single sentence that covers the core action and gesture types. However, it could be restructured to front-load key information; currently it's minimal but 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?
For a tool with 10 parameters, no output schema, and no annotations, the description is too sparse. It lacks details on return values, error handling, and how parameters interact, making it insufficient for an agent to use reliably without additional 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 baseline is 3. The description lists gesture types, which adds some context, but does not add significant meaning beyond the schema's parameter descriptions and enum values.
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 executes gestures and lists specific types (tap, swipe, etc.), but does not differentiate from sibling tools like mobile_gesture_combo or mobile_gesture_macro, which may also handle multi-step sequences.
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 (e.g., mobile_gesture_combo, mobile_gesture_macro). The description does not specify prerequisites, when not to use, or context-dependent choices.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute a multi-step gesture sequence (array of steps). Each step can be tap, swipe, fastswipe, tap-hold, drag, press, move, release, hold, swipe-hold-start, swipe-hold-end, or swipe-hold-startend.
| Name | Required | Description | Default |
|---|---|---|---|
| steps | Yes | Array of gesture steps to execute in sequence | |
| serial | No | ADB device serial (optional) | |
| return_screen | No | Capture screen after sequence (default: true) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It only lists actions without explaining failure modes, coordinate systems, whether the sequence is atomic, or side effects. Important behavioral traits are missing.
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 concise sentence that front-loads the purpose. However, it lists many actions inline, which could benefit from a bulleted list for readability. Minimal waste, but not perfectly structured.
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 complexity of nested steps and many action types, the description is too brief. It does not explain sequencing, delays, return values, or coordinate semantics. Lacks essential context for a tool with no output schema.
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 coverage is 100%, so baseline 3. The description repeats the action list already in the schema but adds no new semantics about parameter usage, like how coordinates relate or what units are used. No added value beyond 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 the tool executes a multi-step gesture sequence and lists the supported actions. However, it does not differentiate itself from the sibling tool 'mobile_gesture' which presumably handles single gestures, missing an opportunity to guide selection.
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 like mobile_gesture or mobile_gesture_macro, and no conditions or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute a named gesture macro (e.g., 'unlock', 'home', 'back', 'recents', 'notification_panel', 'quick_settings').
| Name | Required | Description | Default |
|---|---|---|---|
| macro | Yes | Macro name | |
| serial | No | ADB device serial (optional) | |
| return_screen | No | Capture screen after macro (default: true) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It only says 'Execute', without mentioning blocking behavior, failure handling, prerequisites, or side effects beyond what is implicit from the macro name.
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 efficient sentence with examples. It is front-loaded and appropriately sized, though the examples are slightly redundant with the enum.
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 no output schema, no annotations, and the tool's side-effect nature (macro execution), the description is incomplete. It lacks information about return values, prerequisites, and how it relates to sibling tools like mobile_gesture_combo.
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 baseline is 3. The description adds no further meaning; it merely lists examples already covered by the enum. It does not enrich understanding of 'serial' or 'return_screen' beyond their schema 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 the action ('Execute') and the resource ('named gesture macro') with concrete examples, distinguishing it from siblings like mobile_gesture (single gestures) and mobile_gesture_combo (combo gestures).
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 does not provide any guidance on when to use this tool vs alternatives (e.g., mobile_gesture, mobile_gesture_combo). No when-not-to-use or exclusion criteria are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Control device power state: turn screen on/off, check if awake, or reboot.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Power action | |
| serial | No | ADB device serial (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral disclosure burden. It conveys that 'reboot' is a destructive action and 'awake' is a check, but lacks details such as whether rebooting causes temporary unavailability or if screen on/off requires secure unlock.
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?
Single sentence, efficiently front-loaded with the purpose and actions. No unnecessary words or structure issues.
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 (2 params, no output schema), the description is adequate but incomplete. It omits information about return values (e.g., what 'awake' returns) and potential side effects of reboot, which would help an agent handle the response 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 coverage is 100%, so baseline is 3. The description adds no extra meaning to parameters beyond the schema's enum values and optional serial description; it merely mirrors them.
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 controls device power state and lists specific actions (turn screen on/off, check awake, reboot). This distinguishes it from sibling tools like mobile_screenshot or mobile_state, which handle different aspects of device interaction.
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. For instance, it does not explain when to use 'reboot' versus 'on'/'off', or how this relates to other mobile tools like mobile_button (which might also affect screen state).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Restart the ADB server (kill + start). Useful when devices are not detected or ADB is stuck.
| 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 bears full burden. It discloses 'kill + start', indicating destructive but transient behavior. While it doesn't mention side effects like dropped connections, the restarting nature is adequately conveyed.
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?
Two sentences, front-loaded with the action. Every word earns its place; no redundancy or unnecessary detail.
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 tool with no parameters and no output schema, the description covers purpose, behavior, and usage context completely. It tells the agent exactly what it does and when to use it.
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?
No parameters exist, so schema coverage is 100%. The description doesn't need to add parameter details. A baseline score of 4 is appropriate for zero-parameter tools.
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 'Restart the ADB server (kill + start)', which is a specific verb and resource. It distinguishes itself from sibling tools like mobile_activity_manager or mobile_app by focusing on ADB connectivity issues.
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?
Explicitly says 'Useful when devices are not detected or ADB is stuck', providing clear context for when to use. No exclusions or alternatives are stated, but the context is sufficient given the tool's specific purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Capture a screenshot from the Android device. Returns the screenshot file path and UI hierarchy text.
| Name | Required | Description | Default |
|---|---|---|---|
| serial | No | ADB device serial (optional) | |
| return_screen | No | Include UI hierarchy text (default: true) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It states that a screenshot is captured from an Android device and returns file path and UI hierarchy, but does not disclose prerequisites (e.g., connected device), side effects (none expected), or error scenarios. Adequate but not exhaustive.
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?
Two efficient sentences, front-loaded with the main action. No unnecessary words or redundancy.
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?
No output schema, but the description specifies return values (file path and UI hierarchy). Given the tool's simplicity, it is fairly complete, though it could mention that it works via ADB or requires a device to be listed.
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 coverage is 100%, but the description adds value by explaining that return_screen controls UI hierarchy text inclusion and that the result includes a file path (not in schema). This clarifies behavior beyond the schema's property 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 the verb ('capture') and resource ('screenshot from the Android device'), and distinguishes it from sibling tools like mobile_gesture or mobile_type. It also mentions return values, adding specificity.
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 (e.g., mobile_state, mobile_unlock_screen). No explicit context for when not to use it, which is needed given 18 sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get device state: battery level, screen orientation, display info, foreground app, and network status.
| Name | Required | Description | Default |
|---|---|---|---|
| serial | No | ADB device serial (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It lists the state attributes but does not disclose whether the data is real-time or cached, or if any side effects occur. Basic transparency, but lacks detail.
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?
Single sentence, front-loaded with action, no wasted words. Efficient and to the point.
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 simplicity (one optional parameter, no output schema), the description covers the purpose and lists key outputs. Slightly lacking in return format details, but sufficient for a basic state getter.
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 coverage is 100% (one parameter 'serial' with description). The tool description adds no additional meaning beyond the schema, earning baseline score.
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 device state' and lists specific attributes (battery level, screen orientation, etc.), distinguishing it from sibling tools that involve actions like app management or button taps.
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 for retrieving device state, but provides no explicit guidance on when to use this tool versus alternatives (e.g., other mobile tools) 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.
Type text into the currently focused input field on the Android device.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Text to type | |
| serial | No | ADB device serial (optional) | |
| clear_first | No | Clear the field before typing (default: false) | |
| return_screen | No | Capture screen after typing (default: true) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Minimal disclosure beyond the basic action. No details on error behavior if no field is focused, support for special characters, or whether it simulates keyboard input vs. ADB commands. With no annotations, the description carries full burden but provides little.
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?
One concise sentence with clear verb and target, front-loaded and without redundancy.
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 4 parameters and no output schema, the description lacks context on post-typing behavior, error handling, or device prerequisites. Incomplete for a tool with multiple optional options.
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 coverage is 100%, so baseline is 3. The description adds no new meaning beyond schema; it does not explain optional parameters like serial for multi-device or the effect of clear_first and return_screen.
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 action ('Type text') and the target ('currently focused input field on the Android device'), distinguishing it from sibling tools like mobile_button or mobile_gesture.
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 (e.g., adb input, or tools like mobile_gesture). Prerequisites (ensuring an input field is focused) are not mentioned, and exclusions are absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Unlock the Android device screen. Wakes the screen, swipes up, and enters a PIN/password if provided.
| Name | Required | Description | Default |
|---|---|---|---|
| pin | No | PIN or password to unlock (optional) | |
| serial | No | ADB device serial (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the steps (wake, swipe, enter PIN) but lacks details on failure modes (e.g., incorrect PIN) or prerequisites (e.g., ADB connection). Since no annotations exist, the description should carry more behavioral context.
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?
A single sentence that efficiently conveys the tool's purpose and actions. No filler, front-loaded with the main action.
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 tool with two optional parameters and no output schema, the description is mostly complete but could mention what happens on failure (e.g., if PIN is wrong) or if the screen is already unlocked. It covers the core functionality.
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 coverage is 100%, and the description adds no new meaning beyond the schema's parameter descriptions. The phrase 'enters a PIN/password if provided' mirrors the schema. Baseline 3 is appropriate.
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 unlocks the Android screen by waking, swiping, and entering a PIN. It specifies the verb 'unlock' and the resource 'Android device screen', distinguishing it from sibling tools like mobile_gesture or mobile_power.
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 is provided on when to use this tool versus alternatives. For example, it does not indicate that it should only be used when the device is locked, nor does it mention prerequisites like the device being connected via ADB.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Wait for a UI element to appear or disappear on the screen, with timeout.
| Name | Required | Description | Default |
|---|---|---|---|
| text | No | Text to wait for | |
| serial | No | ADB device serial (optional) | |
| timeout | No | Max wait time in ms (default: 10000) | |
| className | No | Class name to wait for | |
| disappear | No | Wait for element to disappear instead of appear (default: false) | |
| description | No | Content description to wait for | |
| resource_id | No | Resource ID to wait for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should fully disclose behavior. It only mentions waiting with timeout but fails to explain what happens on timeout (e.g., error, return value) or how multiple parameters interact (e.g., logical AND/OR).
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 concise sentence that covers the core action. While efficient, it could be more structured with parameter usage hints, but not to the point of verbosity.
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?
The tool has 7 parameters and no output schema. The description omits critical context like return behavior, timeout error handling, and parameter combinatory logic, making it incomplete for effective use.
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 documents each parameter. The description adds no new semantic detail beyond the schema, providing baseline value.
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: wait for a UI element to appear or disappear with a timeout. It uses specific verbs and resources, and it distinguishes itself from sibling tools which are not wait-based.
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 is provided on when to use this tool versus alternatives like mobile_button or mobile_gesture. There is no mention of prerequisites, when-not-to-use, or recommended scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manage stored passwords for auto-login on Android apps. Store, retrieve, list, or delete credentials.
| Name | Required | Description | Default |
|---|---|---|---|
| app | No | App package name (required for store/get/delete) | |
| action | Yes | Operation | |
| password | No | Password (required for store) | |
| username | No | Username (required for store) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It states 'Manage stored passwords' and lists actions, but does not detail side effects (e.g., deletion is permanent), security implications, error behavior, or whether credentials are stored in plaintext or encrypted. This is insufficient for a credential management 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 description is a single sentence that efficiently communicates the general purpose and immediate actions. It is front-loaded with the verb 'Manage', though it could be slightly more structured by separating the action list.
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 has 4 parameters, no output schema, and no annotations, the description is too minimal. It does not explain return values (e.g., for 'get'), error handling, or security context. A credential manager requires more complete documentation.
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 reinforces the actions (store, get, list, delete) but adds no additional semantics beyond what the schema already provides for each parameter.
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: managing stored passwords for Android auto-login. It lists the specific actions (store, retrieve, list, delete), distinguishing it from sibling tools which focus on UI automation and app downloads.
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 usage guidelines are provided. The description does not specify when to use this tool versus alternatives, nor does it mention prerequisites or exclusions. Given the sibling tools are unrelated, some context on appropriate usage (e.g., Android credential management only) would be helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Download an APK from RuStore by package name.
| Name | Required | Description | Default |
|---|---|---|---|
| output_dir | No | Output directory (default: /tmp) | |
| package_name | Yes | Package name to download |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It does not disclose side effects (e.g., overwrite behavior, default output directory behavior), error handling, or permissions needed. The description is too brief.
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?
Single sentence, front-loaded with key action. Every word is functional. Could be slightly more informative without becoming verbose.
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 no output schema and no annotations, the description fails to cover return values, error cases, or behavioral nuance. For a download tool, more context (e.g., file naming, success/failure indicators) is needed for completeness.
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 coverage is 100%, so baseline is 3. The description adds 'by package name' but does not provide meaning beyond the schema's parameter descriptions. No added semantics.
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 is specific: verb 'download', resource 'APK from RuStore', and key input 'by package name'. It clearly distinguishes from sibling tools like fdroid_download (F-Droid) and rustore_search (search).
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 vs alternatives (e.g., fdroid_download), nor when not to use it. Lacks context for appropriate invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for Android apps on RuStore by query.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (default: 10) | |
| query | Yes | Search query |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states the action without mentioning if the tool is read-only, any side effects, rate limits, or return behavior, which is insufficient for full transparency.
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, concise sentence that directly conveys the tool's purpose with no superfluous 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?
Missing output schema and annotations; the description does not explain what the search returns (e.g., list of apps, metadata) or provide any further context, leaving the agent underinformed.
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 coverage is 100% with parameter descriptions. The description adds 'by query' which aligns with the query parameter but does not mention 'limit' or provide additional context 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?
The description clearly states the tool searches for Android apps on RuStore using a query, specifying the action, resource, and input. It distinguishes itself from sibling tools like fdroid_search and rustore_download.
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 use for RuStore searches but does not explicitly state when to use it versus alternatives like fdroid_search, nor does it provide any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0fdroid_downloadfdroid_searchmobile_activity_managermobile_appmobile_buttonmobile_device_listmobile_gesturemobile_gesture_combomobile_gesture_macromobile_powermobile_restart_bridgemobile_screenshotmobile_statemobile_typemobile_unlock_screenmobile_waitpassword_managerrustore_downloadrustore_searchEach tool targets a distinct function: gestures, buttons, app management, F-Droid/RuStore search/download, password management, device state, etc. Even gesture tools are differentiated by single, combo, and macro operations.
Naming is inconsistent: some tools have 'mobile_' prefix while others (fdroid_download, rustore_search) do not. Verb-noun combinations vary (e.g., 'mobile_power', 'mobile_activity_manager', 'mobile_device_list'), and some names are vague.
19 tools is on the higher side but justified given the breadth of Android device control. A few tools (e.g., three gesture tools) could potentially be consolidated, but overall count is reasonable.
Covers core device interaction, app lifecycle, and app store search/download. Missing advanced debugging (logcat), file operations, or notification management, but sufficient for common automation tasks.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Control real Android and iOS devices with LLM agents — tap, swipe, type, automate flows.
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.
Turns a phone into a camera+Bluetooth remote so AI assistants can see and control any PC.
Give your AI agents the tools to build, manage, and run automation workflows.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/AsmanovLev/android-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
