Skip to main content
Glama
Android Use
by JackCaow

aua_execute_goal

Run bounded Android UI actions to accomplish a supplied goal; returns decision options for host approval and stops on completion, handoff, or unresolved effects.

Instructions

Agent plans, a decision policy selects candidate IDs, Android Use executes. decider=auto uses Jev when enabled (TypeSafe key in screen settings, or ANDROID_USE_JEV_ENABLED=1 / TYPESAFE_API_KEY; sends visible app UI text to TypeSafe), otherwise host: no key, nothing sent externally. Host mode returns status=decision_required with compact state, option IDs and a one-time token; choose with aua_goal_decide. Caller supplies goal, foreground package, exact input texts and optional completion selector. Compact semantic state and parallel operation/target questions share one Jev request per step. Each Jev request also judges goal completion; without a completion selector a confident ACHIEVED stops before another action (stop_reason=model_goal_achieved, unverified: check it). input_macros=true can combine stable-field focus and exact input with native readback; max_steps counts candidate selections, with at most two native writes per input macro. Bounded candidate-only actions; no automatic replay. status=handoff is not success. effect_timeout_seconds bounds observation after acknowledged mutations; unresolved effects hand off without another mutation. Geometry-only changes do not prove an effect. Keep existing tools for planning, unsupported controls and recovery. Password screens hand off.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "goal": "<goal>",
      "package": "<package>"
    },
    "name": "aua_execute_goal"
  }
}

Input Schema

NameRequiredDescriptionDefault
goalYes
textsNo
actionsNo
deciderNoauto
observeNotree
packageYes
max_stepsNo
completionNo
min_marginNo
input_macrosNo
max_model_callsNo
min_probabilityNo
timeout_secondsNo
completion_stateNovisible
effect_timeout_secondsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.6.0
    • addedInput schema / properties / decider
      Added value: +{
      +  "default": "auto",
      +  "enum": [
      +    "auto",
      +    "jev",
      +    "host"
      +  ],
      +  "title": "Decider",
      +  "type": "string"
      +}
  2. Addedv0.5.2

TDQS

A3.5/5.0
Behavior5/5

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

The description discloses far more than the annotations, including external transmission of visible app UI text to TypeSafe, host-mode token flow, handoff semantics, no automatic replay, effect-timeout behavior, and that geometry-only changes do not prove an effect. These are exactly the operational, privacy, and failure-mode details an agent needs before invoking a non-idempotent open-world tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The text is dense and fact-packed with little wasted wording, but it is structured as a single wall of jargon-heavy sentences. The opening is not front-loaded around the core purpose, making the important usage details harder to scan for an agent selecting among many siblings.

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

Completeness3/5

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

Given the tool's complexity, the description covers core execution behavior, external-data implications, decision routing, handoff states and effect verification well. However, with no output schema and most of the 15 parameters undocumented, it remains incomplete for full invocation correctness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage across 15 parameters, the description must carry the full explanatory burden. It adds valuable meaning for decider, input_macros, max_steps, completion and effect_timeout_seconds, but leaves actions, observe, max_model_calls, min_margin, min_probability, timeout_seconds and completion_state unexplained.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description implies goal execution through phrases like 'Android Use executes' and 'Caller supplies goal', but it never states the core purpose plainly. The opening sentence focuses on internal architecture rather than a specific verb-and-resource definition, and most sibling tools are not differentiated.

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?

It gives meaningful routing guidance: use aua_goal_decide for host-mode decision_required results, keep existing tools for planning, unsupported controls and recovery, and hand off on password screens. It lacks clear guidance on when to choose this over lower-level siblings such as aua_batch or aua_screen_action, so it stops short of a full 5.

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