Wait for page condition

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does not state what happens on timeout, whether the tool throws or returns a value, whether it blocks or polls, or any side effects. The phrase 'bounded content stability' is opaque without further explanation. This is a significant gap for a waiting tool where agents need to know failure behavior.

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 a single sentence that front-loads the full list of wait conditions. It is efficient and information-dense, with no filler. Every word contributes to the core purpose.

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 has 13 parameters, many with complex interplay (e.g., scope, ignoreRoles, excludeSelectors), yet the description only summarizes the wait types. It does not explain return behavior, timeout semantics, or how parameters interact. Without an output schema, the agent lacks crucial information to call this correctly in diverse 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 69%, with several parameters lacking descriptions (text, selector, timeoutMs, urlIncludes, documentId). The description provides a high-level summary of the wait conditions, which partially aligns with parameters, but it does not elaborate on parameter meanings or combinations beyond the schema. It adds some value by grouping conditions but does not fully compensate for the uncovered 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 states a clear verb ('wait for') and enumerates the specific conditions it handles: text, selector, URL substring, selector absence, scoped text, and bounded content stability. It is specific and unambiguous, and since no sibling tool performs waiting, it distinguishes itself effectively.

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 implies usage for waiting on page conditions but does not explicitly state when to prefer this tool over alternatives or when not to use it. It also lacks guidance on which parameter combinations are valid (e.g., can text and selector be used together?). The context is clear but exclusions and selection criteria are absent.

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