Skip to main content
Glama
Sign In
waydroid-mcp

waydroid-mcp

by TechyAditya
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

input

Simulate taps, long presses, swipes, text entry, and key presses on Waydroid displays to control Android apps, targeting coordinates or UI elements for automated testing and debugging.

Instructions

Touch and keyboard input on a display, in display pixels. tap and long_press take x and y, or element: text, description or resource id to find in the UI tree. swipe goes from x,y to x2,y2 (swipe up to scroll down). text types into the focused field, so tap the field first; key sends a key such as BACK, ENTER, TAB, HOME or DEL.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "action": "<action>"
    },
    "name": "input"
  }
}

Input Schema

NameRequiredDescriptionDefault
xNo
yNo
x2No
y2No
keyNo
textNo
actionYes
elementNoFor tap and long_press: element text, content description or resource id.
packageNoApp to act on. An app in its own window or hidden display is found by package; otherwise Waydroid's main display is used.
display_idNoAndroid display id instead of a package; 0 is Waydroid's main display.
duration_msNoSwipe or long-press length. Defaults: 300 and 800.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

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 the full burden. It discloses meaningful behavior: coordinates are in display pixels, element targeting uses the UI tree, swipe direction is reversed relative to scroll direction, and text goes into the focused field. It does not discuss permissions, failure behavior when an element is not found, timing/synchronization, or targeting via package/display_id.

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?

The description is a dense, front-loaded paragraph with no wasted wording. It moves from the general purpose to action-specific semantics and important usage constraints in a compact form.

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 an 11-parameter input tool with no annotations or output schema, the description gives enough context to select the right action and understand coordinate/element targeting, swipe behavior, text focus requirements, and key tokens. Remaining gaps, such as error behavior and explicit package/display targeting, are partly covered by schema descriptions and are not fatal for basic invocation.

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 description coverage is low at 36%, so the description must compensate. It adds clear semantics for action, x/y, x2/y2, element, text, and key beyond the schema, while package, display_id, and duration_ms are documented in the schema itself. The description still does not explain package/display targeting or duration defaults, but overall it meaningfully clarifies the core input parameters.

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 that this tool performs touch and keyboard input on a display, using display pixels. It distinguishes the supported action types (tap, long_press, swipe, text, key), but it does not explicitly name or contrast sibling tools such as app_action or shell.

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 gives useful per-action usage details, including that text requires tapping the field first, that element lookup works for tap/long_press, and that swipe up scrolls down. However, it does not say when to use this tool rather than alternatives like app_action or shell, nor does it describe any when-not conditions.

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

Deploy Server

Other Tools