Skip to main content
Glama

Wait

browser_wait

Wait for page text, URL changes, enabled elements, network responses, or network idle before continuing; it only reads, detecting login or SPA data without disturbing user input.

Instructions

Waits until text appears; gone: that text disappears; url: the URL changes; enabled: that button/input becomes enabled; response: a network response for that URL completes (returns its body); network_idle: the network goes quiet; otherwise for seconds. For SPAs (search results, lists, etc.), instead of reading the page, getting the data response (JSON) with response="/api/search" after a click is faster and more accurate (it searches from this agent's last action on that tab, so responses that arrived during the click are caught). Only reads, never touches the page, so the user's input is not lost (use it to detect login: url, gone="Password" or text="Inbox"). Returns as soon as the condition is met or another agent's message arrives. Keep waits minimal: long waits only for humans (login, etc.); to wait for other agents use slot_inbox wait.

Input Schema

NameRequiredDescriptionDefault
tabNoTarget tab: number (1, 2…) or ID ("t7"). Use the stable ID when agents share a slot. Required for action tools when there are multiple tabs.
urlNoUntil the URL contains this (e.g. "mail.google.com/mail"). "" = until it differs from the current URL
goneNoUntil this text disappears from the page (e.g. login form's "Password" gone = logged in)
slotYesBrowser slot 1-30. "3", "slot 3", "browser 3" → 3. If the user gives a port like 14052, subtract 14049.
textNoText to wait for
agentNoYour display name, shown to other agents. Subagents must always set it. Default "claude-1e1b".
enabledNoUntil this ref element (button/input) becomes enabled
secondsNoPlain wait in seconds. Avoid: wait on a condition (text/gone/url) or slot_inbox wait instead
timeoutNoMax wait in seconds for text/gone/url/enabled/response/network_idle. 300-600 when waiting for a human login, etc.
responseNoUntil a network response whose URL contains this completes (e.g. "/api/search"). * ? wildcards work (matched against the full URL, e.g. "*api.example.com/v1/items*"). Returns the response body
multiSlotNotrue only when one agent must handle several slots together (e.g. comparing). Normally omit (one agent = one slot; use subagents for the rest)
network_idleNoUntil no network requests for 0.5s (before capture/read)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.1.10
    • changedInput schema / properties / agent / description
      Previous value: -"Your display name, shown to other agents. Subagents must always set it. Default \"claude-68d9\"."New value: +"Your display name, shown to other agents. Subagents must always set it. Default \"claude-1e1b\"."
  2. First observedv0.1.0

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so: it declares the tool "Only reads, never touches the page, so the user's input is not lost," states it returns as soon as the condition is met or a message arrives, and explains the response mode returns the body and searches from the agent's last action. This is rich behavioral disclosure beyond what the schema states.

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?

The key information — the mode list — is front-loaded effectively, and each subsequent sentence (SPA shortcut, read-only safety, minimal waits) earns its place. However the first sentence is a dense semicolon run-on, which slightly hurts scannability.

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?

For a 12-parameter tool with no annotations and no output schema, the description is nearly complete: it covers modes, timing, safety, and return-body for response. It does not state what a text/gone/url wait returns or what happens on timeout expiry, leaving a couple of gaps.

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, but the description adds real value by explaining mode precedence ("otherwise for seconds") and the semantics of response wildcards and returned bodies that tie the parameters together. It stops short of fully documenting timeout-failure behavior, so it is above baseline but not exhaustive.

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 names a concrete verb ("Waits until") and exhaustively enumerates the condition modes — text, gone, url, enabled, response, network_idle, seconds — so an agent knows exactly what the tool does. It also names the sibling it is not ("to wait for other agents use slot_inbox wait"), distinguishing it from the other wait-style tools.

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 per mode and an alternative: for SPAs use response="/api/search" "instead of reading the page," and it routes agent-message waiting to slot_inbox wait. It also constrains duration ("Keep waits minimal: long waits only for humans"), leaving little to inference.

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