jevsim_run_steps

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

Annotations already indicate destructive and non-read-only behavior, and the description adds valuable behavioral details: returns partial progress, stops on ambiguity or failure, and never automatically replays uncertain actions. This goes beyond 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.

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

Four terse, front-loaded sentences with no filler. Every sentence contributes operational value, and the most important usage constraints appear early.

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

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

The description covers core execution behavior and safety constraints well, but with no output schema and no parameter-level descriptions, key details such as return format and the meaning of freshness or minProbability remain unclear. It is viable but not fully complete for such a complex nested schema.

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

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

Schema description coverage is 0%, yet the description only glosses over the steps array and the 60-second limit. It leaves deviceId, platform, freshness, minProbability, and the target/expect substructures largely unexplained, forcing the agent to infer meaning from names and enums alone.

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

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

States a clear, specific action: execute up to 10 caller-planned tap/type/scroll/wait/assert steps. This is easily distinguishable from the sibling status/inspect tools, though it does not explicitly name those alternatives.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides concrete operational guidance: every step needs a deterministic expected outcome, the simulator or Android device must be reserved for this call, and no other UI tool should be used concurrently. It does not, however, explicitly compare against jevsim_status or jevsim_inspect for tool selection.

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