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

mobile-debug-mcp

by clivejefferies
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

adjust_control

Set a slider or other numeric control to a target value with tolerance-based verification and bounded retries.

Instructions

Purpose: Adjust a numeric control value with verification.

This is the initial adjustable-control surface for slider-like controls and other controls that expose a numeric value or value_range.

Inputs:

  • exactly one of selector or element_id

  • property (defaults to "value")

  • targetValue

  • tolerance (optional; discrete default is 0, continuous default is max(step / 2, 1% of range) when omitted)

  • maxAttempts (optional; defaults to 5)

  • 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_state / actual_state / within_tolerance / converged / attempts / adjustment_mode

  • target.selector = original selector or element handle

  • success = true when the control converges within tolerance

Verification Guidance:

  • Prefer direct platform adjustment when the runtime exposes it; then verified increment/decrement actions; use coordinate fallback only as degraded mode

  • Use expect_state for the control value readback

  • Do not use derived semantic metadata as proof of success

Failure Handling:

  • ELEMENT_NOT_FOUND → re-resolve the control

  • ELEMENT_NOT_INTERACTABLE → the control cannot be adjusted through the current runtime

  • CONTROL_CONVERGENCE_FAILED → the control did not converge within bounded retries or the requested value is out of range

  • UNKNOWN → capture a snapshot and stop 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
deviceIdNoOptional device serial/udid
platformNoOptional platform override
propertyNoReadable numeric state property to adjust.value
selectorNo
toleranceNoAccepted numeric tolerance around the target value. Defaults are derived from the readable control domain.
element_idNoOptional previously resolved element identifier.
maxAttemptsNoMaximum adjustment attempts.
targetValueYesTarget numeric value.

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/5.0
Behavior4/5

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

With no annotations at all, the description carries the full behavioral burden and does so well: it defines bounded retries (maxAttempts=5), convergence semantics, the derived tolerance rule, and per-error-code recovery guidance (ELEMENT_NOT_FOUND, ELEMENT_NOT_INTERACTABLE, CONTROL_CONVERGENCE_FAILED, UNKNOWN). It also discloses that no automatic unlock or wake is performed and that device readiness signals may be unavailable on iOS.

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 (Purpose, Inputs, Output Structure, Verification Guidance, Failure Handling) with the core purpose front-loaded, so an agent can skim. The output-structure enumeration is long but justified given there is no output schema; the device-readiness paragraph is the least essential part.

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 an 8-parameter mutation tool with nested selector, no annotations, and no output schema, the description supplies output fields, convergence semantics, and failure taxonomy — enough to call it correctly. Minor gap: out-of-range targetValue behavior is only implied through CONTROL_CONVERGENCE_FAILED rather than stated directly.

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 already 88%, so the baseline is 3; the description adds real meaning on top by explaining the 'exactly one of selector or element_id' constraint, that property defaults to 'value', and the tolerance derivation formula (0 for discrete, max(step/2, 1% of range) for continuous) which the schema only gestures at. It does not explain selector sub-fields like contains, but those are documented in the schema.

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?

States a specific verb and resource: 'Adjust a numeric control value with verification,' and scopes it to 'slider-like controls and other controls that expose a numeric value or value_range.' That is precise enough to separate it from sibling interaction tools like tap, swipe, or type_text, though it never names an alternative explicitly.

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?

Gives a clear strategy hierarchy (direct platform adjustment preferred, then verified increment/decrement, coordinate fallback only as degraded mode) and points to expect_state for readback. It also warns against treating derived semantic metadata as proof of success. What's missing is an explicit statement of when NOT to use it (e.g., non-numeric controls, use tap instead).

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