Skip to main content
Glama
clivejefferies

mobile-debug-mcp

expect_element_visible

Verify that a target UI element becomes visible after an action, confirming the intended outcome with deterministic binary success or failure.

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

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

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

No annotations are provided, so the description carries the full burden. It discloses internal resolution, deterministic binary output, failure codes (TIMEOUT, UNKNOWN), and constraints (no natural-language interpretation). It could mention that the tool is read-only.

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?

The description is structured with clear headers (Purpose, Inputs, Output Structure, etc.) and is front-loaded. However, it is somewhat verbose and could be more concise without losing clarity.

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?

Given the lack of output schema, the description covers purpose, usage, behavior, output structure, and failure handling. It does not detail the nested selector properties (text, contains, etc.) but provides sufficient context for an agent to understand the tool's role.

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 50%. The description adds meaning for selector and element_id (e.g., 'required selector used to resolve the target element') but does not explain deviceId, platform, timeout_ms, or poll_interval_ms. Parameters with defaults are not described, leaving gaps.

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?

The description clearly states the tool's purpose: 'deterministically verify that the intended UI outcome of an action has occurred by confirming a target element is visible.' It uses specific verb-resource combination and distinguishes from sibling tools like expect_screen and expect_state.

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?

The description provides a recommended usage workflow (steps 1-6), verification guidance, and failure handling. It tells when to use ('primary and authoritative verification tool') but does not explicitly state when not to use. The sibling list provides context.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/clivejefferies/mobile-debug-tools'

If you have feedback or need assistance with the MCP directory API, please join our Discord server