web-speed-agent

Overview Schema Source Related Servers Discussions Admin

wait_for_predicate

Wait until a JavaScript expression returns truthy in the browser, so automation proceeds only when a condition is met. Use it for app readiness, spinner removal, or list lengths instead of fixed sleeps.

Instructions

Wait until a JavaScript expression returns a truthy value.

The general-purpose wait, for when readiness is not "an element appeared": a list reached a length, a spinner class was removed, a global got populated, an animation finished.

wait_for_predicate("document.querySelectorAll('.row').length > 10")
wait_for_predicate("!document.querySelector('.spinner')")
wait_for_predicate("window.__APP_READY === true")

Always prefer this to a fixed sleep — it returns the moment the condition holds, instead of costing the full delay every time. If you only need to wait after a click or a keypress, pass wait_for_predicate to that tool instead and save the extra round-trip.

Args: js: JavaScript expression (or zero-argument function) re-evaluated in page context until it returns truthy. timeout_ms: Maximum time to wait (default 10 000). poll_ms: How often to re-evaluate, in milliseconds (default 100).

Input Schema

TableJSON Schema

Name	Required	Description	Default
`js`	Yes
`poll_ms`	No
`timeout_ms`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.5.0Sep 16, 2026

TDQS

A4.7/5.0

Behavior4/5

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

With no annotations, the description carries the full burden. It discloses the core mechanics: re-evaluated in page context, returns the moment the condition holds, with configurable timeout and poll intervals. However, it does not state what happens on timeout (e.g., throws an error) nor the risk of executing arbitrary JavaScript with possible side effects. These are minor gaps given the operation's nature.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is tightly structured: a one-sentence purpose, three illustrative examples, a usage preference note, and clear parameter definitions. No wasted words; every sentence earns its place, and the key information is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

It covers the essential context: purpose, examples, usage guidance, and all parameters. It omits the timeout failure behavior and any return value specification, though an output schema exists to potentially cover return. For a wait tool, these are acceptable gaps, making it highly usable for an agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must compensate. It does so fully: it explains 'js' as the expression to evaluate, 'timeout_ms' as the maximum wait, and 'poll_ms' as the re-evaluation interval, reinforced with three concrete usage examples. This adds significant meaning beyond the bare schema types and defaults.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a precise verb+resource: 'Wait until a JavaScript expression returns a truthy value.' It explicitly contrasts with the sibling 'wait_for_element' by framing itself as the general-purpose wait for conditions other than element appearance, giving clear differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives explicit when-to-use guidance: 'Always prefer this to a fixed sleep,' and provides a conditional exclusion: 'If you only need to wait after a click or a keypress, pass wait_for_predicate to that tool instead.' This tells the agent exactly when to call it directly versus delegate, leaving no ambiguity.

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