Skip to main content
Glama
mobile-debug-mcp

mobile-debug-mcp

start_log_stream

Stream live app logs on Android or iOS for debugging. Target a package or bundle ID and filter by device, platform, session, and log level.

Instructions

Start streaming logs for a target application on Android or iOS. For Android this uses adb logcat --pid=; for iOS it streams xcrun simctl spawn <device> log stream with a predicate.

Input Schema

NameRequiredDescriptionDefault
levelNoerror
deviceIdNoDevice Serial (Android) or UDID (iOS). Defaults to connected/booted device.
platformNoandroid
sessionIdNoSession identifier for the log stream
packageNameYesAndroid package name or iOS bundle id

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.34.0
    • addedInput schema / allOf
      Added value: +[
      +  {
      +    "not": {
      +      "required": [
      +        "expectedState"
      +      ]
      +    }
      +  }
      +]
  2. First observedv0.31.0

TDQS

B3.2/5.0
Behavior2/5

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

No annotations exist, so the description carries the full burden, yet it only discloses the underlying commands. It says nothing about the stream lifecycle (does it keep running, who terminates it, must stop_log_stream be called?), how the streamed output is retrieved, whether the sessionId is created here or supplied by the caller, or rate/cost characteristics.

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 action, with the platform-specific mechanics as supporting detail. No filler or redundancy.

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

Completeness2/5

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

This is a stateful, long-running operation starter with 5 parameters, no annotations, and no output schema. The description omits stream lifecycle, session handling, and how to consume or terminate the stream, which are the pieces an agent most needs before calling it.

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 coverage is 60% and the description adds some real meaning by linking Android `latest` to packageName resolving to a PID, implying the app must be running, and noting iOS uses a device plus predicate. It says nothing about level filtering, sessionId, or the default platform behavior, leaving part of the gap unfilled.

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 specific verb and resource ('Start streaming logs') and scopes it to an Android/iOS target application, which distinguishes it reasonably well from siblings like get_logs and read_log_stream. It stops short of naming those siblings, so the boundary is inferred rather than stated.

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 only implied: an agent can guess this is for live log monitoring while an app runs. There is no explicit when-to-use versus get_logs/read_log_stream, no prerequisite that the app must be running, and no mention of pairing with stop_log_stream.

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