wait

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, and it largely does not. It never says whether the call blocks, what happens when the timeout elapses (error vs. silent return), or whether a failed wait has side effects on the page — critical questions for a synchronization primitive.

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?

Two short sentences, with the capability statement front-loaded and the timing advice second. Nothing is redundant with the title or restates the schema.

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?

For a 5-parameter, annotation-free tool with no output schema, the description covers the what and the when but not the after. It omits return semantics and timeout failure behavior, so an agent cannot predict what a completed or timed-out wait yields.

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 80%, so the properties are mostly self-documenting and baseline 3 applies. The description does add useful semantics by pairing each wait mode with its meaning (selector vs. text vs. idle), but it says nothing about tabId or spaceId, the parameters most likely to be misused.

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 states a specific verb (wait) and enumerates the three conditions it can wait on — selector appears, text shows up, network idle — which map cleanly onto the 'for' enum. It does not, however, contrast itself with siblings like snapshot, read_text, or network, which an agent might consider instead for similar observation tasks.

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?

'Use after actions that load content' gives a clear, actionable timing cue that tells the agent when this tool belongs in a sequence. It stops short of stating exclusions or naming alternatives (e.g., when not to wait, or what to use instead when content is already present).

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