Wait For

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

No annotations are provided, so the description must carry the full behavioral burden. It discloses the core waiting behavior and the gone flag, and mentions that gestures already settle, implying this tool is not for gesture settling. However, it fails to disclose polling mechanics, default timeout behavior, or any side effects. For a tool with no annotations, this is insufficient behavioral context.

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?

The description is two sentences with no fluff. The main purpose is front-loaded, and the usage note is concise. It earns points for brevity and clarity of structure, though it sacrifices detail for conciseness.

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?

With 7 parameters, no annotations, and no output schema details provided, the description is incomplete. It omits key parameter semantics (timeout, interval, device, package, activity) and does not mention polling behavior or return values. While an output schema exists, it does not cover parameter usage. The description is insufficient for an agent to call this tool correctly in varied scenarios.

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%, so the description must explain parameters. It only explains the gone parameter (waits for disappearance) and implicitly relates text and foreground, but it does not explain device, package, timeout, activity, or interval. The timeout and interval defaults are not mentioned, leaving agents to guess their meaning. This is a significant gap given the 7 parameters.

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 clearly states the tool waits until text appears on screen and/or an app/activity is in the foreground, with a note about gone=true for disappearance. It specifies the resource (text, app/activity) and the action (wait). It is distinct from browser_wait, which is contextually different, though it doesn't explicitly contrast with other wait-like tools.

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 description gives some usage context: 'For long waits (downloads, uploads); gestures already settle.' This implies it is appropriate for long-running operations and not needed for gestures, but it doesn't explicitly state when to use this tool over alternatives or list exclusions. It provides a hint but not a clear decision rule.

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