Skip to main content
Glama
Sign In
mobile-debug-mcp

mobile-debug-mcp

by clivejefferies
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

start_system_trace

Start a bounded Android Perfetto or iOS simulator Time Profiler recording and get an owned trace ID after readiness. Stop it to retrieve a local trace artifact or cancel to discard it.

Instructions

Start bounded Android Perfetto or iOS simulator Time Profiler recording, returning an owned trace_id after readiness. iOS requires explicit deviceId and running appId. Run an existing journey with systemTraceId, then stop to retrieve a local artifact or cancel to discard. Traces can contain sensitive system metadata, logs and paths; local user-managed retention, no upload.

Input Schema

NameRequiredDescriptionDefault
appIdNoiOS only: running development app bundle identifier; required for iOS start.
deviceIdNo
platformYes
templateNoiOS only. Default Time Profiler; initial simulator support is Time Profiler only.
durationMsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.35.0
    • addedInput schema / oneOf
      Added value: +[
+  {
+    "not": {
+      "anyOf": [
+        {
+          "required": [
+            "appId"
+          ]
+        },
+        {
+          "required": [
+            "template"
+          ]
+        }
+      ]
+    },
+    "properties": {
+      "platform": {
+        "const": "android"
+      }
+    }
+  },
+  {
+    "properties": {
+      "platform": {
+        "const": "ios"
+      }
+    },
+    "required": [
+      "deviceId",
+      "appId"
+    ]
+  }
+]
    • addedInput schema / properties / appId
      Added value: +{
+  "description": "iOS only: running development app bundle identifier; required for iOS start.",
+  "minLength": 1,
+  "pattern": "^[a-zA-Z0-9._-]+$",
+  "type": "string"
+}
    • addedInput schema / properties / template
      Added value: +{
+  "description": "iOS only. Default Time Profiler; initial simulator support is Time Profiler only.",
+  "enum": [
+    "System Trace",
+    "Time Profiler",
+    "Animation Hitches",
+    "Hangs"
+  ],
+  "type": "string"
+}
  2. Addedv0.34.0

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations, the description carries the full load and does substantial work: it discloses that recording is bounded, that the trace_id is 'owned' and returned only after readiness, and that sub-workflows consume it via systemTraceId. It also flags the sensitive-data profile (system metadata, logs, paths) and the local, non-uploaded retention model. Gaps remain around whether recording auto-stops at durationMs, whether concurrent traces are permitted, and required platform permissions.

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?

Three dense sentences ordered as capability, workflow, then risk/retention. No filler, no restatement of the tool name, and the most decision-relevant facts (platform split, lifecycle, data sensitivity) are front-loaded.

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?

There is no output schema, and the description correctly explains that a trace_id is returned after readiness and that an artifact is retrieved later via stop, which covers the return contract adequately. For a stateful, two-platform recording tool it could still be clearer about auto-stop behavior at durationMs and whether a trace must be stopped or cancelled before starting another.

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?

Schema coverage is only 40% (deviceId, platform and durationMs are undocumented in the schema), but the description compensates by tying deviceId and appId to iOS as explicit preconditions, implying platform-conditional requirements. 'Bounded' gestures at durationMs without stating the 1s-120s range or 30s default, and the template restriction is left to the schema's enum description.

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?

States a specific verb (start) plus the exact resource and platform scope ('bounded Android Perfetto or iOS simulator Time Profiler recording'), and names the owned return value (trace_id). This clearly separates it from siblings such as get_system_trace_status, stop_system_trace and cancel_system_trace without requiring the schema.

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?

Gives concrete workflow guidance: run an existing journey with systemTraceId, then stop to retrieve the artifact or cancel to discard, which resolves the stop-vs-cancel ambiguity. It also states the iOS precondition (deviceId plus a running appId). It stops short of naming a when-not-to-use condition or pointing at get_system_trace_capabilities for capability checks.

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