run_task
Execute a high-level goal on an Android phone by reading the screen, deciding actions, and iterating until done. Provide a plain-language goal; the tool handles the rest, reporting steps and outcome.
Instructions
Give the phone a goal and let it work the whole thing out itself.
Use this instead of driving the phone a step at a time. It reads the screen, decides what to do, does it, and reads again, until the goal is reported done or unreachable — so "open the email app" is one call here rather than ten round trips through you.
Every step reports the action, what came of it, and the two numbers Jev gave
for the choice: probability is how likely that option was the best one and
confidence is how sure it was of its own ranking. They are reported rather
than gated on, so a run that succeeded on a thin lead says so, and a run that
stopped for a reason other than reaching the goal says that instead.
achieved is what the run claimed. Read the steps for what actually
happened. If a run needs looking at afterwards, set PHONE_CONTROL_RUNS to a
directory and each run leaves a folder there with the full record of what it
asked Jev and what came back; the reply then names the folder.
Prefer the step-by-step tools when you already know exactly what to tap, when the screen is visual rather than textual, or when you need to inspect something part-way through.
Args: goal: What to achieve, in plain language. For example "open the email app" or "turn on airplane mode". max_steps: How many actions to allow before giving up. Reaching it ends the run honestly as unfinished rather than as a failure of the goal.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| goal | Yes | What you want done, in plain language. Phrase it as the outcome, not the steps. | |
| max_steps | No | How many actions to allow before giving up. |
Output Schema
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes |