mobilerun-mcp

List Apps

list_apps

Fetch installed applications on a connected device, optionally including system apps, plus protected apps on Mobilerun Cloud. Use it to inventory available apps before launching or managing them.

Instructions

List installed apps (user apps only unless include_system_apps=true). include_protected_apps is honoured on Mobilerun Cloud devices only (as in mobilerun-core).

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": "list_apps"
  }
}

Input Schema

Name	Required	Description	Default
`device`	No
`system`	No
`include_system_apps`	No
`include_protected_apps`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 27, 2026

TDQS

A3.6/5.0

Behavior3/5

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

With no annotations, the description carries full burden and does disclose the default filter (user apps only) and a platform-dependent limitation (include_protected_apps only honoured on Mobilerun Cloud). It omits other relevant behavior: whether a device must be connected, whether the result set is paginated, and error behavior on unreachable devices.

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?

Two short sentences, both front-loaded with the most decision-relevant facts (default scope, then the platform caveat). No filler, though the protected-apps aside is parenthetical and slightly cryptic in its mobilerun-core reference.

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?

An output schema exists, so return values need no explanation. For a four-parameter read-only listing tool, the description covers the default filtering behavior and the one platform-specific constraint; the remaining gap around the `device` parameter is minor given the schema's anyOf/default null structure.

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 0%, so all four parameters lack inline documentation, and the description compensates for only part of that: it explains include_system_apps and include_protected_apps semantics. The `device` parameter (format/selection) is never addressed, and the relationship between the `system` and `include_system_apps` booleans is left unreconciled despite looking redundant.

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?

States a clear verb+resource ('List installed apps') and immediately qualifies the default scope (user apps only). It is distinguishable from siblings like lookup_app, install_app, and list_app_deeplinks, though it never names them explicitly.

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 the condition that changes default behavior (include_system_apps=true) and notes the cloud-only constraint for protected apps, which is useful operational guidance. It does not, however, say when an agent should prefer this over lookup_app or list_app_deeplinks, leaving sibling selection implied.

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

Deploy Server