aua_screen_action

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

Beyond the annotations (readOnlyHint=false, openWorldHint=true, idempotentHint=false), the description discloses real behavioral traits: phone actions are suppressed during auth takeover, settings responses never expose credentials, and save runs a fixed synthetic Choice test before enabling. That is meaningful side-effect and safety context an agent could not infer from structured fields, though it stops short of saying what each action returns or which actions mutate local state.

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 short telegraphic sentences with no filler, but the phrasing is jargon-heavy ('fixed synthetic Choice', 'local Jev settings') and the most decision-relevant information, the action list and parameter mapping, is absent. Compact, yet under-specified rather than tight.

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?

This is a 13-action multi-purpose tool with 5 parameters, 20% schema coverage, and no output schema, so the description carries a heavy burden it does not meet. It omits action-by-action behavior and the x/y/direction/api_key applicability, leaving an agent unable to invoke most actions correctly without guessing.

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 only 20% – just api_key has a note – and the description adds only that users supply their own key in the screen UI. It never maps x/y to tap/swipe, direction to swipe, or api_key to jev_save/jev_test, leaving 13 actions' parameter requirements undocumented. With this low coverage the description should compensate and does not.

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?

The description only characterizes the tool as 'App-only preview controls and local Jev settings' without a specific verb or enumeration of what the 13 actions do. It never distinguishes itself from siblings such as aua_tap, aua_swipe, or aua_screen, even though its action enum overlaps with those tools' purposes. An agent cannot predict what calling it will accomplish.

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?

The only guidance is a constraint ('Phone actions are blocked during authentication takeover'), which implies a when-not condition but no when-to-use rule. Nothing tells the agent which of the 13 actions to pick, or when to prefer this tool over aua_tap/aua_swipe for the same tap/swipe operations.

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