What can you do with this server?

This server provides an MCP interface to control and automate Android devices (real or emulated) via ADB and UIAutomator, enabling AI agents to see the screen, read UI elements, and perform interactions — no device-side app required. Device Management * List connected devices (list_targets) — serial numbers, state, and model * Get detailed device info (status) — state, system properties, and battery level Screen Reading * Capture a screenshot (screenshot) — returns the current screen as a PNG image * Describe the screen (describe_screen) — parses the live UIAutomator UI tree into a flat list of elements with labels and exact tap coordinates (x, y) Input & Interaction * Tap at specific screen coordinates (tap) * Swipe from one coordinate to another with optional duration (swipe) * Long press at a coordinate with optional duration (long_press) * Type arbitrary text including spaces, special characters, and unicode (type_text) Key Events * Press named keys like home, back, enter, or recents (press_key, press_home, press_back) App & URL Launch * Launch an app by package name or friendly name (launch_app) * Open any HTTP/HTTPS URL in the device's default browser (open_url) All tools accept an optional serial parameter to target a specific device when multiple are connected. describe_screen returns exact element coordinates that feed directly into tap, enabling deterministic interactions without OCR guessing.

Which integrations are available for this server?

Allows AI agents to control physical Android devices and emulators via adb, providing tools for screen capture, UI tree inspection, input events (tap, swipe, type), app launching, and device status.

How do I use androir-mcp?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@androir-mcp what's on the screen?" 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.

androir-mcp

by benasbarciauskas

Overview Schema Source Related Servers Discussions Admin

TypeScript

Local

androir-mcp

Drive real Android devices from any AI agent — see the screen, tap, swipe, type, over adb.

An independent, standalone Model Context Protocol server that gives an AI agent a clean, safe automation surface for physical Android devices and emulators: capture the screen, read the live UI tree, and drive input — backed entirely by adb + uiautomator, no native code and no device-side app.

License Node TypeScript MCP PRs welcome Stars

NOTE

Requiresadb (Android platform-tools) and an Android device with USB debugging enabled (or an emulator). The server runs locally, holds no credentials, and talks only to the device(s) adb already sees.

✨ What is androir-mcp?

androir-mcp is a standalone MCP server for automating Android over adb. It is its own project — not a copy or port of anything — exposing a small, conventional screen-read + input tool set that drops into any MCP-based agent loop.

Everything is backed by adb and uiautomator: there is no native code and nothing to install on the device. The agent shells out to adb (always as an argv array — never a shell string) to capture screenshots, dump the UI hierarchy, and send input events.

The key advantage on Android is that describe_screen returns the real UI tree — exact element bounds and text straight from uiautomator — rather than guessing from OCR. Tap coordinates come back as element centers and feed straight into tap, so an agent can read a screen and act on it deterministically.

Related MCP server: Android MCP Server

🚀 Features

📸 screenshot — capture the device screen as a PNG (signature-validated).
🌳 describe_screen — parse the uiautomator UI tree into a flat list of labels with center tap coordinates (text / content-desc / class, entity-decoded).
👆 tap / swipe / long_press — coordinate input in device pixels.
⌨️ type_text — type arbitrary text safely (spaces, metacharacters, and unicode all type verbatim).
🔘 press_key / press_home / press_back — named key events.
📱 launch_app — launch by package name or a friendly name (resolved from the installed package list, cached per device).
🔗 open_url — open an http(s) URL in the default browser.
🔎 list_targets / status — enumerate connected devices and read device state, properties, and battery.

Safety by construction:

🛡️ argv-only adb — every command is an argument array, never a shell string, and any value handed to the device shell is single-quoted for it, so there is no shell-injection surface.
✅ strict serial validation — serials are checked against [A-Za-z0-9.:_-] (≤ 128 chars) before reaching any subprocess.
⏱️ per-call timeout (default 30 s) with process-group kill on timeout.
🤫 scrubbed errors — concise messages only; no raw adb stderr (which can leak serials/paths) and no host stack traces reach the model.

🛠️ Tools

