Skip to main content
Glama
mobile-debug-mcp

mobile-debug-mcp

type_text

Types text into the focused Android input field, with optional UI-state checks before dispatch to avoid entering text into the wrong screen.

Instructions

Purpose: Type text into the currently focused Android input field.

Inputs:

  • text

  • platform/deviceId (optional)

Output Structure:

  • action_id, timestamp (ISO 8601), action_type

  • lifecycle_state: post-dispatch lifecycle state (pending_verification or failed)

  • source_module: runtime source of the action envelope

  • target.selector = { text }

  • success = true when text input was dispatched

  • failure_code/retryable when dispatch fails

  • ui_fingerprint_before/ui_fingerprint_after when available

Recommended Usage:

  1. Resolve or focus the target input first

  2. Call type_text

  3. If needed, wait for UI stabilization using wait_for_*

  4. Verify with expect_element_visible or expect_screen, depending on the intended outcome

Verification Guidance:

  • Prefer verifying the next expected element or screen state instead of inferring success from the text action alone

  • Follow RESOLVE → ACT → WAIT (if needed) → EXPECT

  • Do not use wait_for_* alone as final verification when an applicable expect_* tool exists

Failure Handling:

  • TIMEOUT → retry once

  • UNKNOWN → re-focus the input or capture a snapshot

Conditional input: optionally supply expectedState { snapshotSessionId, snapshotRevision, timeoutMs? } from a successful get_ui_tree on the same explicit platform/deviceId. A fresh normalized UI-tree check runs immediately before input, even with verification disabled. PRECONDITION_FAILED or PRECONDITION_UNAVAILABLE means no input was dispatched; inspect condition evidence and re-observe before deciding what to do next. Compact failures summarize the fresh condition evidence; use get_interaction_diagnostics with the returned diagnostics reference for the retained UI tree. This is not atomic with OS input delivery. Compact results summarize observations, condition trees, state deltas and readiness probe evidence within a byte budget. Use get_interaction_diagnostics with the returned diagnostics session_id/result_id to retrieve the original result without replaying input. Debug output is unchanged. Results include device_readiness with timestamped device blocker evidence. Android reports supported power/keyguard signals; iOS signals may be unknown or explicitly unsupported. Launch/input dispatch success does not establish app visibility or input readiness. No automatic unlock or wake is performed.

Input Schema

NameRequiredDescriptionDefault
textYesThe text to type
deviceIdNoDevice Serial/UDID. Defaults to connected/booted device.
platformNoPlatform to type on (currently only android supported)
responseModeNodebug
expectedStateNo
actionTimeoutMsNoDispatch budget in milliseconds, clamped to 100–30000.
verificationModeNofull
verificationTimeoutMsNoLight observation budget in milliseconds, clamped to 100–60000.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv0.34.0
    • addedInput schema / allOf
      Added value: +[
      +  {
      +    "if": {
      +      "required": [
      +        "expectedState"
      +      ]
      +    },
      +    "then": {
      +      "properties": {
      +        "deviceId": {
      +          "minLength": 1,
      +          "not": {
      +            "enum": [
      +              "booted",
      +              "default"
      +            ]
      +          },
      +          "pattern": "\\S",
      +          "type": "string"
      +        },
      +        "platform": {
      +          "enum": [
      +            "android"
      +          ]
      +        }
      +      },
      +      "required": [
      +        "platform",
      +        "deviceId"
      +      ]
      +    }
      +  }
      +]
    • addedInput schema / properties / actionTimeoutMs
      Added value: +{
      +  "description": "Dispatch budget in milliseconds, clamped to 100–30000.",
      +  "type": "integer"
      +}
    • addedInput schema / properties / expectedState
      Added value: +{
      +  "additionalProperties": false,
      +  "properties": {
      +    "snapshotRevision": {
      +      "maximum": 9007199254740991,
      +      "minimum": 1,
      +      "type": "integer"
      +    },
      +    "snapshotSessionId": {
      +      "minLength": 1,
      +      "type": "string"
      +    },
      +    "timeoutMs": {
      +      "default": 15000,
      +      "maximum": 60000,
      +      "minimum": 100,
      +      "type": "integer"
      +    }
      +  },
      +  "required": [
      +    "snapshotSessionId",
      +    "snapshotRevision"
      +  ],
      +  "type": "object"
      +}
    • addedInput schema / properties / responseMode
      Added value: +{
      +  "default": "debug",
      +  "enum": [
      +    "compact",
      +    "debug"
      +  ],
      +  "type": "string"
      +}
    • addedInput schema / properties / verificationMode
      Added value: +{
      +  "default": "full",
      +  "enum": [
      +    "none",
      +    "light",
      +    "full"
      +  ],
      +  "type": "string"
      +}
    • addedInput schema / properties / verificationTimeoutMs
      Added value: +{
      +  "description": "Light observation budget in milliseconds, clamped to 100–60000.",
      +  "type": "integer"
      +}
  2. First observedv0.31.0

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations supplied, the description carries the full burden and does so: it discloses that no automatic unlock/wake occurs, that dispatch success does not imply app visibility or input readiness, that the operation is not atomic with OS input delivery, and what PRECONDITION_FAILED/PRECONDITION_UNAVAILABLE mean for whether input was sent. It also enumerates the result envelope fields (lifecycle_state, source_module, ui_fingerprint_*) and device_readiness caveats.

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?

Well structured with labeled sections and the purpose front-loaded, and nearly all of the length buys real information for an 8-parameter, annotation-free mutation tool. There is some redundancy, notably the get_interaction_diagnostics retrieval path being explained twice in slightly different words, which could be collapsed.

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?

Given no annotations, no output schema, and a nested expectedState object, the definition still covers return shape, precondition semantics, failure codes, verification expectations, and device-readiness caveats. An agent has everything needed to call it correctly and interpret the result without opening other tools.

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?

At 63% schema coverage the description usefully explains expectedState (snapshotSessionId/snapshotRevision sourced from a successful get_ui_tree, a fresh UI-tree check run immediately before input even when verification is disabled) and the compact-vs-debug response mode tradeoff, which the schema only hints at. It leaves verificationMode, actionTimeoutMs, and verificationTimeoutMs entirely to the schema's own descriptions, so it does not fully close the coverage gap.

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?

Opens with a specific verb+resource+platform: "Type text into the currently focused Android input field." That phrasing also implicitly distinguishes it from tap/tap_element/set_text-style siblings by naming the precondition (focus must already exist) rather than the target element.

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?

Gives an explicit ordered workflow (resolve/focus → type_text → wait_for_* → expect_*), states exclusions ("Do not use wait_for_* alone as final verification when an applicable expect_* tool exists"), and names the concrete alternative tools by name. It also specifies retry policy per failure code (TIMEOUT → retry once, UNKNOWN → re-focus or snapshot).

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