Skip to main content
Glama

wait_object

Wait until a specified object appears in the client UI tree, using timeout and properties, to confirm readiness before interacting with it.

Instructions

Wait until an object appears in the tested client UI tree.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNo
typeNo
titleNo
timeoutNo
session_idNodefault-18

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.5.3

TDQS

C2.7/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states that the tool waits for appearance but says nothing about timeout behavior, what happens on failure, whether it returns when the object is already present, or how it polls the UI tree.

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 a single, front-loaded sentence with no filler. It earns high marks for efficiency, though the brevity comes at the cost of necessary operational detail.

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

Completeness2/5

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

With no annotations, no output schema, and 5 undocumented parameters, the description is too thin for reliable invocation. An agent would not know what the tool returns, whether it throws on timeout, or how to construct the object selector correctly.

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

Parameters2/5

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

Schema description coverage is 0%, so the description should explain how name, type, title, timeout, and session_id are used. It only implies the tool targets an object, without defining object-matching semantics, how multiple selectors combine, or what the timeout unit/limit means.

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 and resource: 'Wait until an object appears in the tested client UI tree.' This makes the core action clear and distinguishes it from lookup-type siblings like find_object or get_object, though it does not explicitly contrast with wait_form/wait_window.

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

Usage Guidelines2/5

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

There is no guidance about when to use this tool versus alternatives such as find_object, search_objects, wait_client_idle, or wait_form. The description only expresses the wait action without providing call-site context or exclusions.

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