Skip to main content
Glama

wait_for_text

Polls a desktop UI element until its text or name matches an exact value, substring, or regex, re-finding replaced nodes on each poll. Use it to confirm in-place text changes or status labels.

Instructions

Wait until an element reads text, contains it (contains=true), or matches the regex pattern ("^Opened": starts with Opened, when the rest is unknown). Compares whitespace-trimmed, NFC-normalised text.

Pass handle_id for a field whose value changes in place (a search box after type_text; get_value straight away still shows a prefix on a busy app). Pass window_id plus role and/or name for a label or status bar: toolkits like egui replace such a node when its text changes, so the old handle keeps the old text, and the element is re-found on every poll. An element without a value is read by its name.

Returns {ok, value}; on timeout {ok: false, error} with what was read.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "wait_for_text"
  }
}

Input Schema

NameRequiredDescriptionDefault
nameNo
roleNo
textNo
patternNo
timeoutNo
containsNo
handle_idNo
window_idNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv2.1.0

TDQS

A4/5.0
Behavior4/5

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

With no annotations at all, the description carries the full burden and does well: it discloses the comparison semantics (whitespace-trimmed, NFC-normalised), the re-find-on-every-poll behaviour, the return shape `{ok, value}`, and the timeout failure shape `{ok: false, error}` with what was read. It stops short of stating poll frequency, blocking behaviour, or what happens on an ambiguous multi-match.

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 matching modes an agent needs first, then addressing strategy, then return values — a sensible order. It is information-dense with no filler, though the parenthetical asides ('a search box after type_text', 'toolkits like egui replace such a node') make sentences long and slightly tangled.

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 an eight-parameter, annotation-free, no-output-schema tool, the description covers matching, addressing, stale-handle pitfalls, and both success and timeout return shapes — the agent can call it correctly. Remaining holes are the `timeout` semantics (unit/default) and the precedence between `handle_id` and `window_id`.

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 0%, so the description must compensate across eight parameters, and it does for seven: `text`, `pattern` (with a concrete example regex), `contains`, `handle_id`, `window_id`, `role`, and `name` ('An element without a value is read by its name'). `timeout` is never explained — no unit, no mention that it defaults to 5 — which is the one real gap. Also unstated whether `handle_id` and `window_id` are mutually exclusive.

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?

The description states a specific verb ('wait until') and resource ('an element reads `text`… or matches the regex `pattern`'), and the parenthetical on `contains=true` sharpens the matching mode. It implicitly contrasts with `get_value` (which 'straight away still shows a prefix on a busy app'), but never explicitly distinguishes itself from `wait_for_element` or `wait_for_window`, the closest siblings.

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

Usage Guidelines4/5

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

Strong conditional guidance: use `handle_id` for a field that changes in place, use `window_id` plus role/name for labels or status bars that get replaced wholesale, and the reason is given for each. What's missing is an explicit statement of when not to call this tool or when to prefer `wait_for_element`/`get_value` outright.

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