Skip to main content
Glama

Robot Actions — Remote Device Control

by com.robotactions.test
OverviewDiscussionsAdmin

device_list_apps

List the APPS installed on an Android device — things with a launcher icon, user and system alike, so Settings and Chrome are included. Installed packages that are not apps (providers, accessibility services, Bluetooth stacks) are excluded: a Pixel reports 275 installed packages of which 23 are apps. Set userOnly to drop preinstalled apps, or includeNonLaunchable for the raw package list.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
udidYesDevice serial number (UDID)
userOnlyNoOnly user-installed apps, excluding preinstalled ones (default: false)
includeNonLaunchableNoInclude installed packages with no launcher activity — providers, services, OEM stubs. Default false.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / includeNonLaunchable / description
      Previous value: -"Include installed packages with no launcher activity — providers, services, OEM stubs. Default false."New value: +"Include installed packages with no launcher activity — providers, services, OEM stubs. Default false."
  2. Changed1 schema field changed
    • changedInput schema / properties / includeNonLaunchable / description
      Previous value: -"Include installed packages with no launcher activity — providers, services, OEM stubs. Default false."New value: +"Include installed packages with no launcher activity — providers, services, OEM stubs. Default false."
  3. Changed2 schema fields changed
    • addedInput schema / properties / includeNonLaunchable
      Added value: +{
+  "description": "Include installed packages with no launcher activity — providers, services, OEM stubs. Default false.",
+  "type": "boolean"
+}
    • changedInput schema / properties / userOnly / description
      Previous value: -"Only list user-installed apps, excludes system apps (default: true)"New value: +"Only user-installed apps, excluding preinstalled ones (default: false)"
  4. First observed

TDQS

A4.7/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 disclosure burden. It goes beyond the name/schema by explaining inclusion criteria, exclusion of providers/accessibility services/Bluetooth stacks, and gives a concrete Pixel example (275 packages, 23 apps), which meaningfully sets expectations for the returned list.

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 definition is compact and well-structured: definition first, then a clarifying example, then parameter guidance. Every sentence earns its place and the text is front-loaded with the most important information.

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?

Given the tool's low complexity, clear schema, and the absence of an output schema, this is complete. It tells the agent what the tool lists, what is excluded, and how the optional flags alter behavior, so an agent can invoke it correctly without further inference.

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?

The input schema already documents all three parameters at 100% coverage, providing the baseline of 3. The description adds value beyond the schema by translating userOnly and includeNonLaunchable into practical behavioral terms (drop preinstalled apps, raw package list) and explaining the app-vs-package distinction that gives the parameters meaning.

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 a specific verb and resource: "List the APPS installed on an Android device." It then clarifies the exact definition (launcher-icon apps, user and system alike) and explicitly contrasts with installed packages, making it distinct from generic app listing tools.

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 provides clear functional context and parameter-level usage guidance: "Set userOnly to drop preinstalled apps, or includeNonLaunchable for the raw package list." It does not explicitly name sibling alternatives or state when not to use this tool, so it misses the top tier for exclusion guidance.

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

All Robot Actions — Remote Device Control toolsInspect
Try in Browser
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

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources