stay_awake

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

With no annotations provided, the description fully carries the behavioral transparency burden. It discloses that enabled=true holds screen on while charging (emulators always are), enabled=false restores normal timeout, and that describe_ui works regardless but screenshot/coordinate flows need screen on. No behavioral surprises.

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?

Three dense sentences with zero waste. First sentence states purpose and motivation in a memorable 'fix when' pattern, second explains the two states, third clarifies edge case (describe_ui unaffected). Perfectly front-loaded.

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?

Given two simple parameters (one boolean, one optional string), no output schema, and no annotations, the description is completely sufficient. It explains why you need it, what it does in each state, and which sibling tools are unaffected. No gaps remain.

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 coverage is 100%, so baseline is 3. The description adds context around the enabled parameter (explaining what true/false does in terms of svc power stayon and timeout restoration) and the serial parameter is self-explanatory from schema. No additional nuance beyond schema, so score remains at baseline.

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?

Description clearly states the tool keeps the display awake during a driving session, links to black screenshots and device sleep, and distinguishes between enabled=true and enabled=false behaviors. The phrase 'the fix when screenshots keep coming back black' provides concrete motivation, and 'describe_ui works regardless' clarifies scope.

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?

Explicitly states when to use this tool (when screenshots return black with screen_off:true, device sleeps between steps, common on emulators with short timeout). No explicit alternatives or when-not-to-use are mentioned, but the description implies it's needed for any screenshot/coordinate flow that requires screen on.

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