Tool	adb implementation	Returns
`list_targets`	`adb devices -l`	serials + model + state
`status`	`adb -s S get-state` (+ props, battery)	device/offline/unauthorized + info
`screenshot`	`adb -s S exec-out screencap -p`	PNG image content
`describe_screen`	`adb -s S exec-out uiautomator dump /dev/tty` (fallback: dump to `/sdcard` then `exec-out cat`) → parse XML	element list: label / center tap (x,y)
`tap` (x,y)	`adb -s S shell input tap X Y`	confirmation
`swipe` (x1,y1,x2,y2,dur_ms?)	`adb -s S shell input swipe X1 Y1 X2 Y2 DUR`	confirmation
`long_press` (x,y,dur_ms?)	`input swipe X Y X Y DUR` (same point)	confirmation
`type_text` (text)	`adb -s S shell input text '<quoted>'` (space→`%s`, single-quoted for the device shell)	confirmation
`press_key` (key)	`adb -s S shell input keyevent <KEYCODE>` — names: home→3, back→4, enter→66, recents→187	confirmation
`press_home`	`input keyevent 3`	confirmation
`press_back`	`input keyevent 4`	confirmation
`launch_app` (name or pkg)	resolve name→package (from `pm list packages`), then `monkey -p PKG -c android.intent.category.LAUNCHER 1`	confirmation
`open_url` (url)	`am start -a android.intent.action.VIEW -d '<url>'` (http/https only)	confirmation

All tools take an optional serial; it defaults to the single connected device and errors if the choice is ambiguous. Coordinates are in device pixels, so describe_screen tap points feed straight into tap with no translation.

🏁 Getting started

Prerequisites

adb (Android platform-tools) on your PATH.
An Android device with USB debugging enabled, or a running emulator. Confirm it's visible:
```
adb devices
```

Build

npm install
npm run build

Attach to an MCP client

Add the built server to your MCP client config:

{
  "mcpServers": {
    "androir": {
      "command": "node",
      "args": ["/path/to/androir-mcp/dist/index.js"]
    }
  }
}

Verify

With a device connected, run the self-check (it lists targets, takes a screenshot, and dumps the UI tree):

npm run selfcheck

It prints PASS when the three core tools work end-to-end against a real device.

🤖 Use with an AI agent

Once androir is attached to your MCP client, give the agent a goal and let it read the screen and act:

You: Open the Settings app, go to Wi-Fi, and tell me which network is connected.
Agent: calls launch_app("settings") → describe_screen() (reads the labels + tap coordinates) → tap(x, y) on "Wi-Fi" → describe_screen() again → reports the connected network.

Because describe_screen returns exact element bounds and text, the agent taps real coordinates rather than guessing from a screenshot.

🗺️ Status & roadmap

Core tools — screenshot, describe_screen, tap, swipe, long_press, type_text, press_key/home/back, launch_app, open_url, list_targets, status
uiautomator XML parsing → labels + center tap coordinates (entity-decoded, malformed-XML tolerant)
Device-shell-safe input escaping (no shell injection) + strict serial validation
Unit tests for the XML parser and the input-escaping logic
Pre-push secret-scan hook
Recording / replay skills
Multi-device parallel control
Emulator-specific paths
Published npm package / npx bin

This README and roadmap fill in as the project progresses.

📄 License

Apache-2.0.

Available Tools

13 tools

describe_screenA

Parse uiautomator UI tree; returns element labels and tap coordinates

ParametersJSON Schema

Name	Required	Description	Default
`serial`	No	Device serial (optional; required when multiple devices connected)

TDQS

A3.8/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description bears the burden. It states the operation (parse UI tree) and output (labels, coordinates) but does not disclose potential side effects or prerequisites like accessibility service.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

One sentence with a clear verb ('Parse') and outcome. No extraneous words; front-loaded and efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with one optional parameter and no output schema, the description covers the essentials. However, it could mention the return format or that it captures the current screen state.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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 does not add meaning beyond the schema's parameter description for 'serial'.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it parses the uiautomator UI tree and returns element labels and tap coordinates. This is specific and distinguishes it from sibling tools like screenshot or tap.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool vs. alternatives like tap or screenshot. Usage is implied but not clarified.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

launch_appC

Launch app by package name or friendly name

ParametersJSON Schema

Name	Required	Description	Default
`serial`	No	Device serial (optional; required when multiple devices connected)
`name`	Yes	App name or package (e.g. com.android.chrome)

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description must fully disclose behavior. It only says 'Launch app' with no details on side effects (e.g., whether it brings to foreground, fails gracefully, or requires unlocked device).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, 8 words, efficient. Could be improved with structured parameter hints, but acceptable for a simple tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool is straightforward with no output schema, but missing behavioral context and prerequisites. Adequate for simple use but not thorough.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so baseline is 3. Description adds 'friendly name' context not in schema, but does not elaborate on what constitutes a friendly name.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool launches an app and specifies two identification methods (package name or friendly name). It is distinct from sibling tools like tap or open_url.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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. Does not mention 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.

list_targetsA

