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

mobile-debug-mcp

by clivejefferies
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

expect_element_visible

Verify a target mobile UI element is visible after an action to confirm the expected UI outcome, returning deterministic success or failure for reliable checks.

Instructions

Purpose: Deterministically verify that the intended UI outcome of an action has occurred by confirming a target element is visible.

Inputs:

  • selector: required selector used to resolve the target element

  • element_id: optional previously resolved element identifier used only as context

Output Structure:

  • success: true when the element is visible

  • selector: selector used for verification

  • element_id: resolved element identifier when available

  • element: minimal resolved element info when visible

  • failure_code: TIMEOUT or UNKNOWN when verification fails

  • retryable: true when failure_code=TIMEOUT

Recommended Usage:

  1. Define the expected element state before executing the action

  2. Resolve the target element or triggering control

  3. Call an action tool such as tap_element

  4. If needed, wait for UI availability using wait_for_*

  5. Call expect_element_visible as the final verification step

  6. If success=false, follow the action tool retry guidance

Verification Guidance:

  • Primary and authoritative verification tool for expected element appearance or visibility

  • Use this when the screen should stay the same but the UI should reveal or update a specific element

  • selector is the primary input; element_id is an optional optimization only

  • The tool resolves the selector internally when needed

Constraints:

  • Returns structured binary success/failure only

  • Must not rely on natural-language interpretation or reasoning

Failure Handling:

  • TIMEOUT → retry verification once or retry the action after re-resolving

  • UNKNOWN → capture a snapshot and stop

Input Schema

NameRequiredDescriptionDefault
deviceIdNoOptional device serial/udid
platformNoOptional platform override
selectorYes
element_idNoOptional previously resolved element identifier.
timeout_msNo
poll_interval_msNo

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

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 burden and does so: it documents the exact output structure (success, selector, element_id, element, failure_code, retryable), states the tool resolves the selector internally, declares the result is structured binary success/failure with no natural-language reasoning, and gives per-failure-code retry semantics.

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 and front-loaded with purpose first, which makes it scannable. There is some redundancy — the 'Verification Guidance' bullet restates the purpose, and 'Returns structured binary success/failure only' repeats the Output Structure section — but the overall length is justified for a six-parameter verification tool.

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 fills that gap by enumerating the return fields and failure codes. It also covers the nested selector case by declaring internal resolution. Minor incompleteness remains around timing parameters and the shape of the returned 'element' object.

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 50%, and the description compensates for the important parts: selector is the primary required input, element_id is an optional optimization/context only, and selector resolution happens internally. However, deviceId, platform, timeout_ms, and poll_interval_ms are never explained in prose, leaving a real gap at this coverage level.

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 and outcome: deterministically verify that an action's intended UI outcome occurred by confirming a target element is visible. It also explicitly separates itself from siblings, calling itself the 'primary and authoritative verification tool for expected element appearance or visibility' and contrasting with wait_for_ui/wait_for_* and screen-level expectations.

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?

Provides an explicit six-step workflow (define expected state, resolve element, act, wait, verify, handle failure) and a clear when-to-use condition: 'Use this when the screen should stay the same but the UI should reveal or update a specific element.' Failure handling per failure code is spelled out (TIMEOUT → retry, UNKNOWN → snapshot and stop).

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