Skip to main content
Glama

Wait until the game reaches a state

wait_until
Read-only

Poll tModLoader diagnostics until a condition is met, with typed comparisons and immediate error on impossible waits, returning unmatched as a valid result.

Instructions

Poll diag until one of its fields satisfies a comparison.

Args: field: A TOP-LEVEL diag field, exactly as diag reports it - vats, items, world-ready. Not a path into one: diag splits key: value and stops, so npcs is the whole string active=4 mutated=0 and there is no npcs.active. op: One of ==, !=, <, <=, >, >=, contains, changed. value: What to compare against, as text - it is converted to whatever type the field actually reads as. Omitted for changed, which baselines on its first reading. server: Watch the dedicated server's view instead of the client's. target: Watch a specific client by name. timeout: Seconds for the WHOLE call, spent across every poll rather than granted to each. poll: Seconds between polls.

Use this instead of sleeping and taking a diag. A guessed sleep is wrong in both directions, and the short one is dangerous: the check reads the state BEFORE the thing happened, which looks exactly like the feature being broken.

THE COMPARISON IS TYPED. diag returns counters as ints and the heartbeat's flags as bools; world-ready == true compares as a boolean and items >= 10 as a number, so neither "10" < "9" nor the truthiness of "False" can come back here.

IT REFUSES WHAT CAN NEVER COME TRUE rather than waiting it out. An unknown field names the fields that do exist; ordering a composite string says what the value actually is. Both used to be spellable and would have reported a timeout - blaming a game that was answering perfectly.

Not matching is an ANSWER, not an error: it returns matched: false with the last reading it took, so a wait that expected nothing to happen is as expressible as one that expected something to.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
opYes
pollNo
fieldYes
valueNo
serverNo
targetNo
timeoutNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
lastYes
noteYes
pollsYes
elapsedYes
matchedYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.6.3

TDQS

A4.9/5.0
Behavior5/5

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

Beyond the annotations (readOnlyHint=true, destructiveHint=false), the description discloses critical behavioral details: the typed comparison semantics (ints vs bools), the refusal of conditions that can never be true, the return of `matched: false` with the last reading, and the timeout/poll mechanics. This is substantial added value over the structured metadata and gives the agent a complete mental model of the tool's behavior.

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 description is long but well-organized into clear sections: a terse opening, a detailed Args block, and three focused notes on typing, impossible conditions, and non-match returns. Every sentence adds information, but some parts (e.g., the typed comparison examples) could be trimmed without loss. Still, the structure front-loads the core purpose and keeps related details together, so it remains effective.

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?

Given the tool's complexity (7 params, 0% schema coverage, and a rich behavioral profile), the description covers everything an agent needs to call it correctly: parameter semantics, type handling, error behavior, and timeout/poll semantics. The presence of an output schema (not shown) means return format is already structured, but the description still explains the `matched: false` case, which is essential context. No significant gaps remain.

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

Parameters5/5

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

With schema description coverage at 0%, the description carries the full burden of parameter documentation. It explains every one of the 7 parameters in the Args section: `field` (top-level only, not paths), `op` (enum-like list), `value` (text converted to field type), `server`/`target` (view selection), `timeout` (whole-call budget), and `poll` (interval). This fully compensates for the absent schema descriptions.

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 opens with a precise verb and resource: 'Poll `diag` until one of its fields satisfies a comparison.' This clearly identifies the tool's action and distinguishes it from sibling tools like `diag` (direct read) and `log_watch` (log watching). It also explicitly states when to prefer it over sleeping and taking a `diag`, reinforcing its unique role.

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?

The description gives explicit guidance: 'Use this instead of sleeping and taking a diag' and explains why a guessed sleep is wrong in both directions. It also clarifies behavior for impossible conditions and non-matching outcomes, which helps the agent decide when the tool is appropriate. The parameter docs for `server` and `target` further specify use cases for client vs. server views.

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