List connected Android devices (serial, state, model)

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.8/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must cover behavioral traits. It states it lists devices but doesn't disclose the return format, whether it refreshes, or if any prerequisites exist. The behavior is simple but incomplete.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single concise sentence that conveys the essential information without extraneous details.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a parameter-less list tool, the description is mostly adequate. It could mention that it is used to discover available devices before interacting with them, but overall it is complete enough given the simplicity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters exist in the schema, so the description's mention of returned fields (serial, state, model) adds value beyond the schema. Baseline 4 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'List' and the resource 'connected Android devices', and specifies the fields returned (serial, state, model). This fully differentiates it from sibling tools which perform actions on devices.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool versus alternatives. While the purpose is clear from context, there is no mention of when to use list_targets vs. other informational tools like 'status' or 'describe_screen'.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

long_pressC

Long press at (x,y)

ParametersJSON Schema

Name	Required	Description
`serial`	No	Device serial (optional; required when multiple devices connected)
`x`	Yes	X coordinate
`y`	Yes	Y coordinate
`duration`	No	Duration in ms (default 1000)

TDQS

C2.8/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description bears full responsibility for behavioral disclosure. It only states the action without describing effects (e.g., triggering a context menu), safety implications, or what happens after the press. Duration is not mentioned in the description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise (one sentence) and front-loaded. It is adequate but could be improved by including the default duration or a brief usage hint without adding much length.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 4 parameters, no output schema, and no annotations, the description is too minimal. It does not explain the gesture's purpose or behavior beyond the coordinates, leaving gaps in understanding for complex use cases.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the description does not need to compensate for missing parameter info. However, it adds no additional meaning beyond the schema; it merely restates x and y coordinates without mentioning duration or serial.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action as a long press at coordinates, which is specific and not a tautology. However, it does not distinguish from sibling tools like 'tap' or 'swipe', missing an opportunity to clarify the holding aspect.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use long_press versus alternatives such as tap, swipe, or other gesture tools. The description lacks context about prerequisites or typical scenarios.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

open_urlA

Open an http(s) URL in the default browser

ParametersJSON Schema

Name	Required	Description	Default
`serial`	No	Device serial (optional; required when multiple devices connected)
`url`	Yes	HTTP(S) URL

TDQS

A3.6/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, description states it opens in default browser, implying no side effects. But does not disclose behavior for invalid URLs, missing browser, or error handling.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, 10 words, front-loaded with essential information. No unnecessary content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool, the description is largely complete. However, it lacks details on optional serial parameter behavior and return value.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%. Description adds minimal extra meaning (specifies 'HTTP(S)') beyond what schema already provides for parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it opens an HTTP(S) URL in the default browser. It specifies the action (open) and resource (URL), and is distinct from sibling tools like launch_app or tap.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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., launch_app could also open a browser). No prerequisites or exclusions mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

press_backC

Press the back button

ParametersJSON Schema

Name	Required	Description	Default
`serial`	No	Device serial (optional; required when multiple devices connected)

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description should disclose behavioral traits (e.g., navigates backward, may exit app, no side effects). It only states the action, offering no transparency beyond the obvious.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise at 4 words. However, it may be too sparse, bordering on under-specification. It is front-loaded but could benefit from a bit more detail without harming conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description does not explain return values or behavior. It is incomplete for a tool with a complex context (device automation). Missing details like when the serial parameter is required.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The only parameter 'serial' is fully described in the schema. The description adds no value beyond what the schema provides, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Press the back button' clearly states the action (press) and the target (back button), distinguishing it from siblings like press_home or press_key. However, it could be more specific about whether it targets the hardware or software back button.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use press_back versus alternatives (e.g., press_home, tap). The description does not provide context or prerequisites, leaving the agent to infer usage.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

press_homeB

Press the home button

ParametersJSON Schema

Name	Required	Description	Default
`serial`	No	Device serial (optional; required when multiple devices connected)

TDQS

B3.1/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It fails to disclose behavioral traits such as side effects (e.g., navigating to home screen), device compatibility, or error states. The description is too minimal.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single clear sentence, front-loaded and efficient. It could be slightly expanded without losing conciseness, but it earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the absence of output schema and annotations, the description is incomplete. It does not explain return values, device requirements, or potential side effects, nor does it compensate for missing structured data.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with one parameter 'serial' already documented. The description adds no additional meaning, meeting the baseline of 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Press the home button' uses a specific verb-resource pair, clearly stating the action. It distinguishes from sibling tools like press_back, long_press, and tap, which have different targets or durations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is given on when to use press_home versus alternatives like press_back or tap. The description does not mention context, prerequisites, or conditions for use.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

press_keyC

Press a named key (home, back, enter, recents)

ParametersJSON Schema

