Android MCP is a bridge between AI agents and Android devices, enabling natural language-driven mobile automation via ADB and the Android Accessibility API. It supports automated UI testing, app navigation, and device control.
Device Management
List all available ADB devices
Connect to a specific device by serial number (USB or WiFi)
UI Interaction
Click or long-press at specific (x, y) coordinates
Swipe between coordinates for scrolling/navigation
Drag UI elements from one location to another
Type text at specific coordinates, with an option to clear existing content first
Press hardware/system buttons (Back, Home, Volume Up/Down, etc.)
Device State & Information
Capture snapshots of the current device state, optionally including a visual screenshot with UI element bounding box annotations
Retrieve notifications currently displayed on the device
Automation Control
Execute shell commands directly on the device
Pause execution for a specified duration to handle timing-sensitive automation flows
Enables interaction with Android devices through ADB and Accessibility API, allowing for app navigation, UI interactions (click, swipe, type), and automated QA testing without requiring computer-vision pipelines.
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 open the settings app and turn on airplane mode"
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-MCP is a lightweight, open-source tool that bridge between AI agents and Android devices. Running as an MCP server, it lets LLM agents perform real-world tasks such as app navigation, UI interaction and automated QA testing without relying on traditional computer-vision pipelines or preprogramed scripts.
https://github.com/user-attachments/assets/cf9a5e4e-b69f-46d4-8487-0f61a7a86d67
Native Android Integration
Interact with UI elements via ADB and the Android Accessibility API: launch apps, tap, swipe, input text, and read view hierarchies.
Bring Your Own LLM/VLM
Works with any language model, no fine-tuned CV model or OCR pipeline required.
Rich Toolset for Mobile Automation
Pre-built tools for gestures, keystrokes, capture, device state, shell commands execution.
Real-Time Interaction
Typical latency between actions (e.g., two taps) ranges 2-4s depending on device specs and load.
Android 10+
Related MCP server: Android MCP Server
Python 3.13
ADB (Android Debug Bridge)
Android 10+ (Emulator/ Android Device)
Before running the server, ensure your Android device is connected and recognized by ADB:
Connect your Android device via USB or ensure your emulator is running.
Open a terminal and run:
adb devicesYou should see your device listed:
List of devices attached
R38M30XXXXX deviceThe serial number will differ per device. Emulators show serials like emulator-5554.
If the list is empty or shows "unauthorized", check your USB debugging settings on the device.
For WiFi ADB, connect the device first:
adb connect 192.168.1.3:5555
adb devicesYou can run the Android MCP server using UVX (recommended) or UV (for local development).
No need to install dependencies manually. Just configure Claude Desktop:
Windows note: Use Python 3.13 for
uvxon Windows. Python 3.14 currently fails to resolve a transitivepywin32dependency used by the MCP stack.
Locate your config file
Windows: %APPDATA%\Claude\claude_desktop_config.json
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Add the configuration
{
"mcpServers": {
"android-mcp": {
"command": "uvx",
"args": [
"--python",
"3.13",
"android-mcp"
]
}
}
}Note: The server starts first and connects lazily when a tool runs. If no device is specified, it auto-detects connected devices and prefers physical devices over emulators. Use
--device <serial>or theANDROID_MCP_DEVICEenvironment variable to target a specific device.
Configure a specific WiFi device with environment variables:
{
"mcpServers": {
"android-mcp": {
"command": "uvx",
"args": [
"--python",
"3.13",
"android-mcp"
],
"env": {
"ANDROID_MCP_CONNECTION": "wifi",
"ANDROID_MCP_HOST": "192.168.1.3"
}
}
}
}Or pass explicit flags:
{
"mcpServers": {
"android-mcp": {
"command": "uvx",
"args": [
"--python",
"3.13",
"android-mcp",
"--wifi",
"192.168.1.3"
]
}
}
}Clone and Install
git clone https://github.com/CursorTouch/Android-MCP.git
cd Android-MCP
uv syncConfigure Claude Desktop
{
"mcpServers": {
"android-mcp": {
"command": "uv",
"args": [
"--directory",
"</PATH/TO/Android-MCP>",
"run",
"android-mcp"
]
}
}
}Note: Replace
</PATH/TO/Android-MCP>with the full path to your cloned directory. You can also add"--device", "<YOUR_DEVICE_serial>","--wifi", "192.168.1.3", or"--usb"to control device selection.uv syncfollows the repo's.python-version, so local development uses Python 3.13 by default.
You can also use Android-MCP with OpenCode. After cloning and installing the repo (see Option 2), add the server as a local MCP in your OpenCode config (opencode.json):
{
"mcp": {
"android-mcp": {
"type": "local",
"command": ["uv", "--directory", "</PATH/TO/Android-MCP>", "run", "android-mcp"]
}
}
}Note: Replace
</PATH/TO/Android-MCP>with the full path to your cloned directory. As with UV mode, you can append"--device","--wifi","--usb", etc. to thecommandarray to control device selection.
Android-MCP resolves devices lazily when a tool is called, so the MCP server can start even if no device is available yet.
--device RFCN2013V8D: connect to a specific USB serial
--device 192.168.1.3:5555: connect to a specific WiFi ADB target
--wifi 192.168.1.3: use WiFi and auto-append port 5555
--usb: auto-detect the first USB-connected device
--usb RFCN2013V8D: use a specific USB device
--connection wifi: prefer the first available WiFi ADB device
--connection usb: prefer the first available USB device
Supported environment variables:
ANDROID_MCP_DEVICE: explicit serial or host:port
ANDROID_MCP_CONNECTION: auto, usb, or wifi
ANDROID_MCP_HOST: WiFi host, with :5555 added automatically when omitted
If nothing is configured, Android-MCP will use the first available ADB device reported by adb devices. If none are available, tool calls return a configuration error instead of crashing the MCP handshake.
Restart the Claude Desktop
Restart your Claude Desktop. You should see "android-mcp" listed as an available integration. That's it, now you're ready to start controlling your Android device with natural language.
For troubleshooting tips (log locations, common ADB issues), see the MCP docs.
Claude can access the following tools to interact with Windows:
State-Tool: To understand the state of the device.
Click-Tool: Click on the screen at the given coordinates.
Long-Click-Tool: Perform long click on the screen at the given coordinates.
Type-Tool: Type text on the specified coordinates (optionally clears existing text).
Swipe-Tool: Perform swipe from one location to other.
Drag-Tool: Drag from one point to another.
Press-Tool: To press the keys on the mobile device (Back, Volume Up, ...etc).
Wait-Tool: Pause for a defined duration.
State-Tool: Combined snapshot of active apps and interactive UI elements.
Notification-Tool: To access the notifications seen on the device.
Shell-Tool: To execute shell commands on the android device.
SCREENSHOT_QUANTIZED: Set to true to quantize the screenshot to reduce input tokens.
Android-MCP can execute arbitrary UI actions on your mobile device. Use it in controlled environments (emulators, test devices) when running untrusted prompts or agents.
This project is licensed under the MIT License. See LICENSE for details.
Contributions are welcome! Please read CONTRIBUTING for dev setup and PR guidelines.
Made with ❤️ by CursorTouch,
developers: Jeomon George, Muhammad Yaseen
@misc{
author = {cursortouch},
title = {Android-MCP},
year = {2025},
publisher = {GitHub},
howpublished = {\url{https://github.com/CursorTouch/Android-MCP}},
note = {Lightweight open-source bridge between LLM agents and Android},
}Click on a specific cordinate
| Name | Required | Description | Default |
|---|---|---|---|
| x | Yes | ||
| y | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide destructiveHint: true, but the description adds no additional behavioral context (e.g., timing, return values, or side effects). The description is redundant with the annotation.
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?
Extremely short, but too short to be informative. Front-loaded but at the expense of 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 no output schema and 2 required params, the description is incomplete. It does not explain what the tool returns or any side effects. The low complexity of a click action is not fully covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage for parameters x and y. The description does not explain what x and y represent (e.g., coordinates on screen, units, range). The tool name and schema type hint at integers, but meaning is missing.
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 the verb 'click' and resource 'coordinate', but the typo 'cordinate' and lack of context (e.g., what is being clicked) make it vague. It distinguishes from siblings like ClickBySelector only by implication of using coordinates.
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 vs alternatives like ClickBySelector. No context about prerequisites 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.
Click on an element by selector (text, resourceId, className, description). More reliable than coordinate clicks — handles dynamic layouts and element reflow. At least one selector must be provided.
| Name | Required | Description | Default |
|---|---|---|---|
| text | No | ||
| index | No | ||
| timeout | No | ||
| className | No | ||
| resourceId | No | ||
| description | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations: it mentions handling dynamic layouts and reflow, and the constraint that at least one selector must be provided. While annotations already set destructiveHint=true, the description does not contradict it and provides additional positive traits.
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 consists of two concise sentences conveying purpose, advantage, and constraint. Every word serves a function, with 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?
Given 6 parameters, no output schema, and typical selector-based clicking complexity, the description provides sufficient context: it explains the method, reliability advantage, and the need for at least one selector. It does not cover error handling or return values, but these are reasonable omissions given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description compensates by listing the selector types (text, resourceId, className, description) and stating the 'index' and 'timeout' implicitly via the schema. It clarifies that at least one selector must be provided, adding meaning to parameter usage. However, it does not detail format or constraints 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 action ('Click'), target ('element by selector'), and lists available selector types (text, resourceId, className, description). It distinguishes from coordinate clicks by highlighting reliability and dynamic layout handling, making the tool's purpose unambiguous.
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 this tool ('More reliable than coordinate clicks') and references an alternative ('coordinate clicks'), likely the sibling 'Click' tool. However, it does not explicitly state when not to use or provide a direct comparison, leaving room for minor ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Connect to an ADB device by serial number
| Name | Required | Description | Default |
|---|---|---|---|
| serial | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The tool description does not disclose behavioral traits like side effects on existing connections, authentication requirements, or confirmation of connection. Annotations provide no additional hints (no readOnlyHint or destructiveHint).
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, front-loaded with key information. 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?
Given the tool's function (connection) and lack of output schema or annotations, the description is incomplete. It omits prerequisites, return values, and error conditions, leaving the agent without sufficient 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 coverage is 0%. The description minimally explains 'serial' as an identifier, but does not detail its format, source, or validation rules, which is essential for correct invocation.
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 (connect), the resource (ADB device), and the method (by serial number). It is easily distinguishable from sibling tools like ListDevices.
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, such as prerequisite calls to ListDevices to obtain a serial number, or handling of already connected devices.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manage ADB devices (list, connect, or disconnect)
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | ||
| serial | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not disclose any behavioral traits beyond the basic actions. It fails to indicate side effects (e.g., disconnecting a device may interrupt operations), required permissions, or error handling. With no annotations providing safety hints, the description leaves the agent uninformed about consequences.
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 extremely concise, consisting of a single sentence that front-loads the core purpose. However, this brevity sacrifices necessary details about parameters and usage, making it less effective than a slightly longer but more informative description.
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 parameters, no output schema) and lack of annotations, the description should cover parameter constraints and behavioral context. It does not explain when serial is needed or provide any usage guidance, resulting in significant gaps for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must explain parameter meanings but does not. While the action parameter's enum values are self-explanatory, the serial parameter's role (required for connect/disconnect, optional for list) is not clarified, leaving ambiguity for the agent.
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 that the tool manages ADB devices with three specific actions (list, connect, disconnect), providing a specific verb-resource pairing. However, it does not differentiate itself from sibling tools like ConnectDevice or ListDevices, which could cause confusion about which tool to use.
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 offers no guidance on when to use this tool versus alternatives, nor does it provide any context about prerequisites or appropriate scenarios. With siblings like ConnectDevice and ListDevices, the lack of usage guidelines is a significant gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Drag from location and drop on another location
| Name | Required | Description | Default |
|---|---|---|---|
| x1 | Yes | ||
| x2 | Yes | ||
| y1 | Yes | ||
| y2 | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description doesn't add behavioral info beyond the annotation destructiveHint: true. It does not explain mutating effects, coordinate system, or any side effects.
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 with no extraneous words; appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and 4 required params, the description fails to explain coordinate units, screen origin, or any special behavior, making it insufficient for an agent to use 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 has 0% description coverage; the description implies x1,y1 are start and x2,y2 are end, but no clarification on units, origin, or order, leaving ambiguity.
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 'Drag from location and drop on another location', clearly indicating a drag-and-drop operation between two points, which distinguishes it from sibling tools like Click or Swipe.
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 Swipe or LongClick; missing context about prerequisites or use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List available ADB devices
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint: true. Description adds no behavioral context beyond the annotation, but does not contradict it.
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?
Extremely concise, using only essential words. No unnecessary 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?
Adequate for a simple parameterless list operation. Could mention output format, but not essential given simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has no parameters (100% coverage), so baseline is 3. Description does not add parameter information but none is needed.
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 'List' and resource 'available ADB devices', clearly distinguishing it from sibling tools like ConnectDevice or Device.
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., ConnectDevice). No context about prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Long click on a specific cordinate
| Name | Required | Description | Default |
|---|---|---|---|
| x | Yes | ||
| y | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation includes destructiveHint: true, but the description adds no behavioral details beyond restating the name. It does not explain the duration of the click, potential side effects, or what 'destructive' means in this 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 extremely short, which is concise but sacrifices clarity and usefulness. It has a typo and omits critical information, making it minimally acceptable.
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 domain (UI automation), the complexity of 'long click' (duration, expected result), and the lack of output schema or schema descriptions, the description is incomplete. It does not explain what happens post-click or error conditions.
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 schema has 0% description coverage for the two integer parameters (x, y). The description merely mentions 'specific cordinate' without specifying units, valid ranges, or how coordinates are interpreted (e.g., screen relative). This fails to compensate for the lack of 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 ('long click') and target ('specific cordinate'), distinguishing it from siblings like 'Click' (short click) and 'ClickBySelector' (click by selector). The typo 'cordinate' slightly detracts but does not obscure the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'Click' or 'ClickBySelector'. There is no mention of prerequisites, context, 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.
Access the notifications seen on the device
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states 'Access' implying a read-only operation, while annotations set destructiveHint to true, indicating the tool may modify or delete state. This contradiction makes the behavior unclear and potentially misleading.
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 that conveys the tool's purpose without unnecessary 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?
Given no output schema and a contradictory annotation, the description fails to clarify what 'access' means in terms of return values or side effects. It is incomplete for a tool with no parameters and 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?
There are no parameters, so the schema coverage is 100%. The description does not add parameter-specific semantics, but with zero parameters no additional information is needed.
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 the verb 'access' and specifies the resource 'notifications' with scope 'on the device', clearly distinguishing it from sibling tools like Click or Type which involve direct 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?
The description provides no guidance on when to use this tool versus alternatives, nor does it mention any prerequisites or contexts where it is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Press on specific button on the device
| Name | Required | Description | Default |
|---|---|---|---|
| button | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not mention any behavioral implications, such as the destructive nature indicated by the destructiveHint annotation. It merely states 'press' without elaborating on side effects or outcomes.
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 short sentence with no unnecessary words, but it lacks detail to be fully useful. It is concise but under-specified.
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 destructive hint and lack of output schema, the description should explain the effect of pressing (e.g., triggering an action, potential risk). It does not, leaving the agent without essential behavioral 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?
The description only uses the parameter name 'button' without explaining valid values, format, or constraints. With 0% schema description coverage and no enums, the agent gets no additional meaning beyond the raw 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 action (Press) and the target (specific button on the device). It distinguishes from sibling tools like Click and LongClick by implying a standard press, but does not explicitly contrast 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?
No guidance is provided on when to use this tool versus alternatives such as Click, LongClick, or other input actions. The description lacks context on prerequisites or scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the state of the device. Optionally includes visual screenshot when use_vision=True. The use_annotation parameter (default True) can be set to False to get a clean screenshot without bounding boxes.
| Name | Required | Description | Default |
|---|---|---|---|
| use_vision | No | ||
| use_annotation | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, indicating a safe read operation. The description adds value by clarifying that the tool can optionally capture visual screenshots with or without bounding boxes. No contradictory behavior is mentioned, and additional traits (e.g., performance impact of vision) are not needed.
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 concise sentences with zero filler. Front-loaded with main purpose ('Get the state of the device') followed by optional features. Every sentence adds value.
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 tool with no output schema, the description covers purpose and parameter semantics. It could briefly note what 'state' includes (e.g., device info, UI layout) but is otherwise complete enough for agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameter semantics. It does so effectively: use_vision triggers visual screenshots, use_annotation toggles bounding boxes. This provides clear meaning beyond the schema's type/default definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get the state of the device.' It specifies optional visual screenshots via use_vision and annotation control via use_annotation. This distinguishes it from sibling tools, which are actions (Click, Type, etc.) rather than state retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains parameter usage (use_vision, use_annotation) but does not provide explicit guidance on when to use this tool over alternatives or when not to use it. It implies usage for visual context but lacks explicit context differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Swipe on a specific cordinate
| Name | Required | Description | Default |
|---|---|---|---|
| x1 | Yes | ||
| x2 | Yes | ||
| y1 | Yes | ||
| y2 | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide 'destructiveHint: true' but the description adds no further behavioral context, such as the effect of the swipe, duration, or coordinate system. Without annotations, this would be critical, but here it adds minimal value.
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 short (5 words) but fails to convey essential information, making it under-specific rather than concise. It wastes the opportunity to add value.
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 required parameters, no output schema, and a destructive hint, the description is severely incomplete. It does not explain coordinate system, units, gesture behavior, or expected outcomes, leaving the agent with insufficient 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 has 0% description coverage for its 4 parameters (x1, y1, x2, y2), and the description does not explain what these parameters represent (e.g., start and end points). The agent cannot infer parameter meaning from the description alone.
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 'Swipe on a specific cordinate' which indicates the action but is vague and misspelled. It does not clarify that the swipe is between two coordinates or distinguish it from the sibling 'Drag' tool. The purpose is only partially clear.
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 'Drag' or 'Click'. The description lacks any context about appropriate scenarios or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Type on a specific cordinate
| Name | Required | Description | Default |
|---|---|---|---|
| x | Yes | ||
| y | Yes | ||
| text | Yes | ||
| clear | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only restates the basic action. Annotations indicate destructiveHint=true, but the description does not elaborate on what may be destroyed (e.g., overwritten text) or other behavioral traits like clearing existing content. The 'clear' parameter is not explained.
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 short (one sentence), which is concise but omits necessary information. It could be restructured to include more detail 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?
With four parameters, no output schema, and a destructive hint, the description is severely inadequate. It fails to explain how coordinates work, the effect of the 'clear' parameter, or return behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning to the four parameters (x, y, text, clear). It only mentions 'coordinate' without specifying which properties map to coordinates.
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 'Type on a specific cordinate', specifying the action (type) and target (coordinate). This distinguishes it from sibling tools like Click (mouse click) and Press (key press without location). However, the typo 'cordinate' slightly detracts from clarity.
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 such as Press or Click. The description does not mention prerequisites, context, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Wait for a specific amount of time
| Name | Required | Description | Default |
|---|---|---|---|
| duration | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide idempotentHint and destructiveHint, but description adds no behavioral context beyond 'wait', leaving side effects unclear.
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 concise sentence, no unnecessary words, effectively front-loaded.
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 simplicity, description lacks essential details like time units, behavior during wait, and any side effects, leaving gaps for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% for the required 'duration' parameter; description does not specify units (seconds, milliseconds) or range, adding minimal meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'Wait' and resource 'specific amount of time', distinguishing it from sibling 'WaitForElement' which waits for an element condition.
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 vs alternatives like WaitForElement, or context for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Wait for an element to appear on screen. Use this instead of Wait when content is loading dynamically. Returns element info when found or error on timeout.
| Name | Required | Description | Default |
|---|---|---|---|
| text | No | ||
| timeout | No | ||
| className | No | ||
| resourceId | No | ||
| description | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool returns element info on success or error on timeout, adding behavioral context beyond the readOnlyHint annotation. It doesn't contradict annotations and explains dynamic loading 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 three sentences long, front-loads the core purpose, and contains no irrelevant information. Every sentence adds value.
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, no output schema, and zero parameter descriptions, the description is insufficiently complete. It explains when to use and what happens on success/failure but does not cover how to specify the element or what 'element info' includes.
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 5 parameters with zero schema descriptions, and the tool description provides no insight into their meaning or usage. The description doesn't clarify how parameters like text, className, or resourceId identify the element, leaving the agent guessing.
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 waits for an element to appear on screen, using a specific verb and resource. It distinguishes itself from the sibling 'Wait' by specifying dynamic loading 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?
The description explicitly recommends using this tool over 'Wait' when content loads dynamically, providing clear usage context. However, it does not mention when not to use it or list alternatives beyond Wait.
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.
v0.2.0ClickBySelectorDeviceWaitForElementv0.1.0ClickConnectDeviceDragListDevicesLongClickNotificationPressSnapshotSwipeTypeWaitSeveral tools have overlapping purposes. Coordinate-based actions (Click, LongClick, Type, Swipe, Drag) are all performed at coordinates, making it unclear when to use which. Device management tools (ConnectDevice, Device, ListDevices) also overlap. ClickBySelector and WaitForElement are distinct but the overall set causes confusion.
All tool names use PascalCase, but the naming style is inconsistent. Some are single verbs (Click, Drag, Wait) while others are compound verbs (ClickBySelector, WaitForElement) or nouns (Device, Notification, Snapshot). There is no consistent verb_noun or action_object pattern.
14 tools is well-scoped for an Android device interaction server. It covers device management, UI interactions, and screen capture, without overwhelming the agent. Each tool serves a distinct purpose and the count is appropriate for the domain.
The tool surface covers core Android automation tasks like clicking, typing, swiping, and device management. However, it lacks explicit scroll support, element property inspection, and text input by selector (only coordinate-based typing). These gaps may require workarounds.
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.
Drive real Android & iOS devices and web browsers from natural language for mobile + web QA. 290+ tools across device control, app management, automation sessions, browser automation, and flow recording / replay. Bearer-auth — get a token at robotactions.com → Profile → API Tokens.
Human-input bridge for AI agents with voice-first answer links, MCP tools, and HTTP APIs.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/CursorTouch/Android-MCP'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
