Skip to main content
Glama
Sign In
waydroid-mcp

waydroid-mcp

by TechyAditya
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

launch_app

Open Android apps in Waydroid with custom window, hidden display, size, DPI, or cold-start options, returning the display ID for input, screenshots, and UI inspection.

Instructions

Opens an app. window opens it in its own desktop window and hidden on an off-screen display with no window (both need waydroid-app-displays; hidden defaults to 1080x2340 at 440 dpi). waydroid uses Waydroid's own window. size fixes the Android display in pixels and dpi its density (dp width = pixels * 160 / dpi), so 720x1280 at 320 dpi is a 360 dp phone. Launching an open app again applies the new options, and options left out go back to the defaults. Returns the display id that input, screenshot and ui_tree act on; it changes each time the app is closed and opened.

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": {
      "package": "<package>"
    },
    "name": "launch_app"
  }
}

Input Schema

NameRequiredDescriptionDefault
dpiNo
modeNoDefault: window when the waydroid-app-displays service is running, otherwise waydroid.
sizeNoAndroid display size WIDTHxHEIGHT in pixels, such as 1080x2340.
packageYes
restartNoForce-stop the app first, for a cold start.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.5/5.0
Behavior5/5

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

With no annotations, the description carries the full behavioral burden and does so well: it discloses the waydroid-app-displays dependency, hidden-mode defaults, size/dpi interpretation, relaunch reset semantics, and the volatile display id returned for input, screenshot, and ui_tree.

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 front-loaded with the core action, then uses compact parentheticals and examples for the mode and sizing details. Every clause contributes useful operational context.

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

Completeness5/5

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

There is no output schema, yet the description explains the important return value and how it changes across launches. For a five-parameter tool with no annotations, it provides enough context to invoke it correctly and interpret the result.

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 only 60%, but the description meaningfully explains mode behavior, size and dpi relationships, hidden-display defaults, and what happens when options are omitted on relaunch. The package and restart parameters rely on the schema, but the key behavioral parameters are clarified.

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 opens with the specific action 'Opens an app' and then distinguishes the available display modes. An agent can immediately identify the tool's purpose and scope.

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?

Usage is implied by the explanation of modes and relaunch behavior, but there is no explicit when-to-use guidance or comparison against alternatives. The mode semantics help selection without fully guiding tool choice.

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