Skip to main content
Glama
IGELHARINE

CDPM

by IGELHARINE
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Wait

browser_wait

Waits until page text, URL, element state, network response, or network idle condition is met, then returns; use it to detect logins, search results, or loaded data without touching the page.

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

TableJSON 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-68d9".
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. First observedv0.1.0

TDQS

A4.5/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 and does well: it discloses read-only behavior ('Only reads, never touches the page, so the user's input is not lost'), that it returns as soon as the condition is met or a message arrives, and that response mode returns the body. It doesn't detail failure/timeout behavior beyond the schema, keeping it short of a 5.

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-loads the mode enumeration, then usage guidance, then constraints; every clause adds value. However the sentences are long and dense, cramming several ideas (SPA advice, login detection, message interruption) into run-ons, slightly reducing 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 complex 12-param tool with no output schema, the description covers behavior, mode semantics, and safety adequately. Return-value detail is partial (fully described only for response mode), but the guidance an agent needs to call it correctly is largely present.

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 schema already documents all 12 params and baseline is 3. The description adds interpretation beyond the schema: the response-mode timing nuance ('searches from this agent's last action on that tab, so responses that arrived during the click are caught') and concrete login-detection examples, which raise it above baseline.

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?

States a specific verb (waits) and enumerates every condition mode (text/gone/url/enabled/response/network_idle/seconds) that the tool handles. It explicitly routes to a sibling ('to wait for other agents use slot_inbox wait'), so an agent can distinguish it from other browser tools without opening a schema.

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?

Gives concrete when-to-use per mode plus the SPA recommendation to use response="/api/search" after a click instead of reading the page, and the login-detection pattern (url, gone="Password"). It also states when NOT to use plain seconds and points to the alternative. Exclusions and alternatives are explicit.

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