Skip to main content
Glama
Sign In
waydroid-mcp

waydroid-mcp

by TechyAditya
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

files

Copy data between the host and Android: push a host path to an Android path, or pull an Android path back to the host, including debuggable app-private data when a package is given.

Instructions

Copies files between the host and Android: push a host path to an Android path, or pull an Android path to the host. App-private files under /data/data are readable with pull only for debuggable apps (through run-as), given package.

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>",
      "host_path": "<host_path>",
      "android_path": "<android_path>"
    },
    "name": "files"
  }
}

Input Schema

NameRequiredDescriptionDefault
actionYes
packageNoFor pull from a debuggable app's private directory.
host_pathYes
android_pathYes

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 behavioral burden. It does disclose a genuine constraint (debuggable-app-only, run-as mediation) that an agent could not infer otherwise, but it says nothing about overwriting existing files, whether directories are supported/recursive, failure modes, or permissions on the host side.

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?

Two sentences, front-loaded with the core operation and followed by the one non-obvious constraint. Every clause earns its place with no redundancy.

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?

For a 4-parameter mutation tool with no annotations and no output schema, the description covers purpose, directionality, and one access restriction but omits overwrite semantics, directory support, and any indication of success/failure reporting. Adequate to invoke, not fully sufficient to predict outcomes.

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 only 25%, so the description should compensate more. It does clarify the role of host_path vs android_path implicitly through the push/pull directions, and explains `package` for private pulls, but leaves unclear whether paths may be directories, how missing parents are handled, or what form paths take.

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 names a concrete verb and resource ('Copies files between the host and Android') and then spells out both directions (push host→Android, pull Android→host). It is immediately clear what the tool does and there is no sibling in the catalog that duplicates file transfer, so no explicit differentiation is needed.

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

Usage Guidelines4/5

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

It tells the agent which `action` value maps to which direction of transfer, and adds a real precondition: private /data/data paths are only pullable for debuggable apps via run-as, with `package` supplied. There are no explicit exclusions (e.g., what to do for non-debuggable apps), which keeps it below a 5.

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