Wait For

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

Annotations only declare readOnly=false, openWorld=true, destructive=true; the description adds genuinely non-obvious traits beyond that: check-current-state-first semantics that prevent spurious timeouts, glob vs substring matching on URLs, enforcement of real (not clamped) timeouts, and failure output that names what was awaited versus observed. It does not reconcile the 'destructive' annotation, which is unexpected for a wait, but it does not contradict it either.

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 purpose is front-loaded in sentence one, and the remaining sentences carry distinct facts (check-first behavior, glob rule, failure reporting). It is somewhat dense, and the parenthetical about a URL wait expiring on a finished navigation could be trimmed without loss.

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 no output schema and annotations that say little about runtime behavior, the description does cover return/failure behavior and timing semantics well. However, for a five-parameter tool at 0% schema coverage, leaving 'value', 'location', and 'timeout_ms' unexplained leaves the agent to guess how each maps to a condition type.

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 bears the full param burden for five parameters. It clarifies condition semantics and the wildcard/substring rule for URL values, but 'value' and 'location' are never tied to their roles and timeout_ms is only alluded to via 'real timeouts', so compensation is partial.

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 opening sentence gives a precise verb and enumerates the four condition kinds the tool handles (text appear/disappear, element state, URL match, JS predicate), so the agent knows exactly what this is for. It never names or contrasts with siblings like find_elements or get_text, so it stops just short of full sibling differentiation.

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 real usage context: every condition is check-first and returns immediately when already satisfied, so a wait after the fact is free rather than a timeout. That's actionable guidance on when this is safe to use, but there is no explicit statement of when NOT to use it or which sibling to prefer for a plain immediate check.

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