Name	Required	Description	Default
`serial`	No	Device serial (optional; required when multiple devices connected)
`key`	Yes	Key name

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description holds the full burden. It only states the action without any behavioral context (e.g., whether the press is instantaneous, if it waits for completion, how errors are handled, or what the tool returns). This is insufficient for safe invocation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that front-loads the core action and examples. It is concise with no filler, but could be more informative without sacrificing brevity (e.g., explicit note about optional serial).

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description fails to mention return values or side effects. It also omits device prerequisites or behavioral details. The tool is simple but the description lacks completeness for an agent to use it confidently.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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 example values for the 'key' parameter (home, back, enter, recents), which provides some context beyond the schema's 'Key name'. However, it does not elaborate on the 'serial' parameter beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool presses a named key and provides examples (home, back, enter, recents). However, it does not differentiate itself from sibling tools press_back and press_home, which could cause confusion about when to use this generic version vs the dedicated ones.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives no guidance on when to use press_key versus alternatives like press_back or press_home. It fails to mention that this tool is intended for keys without dedicated tools, leaving the agent without decision support.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

screenshotB

Capture device screen as PNG

ParametersJSON Schema

Name	Required	Description	Default
`serial`	No	Device serial (optional; required when multiple devices connected)

TDQS

B3/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It only states the basic capture function but omits whether the capture is synchronous, requires permissions, affects device state, or returns metadata. Minimal transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise (4 words), but this brevity sacrifices useful detail. Adequate for a simple tool, but lacks structure that would aid understanding.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has one optional parameter, no output schema, and no annotations, the description is too incomplete. It should mention typical use cases, output behavior, or constraints (e.g., requires display).

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline 3. The description does not add any parameter meaning beyond the schema's description of the optional serial parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action (capture), resource (device screen), and output format (PNG). It is distinct from sibling tools like describe_screen (which describes elements) and tap/swipe (which interact).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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. No mention of prerequisites (e.g., device display on) or when not to use (e.g., if screen is locked).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

statusA

Device info: state, properties, battery

ParametersJSON Schema

Name	Required	Description	Default
`serial`	No	Device serial (optional; required when multiple devices connected)

TDQS

A3.7/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It discloses the tool is read-only (info retrieval) but does not specify required permissions, potential pop-ups, or whether it works offline. Minimal but adequate for a simple status check.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

One concise sentence with no wasted words. The information is front-loaded and scannable. Perfect length for the complexity of the tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Lacks detail on the output format (e.g., JSON structure) and does not explain how to interpret 'state' or 'properties'. Given no output schema, more description would help the agent use the result correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% for the single parameter, which is well-described. The description adds value by listing the categories of returned data (state, properties, battery), helping the agent understand what to expect from the output.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves device information covering state, properties, and battery. This distinguishes it from action-oriented siblings like tap or screenshot. The name 'status' reinforces the purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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 siblings. For example, it does not suggest using this before other operations or mention prerequisites like requiring a connected device. The description lacks any directional context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

swipeB

Swipe from (x1,y1) to (x2,y2)

ParametersJSON Schema

Name	Required	Description
`serial`	No	Device serial (optional; required when multiple devices connected)
`x1`	Yes	Start X
`y1`	Yes	Start Y
`x2`	Yes	End X
`y2`	Yes	End Y
`duration`	No	Duration in ms (default 300)

TDQS

B3/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must fully convey behavior. It only indicates a swipe from one point to another, omitting details about duration, continuous motion, or whether the gesture is executed immediately. The default duration (300ms) is in the schema but not mentioned in the description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence, but it is too minimal, sacrificing necessary behavioral and usage context.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (multiple parameters, optional serial and duration, no output schema), the description is insufficient. It does not address what happens after the swipe, return values, or side effects.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, with each parameter described. The tool description adds no extra semantic value beyond echoing the coordinates; it does not explain the significance of duration or serial.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action 'Swipe' with start and end coordinates, which distinguishes it from sibling tools like tap (single point) and long_press (hold).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use swipe versus alternatives like tap or long_press. The description does not mention any preconditions or context for usage.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

tapB

Tap at screen coordinates (device pixels)

ParametersJSON Schema

Name	Required	Description
`serial`	No	Device serial (optional; required when multiple devices connected)
`x`	Yes	X coordinate
`y`	Yes	Y coordinate

TDQS

