Skip to main content
Glama

Wait for the game

wait

Pause playtesting for milliseconds, until specified text appears, or for the page to settle, then return the updated observation. Use for timed passages and animations.

Instructions

Wait for time (ms), for a text to appear, and/or for the page to settle, then return the new observation. Useful for timed passages and animations. Returns text; pass format:"json" for a JSON string.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
msNoMilliseconds to wait.
formatNoOutput format: "text" (default, human-readable) or "json" (JSON string for programmatic use).
game_idYesSession id returned by open_game.
for_textNoWait until this text appears anywhere on the page (up to timeout_ms).
timeout_msNoTimeout for for_text (default 15000).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.3

TDQS

B3.4/5.0
Behavior3/5

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

No annotations provided, so description carries full burden. It discloses return format (text/json) and waiting conditions, but omits timeout behavior for ms wait, error handling if text never appears, and whether the observation is returned as a snapshot. Adequate but incomplete for a wait tool.

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?

Single sentence stating what it waits for and returns, followed by a brief note on use case and format parameter. Slightly dense but front-loaded and efficient.

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

Completeness3/5

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

For a tool with 5 parameters and no output schema, description covers the core waiting and return format but lacks details on timeout interaction, error cases, and how the observation is structured. Sufficient for basic invocation but missing edge-case guidance.

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

Parameters3/5

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

Schema coverage is 100% and parameters have descriptions, so baseline 3 is appropriate. Description mentions ms, for_text, and format, but adds no syntax or default details beyond schema; timeout_ms and game_id are not mentioned in description.

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

Purpose4/5

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

States a specific action (wait) with three conditions (time, text appearance, page settle) and the return (new observation). Distinguishes from siblings like observe (immediate) and screenshot, though doesn't explicitly name an alternative.

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

Usage Guidelines3/5

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

Mentions 'useful for timed passages and animations' which implies usage context, but doesn't specify when to choose wait vs observe or other tools, nor when to avoid waiting.

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