Skip to main content
Glama
Gwakko

agent-in-browser

by Gwakko
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Go
Local

wait_for

Read-only

Pause until text appears, a CSS selector becomes visible, or the URL contains a substring, then continue. Replaces guessed delays after clicks that load content asynchronously.

Instructions

Read-only: pause until a condition holds, polling every 200 ms: given text appears in the page, a CSS selector becomes visible, or the URL contains a substring; gone=true waits for the opposite. Returns how long it waited, or an error on timeout. Use it after clicks that load content asynchronously instead of guessing delays. With only ms it just sleeps (up to 60000). Give exactly one of text, selector or url.

Input Schema

NameRequiredDescriptionDefault
msNoPlain sleep in milliseconds (max 60000); only used when no text, selector or url is given.
tabNoTab id from tabs_list. Defaults to the current tab.
urlNoSubstring the tab URL should contain.
goneNoWait for the condition to become false instead, e.g. for a spinner to disappear.
textNoText that should appear somewhere in the page body.
selectorNoCSS selector of an element that should become visible.
timeout_msNoGive up and return an error after this many milliseconds (default 10000).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv0.1.2
    • changedInput schema / properties / gone / description
      Previous value: -"Wait for the condition to become false instead."New value: +"Wait for the condition to become false instead, e.g. for a spinner to disappear."
    • changedInput schema / properties / ms / description
      Previous value: -"Plain sleep in milliseconds (max 60000)."New value: +"Plain sleep in milliseconds (max 60000); only used when no text, selector or url is given."
    • changedInput schema / properties / selector / description
      Previous value: -"CSS selector that should be visible."New value: +"CSS selector of an element that should become visible."
    • changedInput schema / properties / text / description
      Previous value: -"Text that should appear in the page."New value: +"Text that should appear somewhere in the page body."
    • changedInput schema / properties / timeout_ms / description
      Previous value: -"Timeout (default 10000)."New value: +"Give up and return an error after this many milliseconds (default 10000)."
    • changedInput schema / properties / url / description
      Previous value: -"Substring the URL should contain."New value: +"Substring the tab URL should contain."
  2. First observedv0.1.1

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only declare readOnlyHint and openWorldHint; the description adds the facts an agent actually needs: 200 ms polling cadence, timeout returns an error, the call returns elapsed wait time, and the ms-sleep cap of 60000. It also states the gone=true inversion covers disappearance cases like spinners.

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

Conciseness4/5

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

Front-loaded with the read-only/safety tag and the core polling behavior; nearly every clause carries new information (poll interval, timeout error, return value, exclusive params). The opening sentence packs three semicolon-separated clauses, which costs a little readability against a tool this simple.

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

Completeness5/5

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

With no output schema, the description correctly covers the return value and the failure mode. Combined with 100% schema parameter coverage and the stated exclusivity rule, an agent can call this correctly without further guessing.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3; the description goes beyond it by stating the mutual-exclusivity constraint ('exactly one of text, selector or url') and the asymmetric behavior when only ms is supplied — neither of which the schema encodes. It does not, however, restate the default timeout of 10 s or the tab parameter, leaving those to the schema.

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?

Names a concrete action (pause/poll until a condition holds) and enumerates the three condition types plus the plain-sleep mode, which no sibling tool offers. The distinction from navigate/click/scroll is implicit but unmistakable given the polling semantics and the explicit 'instead of guessing delays' framing.

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?

Explicitly tells the agent when to reach for it ('after clicks that load content asynchronously instead of guessing delays'), and gives the selection rule among its own modes ('give exactly one of text, selector or url' vs. ms-only sleep). No competing sibling exists for this job, so no alternative tool needed to be named.

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

Deploy Server

Other Tools