Skip to main content
Glama

Live: wait for change

live_wait_for_change
Read-only

Pause execution until the user edits the document, selection, or viewport, then return change flags. Prevents busy-waiting in live sessions.

Instructions

Block until the live state changes, or the bounded timeout elapses (read-only).

When to use: between live_session_step iterations so the loop reacts to the user's own GUI edits instead of busy-rendering. To then re-perceive use live_get_scene.

Key params: timeout_s is clamped to at most 60s and poll_interval_s is floored, so the wait never spins tightly nor blocks forever (it sleeps between cheap polls). Each poll pulls a CHEAP state token (small revision marker + selection ids + coarse viewport — never the full doc or a PNG; protocol v5), hashed + diffed against the last token. Requires a session; no code/raw-Action path (ADR-003). NOTE: the socket helper runs on a snapshot, so within one call it cannot observe later GUI edits; the token mechanism is transport-agnostic and detects user edits on any transport that recomputes per poll.

Return shape: LiveChangechanged, timed_out, and the delta flags selection_changed / document_changed / viewport_changed (more than one may fire).

Example: live_wait_for_change(timeout_s=10)

Risk class: low (read-only polling; no document mutation, no Operation Record).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
timeout_sNo
poll_interval_sNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
tokenNoThe newest observed state token.
changedNoWhether any tracked component changed.
timed_outNoTrue when a bounded wait elapsed with no change.
selection_idsNoCurrent selection object ids at observation time.
document_changedNoDocument revision marker changed.
viewport_changedNoViewport (zoom/center) changed.
selection_changedNoSelection ids changed.
Behavior5/5

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

Discloses internal polling mechanism, parameter bounds (timeout_s clamped, poll_interval_s floored), cheap token nature, transport-agnostic property, socket limitation, and return shape details. Goes far beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured: starts with purpose, then usage, then parameter behavior, then return shape, then example. Every sentence is informative and efficient; no redundancy.

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?

Covers all relevant aspects: purpose, when-to-use, parameter constraints, internal behavior, return shape, example, risk class, and session requirement. Complete for a moderate-complexity tool.

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?

Adds semantic meaning to both parameters: explains timeout_s is bounded to 60s, poll_interval_s is floored, and describes impact on polling behavior. With 0% schema coverage, this fully compensates.

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?

Clearly states the tool blocks until live state changes or timeout, read-only. Distinguishes itself by context between live_session_step and live_get_scene, and explicitly notes it is for reacting to user GUI edits.

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?

Explicitly states when to use (between live_session_step iterations) and what to use after (live_get_scene). Also notes session requirement and exclusion of code/raw-Action path.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/jjjsood/inkscape-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server