Skip to main content
Glama
zifanersuotang

Codex Android MCP

Android tap Element

android_tap_element
Destructive

Tap a UI element by its resource-id or visible label/text on an Android device, bypassing coordinate-based taps and duplicate selectors. Confirm success with expected text appearing or disappearing.

Instructions

Tap a view on a connected Android device or emulator by IDENTITY instead of raw coordinates: identifier matches the resource-id, label matches the text OR the content-desc (Android splits what one accessibility label holds elsewhere, so one selector covers both). The selector matches exactly first, then case-insensitively as a substring. Nested duplicates — a list row mirroring its text onto a child TextView inside a clickable container — collapse to ONE target, the outermost clickable node of that chain; if several distinct nodes still match, the error lists every candidate with its text, resource-id and bounds. Only on-screen, enabled nodes are tapped: when the only match is scrolled out of view or disabled the tool FAILS with an actionable message instead of tapping dead coordinates (allow_offscreen=true taps an off-screen match anyway; disabled nodes always refuse). The tap lands on the node center, then after ~300 ms a fresh screenshot is captured with the same summary shape as android_interact. To CONFIRM the tap landed, pass expect_text (text that should appear) or expect_gone (text that should disappear) — the tool polls the screen OCR for ~4 s and reports expected.matched in the SAME call. Do NOT screenshot-and-compare pixels to check whether a tap worked; use these assertions instead.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
labelNoVisible text or content-desc to match, e.g. "Network & internet". Exact match first, then case-insensitive substring. Icon-only buttons carry a content-desc but no text.
serialNoTarget device serial from android_devices. Defaults to the currently streamed device, else the only connected one.
identifierNoresource-id to match, e.g. "com.android.settings:id/search_action_bar" (the ":id/name" tail is usually enough as a substring). Exact match first, then case-insensitive substring.
expect_goneNoOptional text that should DISAPPEAR after the tap. Mutually exclusive with expect_text; reported as expected.matched (true = the text is gone).
expect_textNoOptional text that should APPEAR after the tap. The tool polls screen OCR for up to ~4 s and reports expected.matched — one round trip instead of tap + screenshot + manual compare.
allow_offscreenNoAllow tapping a node whose bounds lie outside the screen (a recycled list row that uiautomator still reports) — the tap lands at the recorded coordinates whatever is displayed there. Default false: such a match fails with a scroll-it-into-view error. Disabled nodes are always refused, regardless of this flag.
Behavior5/5

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

Annotations only indicate destructive=true and non-readonly. The description adds extensive behavioral details: exact-match-then-substring matching, duplicate collapse to outermost clickable node, on-screen/enabled restrictions, allow_offscreen behavior, tap on center, ~300ms screenshot delay, and the polling mechanism with expect_text/expect_gone. It even specifies failure behaviors (actionable message) and disabled-node refusal. This far exceeds what annotations provide.

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 long but every sentence serves a purpose, covering matching, duplicate handling, failure modes, and assertion guidance. It is structured logically: purpose, matching rules, tap behavior, confirmation methods. While verbose, the complexity justifies the length; it is front-loaded with the core purpose and avoids fluff.

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

Completeness5/5

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

With no output schema, the description explains the return shape (screenshot summary like android_interact, expected.matched field), covers error scenarios, and gives actionable alternatives. It fully equips an agent to invoke the tool correctly, including edge cases (offscreen, disabled, duplicate matches, assertion polling). Nothing important is missing.

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?

The input schema has 100% coverage with detailed descriptions for every parameter (e.g., exact match then substring, default serial logic, mutually exclusive expect params, allow_offscreen semantics). The tool description reinforces some of this but adds little new per-parameter meaning. Since the schema already carries the load, a baseline 3 is appropriate; no major gaps exist.

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 states a specific verb (tap) and resource (a view on an Android device/emulator) and explicitly differentiates from raw-coordinate approaches by saying 'by IDENTITY instead of raw coordinates'. It also names the matching criteria (resource-id, label, content-desc) and is clearly distinct from siblings like android_tap_row or android_tap_text.

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 implies usage context: it's for tapping by identity rather than coordinates, and it explicitly instructs how to confirm a tap using expect_text/expect_gone instead of image comparison. However, it doesn't explicitly name sibling alternatives (e.g., android_tap_row) or state when NOT to use this tool, leaving some inference. Still, the context is clear enough for correct selection.

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/zifanersuotang/codex-android-mcp'

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