Android-MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| Click-ToolA | Tap at exact (x,y) pixel coordinates. Prefer Click-By-Label when you have a label index from State-Tool. |
| State-ToolA | Get current screen state: interactive UI elements with label indices, types, names, and tap coordinates. Returns device context (current app, keyboard visibility, screen size). Set use_vision=True for annotated screenshot. Always call this first before interacting. |
| Click-By-LabelA | Tap an element by its label index from the most recent State-Tool output. Safer than Click-Tool because coordinates are resolved internally. |
| Long-Click-ToolA | Long-press at (x,y) for ~1 second. Use for context menus or elements requiring sustained touch. |
| Swipe-ToolA | Swipe from (x1,y1) to (x2,y2) over 300ms. To scroll DOWN, swipe from bottom to top. To scroll UP, swipe from top to bottom. |
| Type-ToolA | Tap (x,y) to focus the input field, then type the given text. Only use on input/editable elements. |
| Drag-ToolA | Drag from (x1,y1) to (x2,y2) over 500ms. Use for reordering, moving items, or adjusting sliders. |
| Press-ToolA | Press a device button: home, back, menu, power, volume_up, volume_down, enter, delete. Also accepts raw Android KEYCODE strings. |
| Notification-ToolB | Access the notifications seen on the device |
| Wait-ToolC | Wait for a specific amount of time |
| Setup-DeviceA | Install the Portal helper app on the device and enable its accessibility service. Use this when State-Tool is slow or the fast MCP Helper backend is unavailable. |
| Start-Recording-ToolA | Start recording test actions |
| Stop-Recording-ToolA | Stop recording test actions. After stopping, use Export-Test-Script with format="pytest" to generate a test with assertions. |
| Export-Test-ScriptA | Export recorded test actions as executable test script. Supported formats: python (default, simple replay script), pytest (with assertions), json, readable. |
| Clear-Recording-ToolA | Clear all recorded test actions |
| Get-Recording-Stats-ToolB | Get statistics about recorded test actions |
| Report-Bug-To-AzureB | Report a bug to Azure DevOps using Azure CLI with proper bug report structure (generates command to run) |
| Report-Bug-To-Azure-DirectC | [EXPERIMENTAL] Report a bug to Azure DevOps - direct execution (may hang) |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 18 tools
Most tools target clearly distinct actions: tapping, swiping, typing, dragging, pressing buttons, notifications, waiting, and recording. The main ambiguity is between Click-Tool and Click-By-Label, which both perform taps, and Report-Bug-To-Azure vs Report-Bug-To-Azure-Direct, which are near-duplicates.
There is a recognizable pattern of verb-noun with a -Tool suffix for many tools, but notable exceptions like Setup-Device, Export-Test-Script, Report-Bug-To-Azure, and Click-By-Label break the pattern. Notification-Tool is noun-first rather than verb-first, making the convention mixed but still generally readable.
18 tools is slightly above the ideal 3-15 range, but the count is justified by the combination of core UI automation actions, device state access, and a test recording pipeline. The two bug-report tools are somewhat redundant and could be consolidated, but overall the scope is reasonable.
The toolset covers the core Android automation lifecycle well: screen state discovery, coordinate-based and label-based interaction, gestures, device buttons, notifications, waiting, and recording/exporting tests. Minor gaps exist, such as no explicit wait-for-element or direct assertion tool, but agents can work around these using the state and export features.