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

mobile-debug-mcp

by clivejefferies
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

wait_for_screen_change

Detect a screen transition by waiting until the current fingerprint differs from a previous one, helping synchronize uncertain navigation timing.

Instructions

Purpose: Detect that a screen transition has occurred by waiting for the current fingerprint to differ from a previous fingerprint.

Capabilities:

  • Synchronization for uncertain navigation timing

  • Detection that something changed on screen

Constraints:

  • Does not verify correctness of the resulting state

  • Must not be used alone to confirm action success when an applicable expect_* tool exists

  • For backend/API activity without a visible UI change, pass the runtime action_type into classify_action_outcome and collect network evidence only if the result remains ambiguous

Recommended Usage:

  1. Capture or define the expected outcome

  2. Call an action tool

  3. Use wait_for_screen_change when transition timing is uncertain

  4. Follow with expect_screen when the expected destination is known

Input Schema

NameRequiredDescriptionDefault
deviceIdNoOptional device id/udid to target
platformNoOptional platform override (android|ios)
timeoutMsNoTimeout in ms to wait for change (default 5000)
pollIntervalMsNoPolling interval in ms (default 300)
previousFingerprintYesThe fingerprint to compare against (required)

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

A3.9/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 disclosure burden, and it does state key traits: it does not verify state correctness and it is a pure timing primitive. However, it never says what a successful wait yields (a new fingerprint? a boolean?), nor what happens on timeout, which is the primary failure mode for a 5s polling tool.

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?

Sectioned into Purpose/Capabilities/Constraints/Recommended Usage, with the core definition leading. Content is dense and largely earns its place, though a few capability bullets restate the purpose sentence, adding minor redundancy for a relatively simple wait primitive.

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?

For a one-required-parameter wait tool with no annotations and no output schema, the definition covers purpose, constraints, sibling alternatives, and a call workflow. The one substantive gap is the return contract, which must be inferred since no output schema exists to cover 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 description coverage is 100%, with all five parameters including the required previousFingerprint and the timeout/poll defaults documented in the schema itself. The description adds only the high-level notion of comparing a prior fingerprint, no format, sourcing, or enum guidance beyond what the schema already provides, so baseline 3 applies.

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 gives a precise verb+resource: wait for the current fingerprint to differ from a previous one, detecting a screen transition. An agent can tell this is a synchronization primitive rather than a verification tool. It does not, however, distinguish itself from the near-identical siblings wait_for_ui_change and wait_for_ui, leaving ambiguity among the wait family.

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

Usage Guidelines5/5

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

Explicit when-to-use ('transition timing is uncertain'), when-not-to-use ('must not be used alone to confirm action success when an applicable expect_* tool exists'), and named alternatives (expect_screen, classify_action_outcome). The numbered recommended workflow places the tool between an action call and a follow-up assertion.

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