B3.3/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, and the description lacks behavioral details such as side effects, permissions, or whether it triggers a simple tap. Only states what it does, not how it behaves.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence with no fluff. Efficiently conveys the core action.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Adequate for a simple tap action, but could mention it performs a single quick tap to distinguish from long_press or multi-tap. Lacks return value info, but no output schema expected.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema covers 100% of parameters. Description adds 'device pixels' nuance, but doesn't elaborate beyond schema descriptions. Baseline 3 due to high coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it taps at screen coordinates, using a specific verb and resource. It distinguishes from siblings like swipe or long_press.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use vs alternatives like long_press or type_text. Does not state prerequisites or context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

type_textA

Type text via adb input (spaces become %s)

ParametersJSON Schema

Name	Required	Description	Default
`serial`	No	Device serial (optional; required when multiple devices connected)
`text`	Yes	Text to type

TDQS

A3.9/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It discloses that spaces become %s, a useful encoding detail, but fails to mention other behaviors like device unlock requirements, support for special characters, or potential destructive effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, no fluff, front-loaded with the action. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no annotations, output schema, or nested objects, the description is minimal. It lacks information about return values, error handling, or side effects, making it barely adequate for a 2-parameter tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with clear descriptions for both parameters. The description adds value by explaining the space-to-%s encoding, which is not in the schema, exceeding the baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it types text via adb input and notes that spaces become %s. This is specific about verb and resource, and distinguishes from sibling tools like tap or press_key which handle different actions.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies use when text input is needed, but does not explicitly state when to use this tool versus alternatives like press_key or tap. No guidance on 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.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

13 tool updatesv0.1.0Jun 24, 2026
- First observeddescribe_screen
- First observedlaunch_app
- First observedlist_targets
- First observedlong_press
- First observedopen_url
- First observedpress_back
- First observedpress_home
- First observedpress_key
- First observedscreenshot
- First observedstatus
- First observedswipe
- First observedtap
- First observedtype_text

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

B3.4/5.0

Scored 2026-06-24 02:15 across 13 tools

Disambiguation3/5

Tools are mostly distinct, but press_key overlaps with press_back and press_home, causing potential confusion about which to use. Other tools like tap, long_press, and swipe are clearly differentiated.

Naming Consistency4/5

Most tools follow a verb_noun pattern (e.g., describe_screen, launch_app, press_back). However, 'status' and 'screenshot' deviate as single nouns, and 'long_press' is slightly awkward. Overall, the convention is fairly consistent.

Tool Count5/5

13 tools cover a broad range of Android interaction tasks without being overwhelming. Each tool serves a clear purpose, and the count is well-scoped for device automation.

Completeness4/5

The tool set covers core device operations: launching apps, UI tree parsing, input simulation, and device info. Minor gaps like scrolling or clipboard access are missing but can be worked around with existing tools.

Maintenance

ActivityStale

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

mobilerun
io.github.droidrun
Control real Android and iOS devices with LLM agents — tap, swipe, type, automate flows.
Testing & QA Tools App Automation
38,854
anotherai
dev.anotherai
MCP server for building and testing AI agents with multi-model experimentation and insights.
Agent Orchestration Autonomous Agents Testing & QA Tools
2
Melaya
org.melaya
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.
Agent Orchestration App Automation Browser Automation
1
ClawLinkOAuth
dev.claw-link
MCP server connecting AI agents to 100+ apps (Gmail, Slack, Notion, GitHub) via one-click OAuth.
App Automation Workplace & Productivity
24

Related MCP Servers

scrcpy-mcp
Shell Access File Systems OS Automation
JuanCF
A
license
A
quality
A
maintenance
MCP server that gives AI agents full vision and control over Android devices via ADB and scrcpy. Supports screenshots, input, apps, UI automation, shell, files, and clipboard.
Updated 25 days ago (2026-08-21 01:47 UTC)
38
231 npm
93
MIT
Android MCP Server
Developer Tools Testing & QA Tools OS Automation
huarangmeng
F
license
A
quality
D
maintenance
An MCP server designed for Android development, enabling AI assistants to directly control Android devices for screenshots, UI analysis, app management, and more.
Updated 6 months ago (2026-03-12 07:43 UTC)
19
-
android-mcp
OS Automation Shell Access Developer Tools
qalvinahmad
A
license
A
quality
C
maintenance
An MCP server that gives AI agents full control of Android devices and emulators through plain ADB — no companion APK, no extra daemon, no telemetry.
Updated 2 months ago (2026-07-04 14:04 UTC)
26
8 npm
2
MIT
AutoMobile
Testing & QA Tools Autonomous Agents Developer Tools
kaeawc
A
license
Not graded
quality
A
maintenance
An MCP server that enables AI agents to control Android and iOS devices via natural language, using platform tools like adb and simctl.
Updated 2 days ago (2026-09-12 16:50 UTC)
2,060 npm
47
Apache 2.0