Skip to main content
Glama
Sign In
waydroid-mcp

waydroid-mcp

by TechyAditya
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

start_activity

Launches an Android activity by URL, deep link, or exact component, waits for it to draw, and returns am start -W launch timing.

Instructions

Starts an activity with an intent on a display, and waits for it to draw: open a URL or deep link (url), or an exact component such as com.android.settings/.Settings. Returns am start -W's timing (TotalTime is the launch time in ms).

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "start_activity"
  }
}

Input Schema

NameRequiredDescriptionDefault
urlNoData URI for an ACTION_VIEW intent, such as https://example.com or myapp://path.
actionNoIntent action. Default: android.intent.action.VIEW with url, otherwise MAIN.
extrasNoString extras, passed with --es.
packageNoApp to act on. An app in its own window or hidden display is found by package; otherwise Waydroid's main display is used.
componentNopackage/activity to start.
display_idNoAndroid display id instead of a package; 0 is Waydroid's main display.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.5/5.0
Behavior3/5

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

With no annotations at all, the description carries the full behavioral burden. It does disclose two important traits: the call blocks until the activity draws, and it surfaces `am start -W` timing with TotalTime as the launch time in ms. It says nothing about failure behavior, timeouts, required permissions/root, or what happens when the target never draws, which is a meaningful gap for an unannotated tool.

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?

A single front-loaded sentence that leads with the blocking behavior and then enumerates the two ways to target an activity, followed by the return-value note. Dense but no filler; the nested parentheticals make it slightly harder to scan but nothing is wasted.

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 6-parameter, all-optional tool with no output schema, the description covers the primary flows and explains the return payload the agent will see. Remaining gaps (extras handling, display_id interplay, error/timeout outcomes) are partly covered by the rich schema, so the definition is largely sufficient.

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 the schema already explains url, action defaults, extras, package, component, and display_id. The description adds only marginal meaning beyond that, mainly reinforcing that `url` maps to a deep-link/ACTION_VIEW intent and `component` takes package/activity form. Baseline 3 is appropriate here.

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 uses a precise verb-plus-resource ('Starts an activity with an intent on a display') and then concretizes it with two invocation modes: a URL/deep link or an exact component like com.android.settings/.Settings. It does not, however, differentiate itself from the sibling launch_app, which appears to cover adjacent launch behavior, so an agent must guess which one to pick.

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 through the two supported modes (url for ACTION_VIEW, component for an exact activity) and the note that it waits for the draw. There is no explicit when-to-use versus when-not, and no mention of when launch_app, app_action, or shell would be preferable.

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