browser_wait_for

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

Annotations already state readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the three operating modes, which is useful, but it does not disclose important behavior such as polling, timeout limits, or what happens if a condition is already satisfied when the call starts.

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?

One concise sentence with no filler, and the primary action ('wait for') is front-loaded. Every part of the sentence contributes to understanding the tool's function.

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 tool is relatively simple and the annotations cover safety, but the description leaves ambiguity about combinations of text, textGone, and time, and about what happens when none of the conditions are met. Since there are no required parameters, an agent needs more guidance on expected input combinations.

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 100%, so the schema already documents each parameter. The description paraphrases the same meanings rather than adding new semantics, and it does not clarify whether parameters can be combined or are mutually exclusive.

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 uses a specific verb ('wait') and names concrete resources: text appearing, text disappearing, and elapsed time. It clearly differentiates this tool from the other browser action siblings just by stating these three focus areas.

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 tells an agent when to use the tool: when you need to block until text appears, until text disappears, or until a duration has passed. It does not explicitly mention alternative tools, but no sibling tool fills the same waiting role, so the omission is minor.

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