Skip to main content
Glama

stream_poll

Read-only

Fetch new frames incrementally from an open session with a private, per-consumer cursor. Acknowledge delivery via since_seq to release frames, and optionally parse each frame server-side.

Instructions

Per-consumer incremental frame poll on an open session — a private cursor with its own deframer, fully independent of read (the two never steal frames from each other). Call with session_id to create a subscription: the result carries its subscription_id plus any frames already buffered. Call with that subscription_id to fetch what arrived since; frames carry a monotonic per-subscription seq, and next_seq is the seq the next frame will get. since_seq acknowledges delivery: frames with seq < since_seq are released — ack with the last delivered frame's seq + 1, not next_seq (next_seq can run ahead of a max_frames-capped page, and acknowledging frames never delivered is a loud error). Each page also stops at max_inline_bytes of rendered payload (default 4096, metered as each frame's hex length + text length; page_bytes reports the page's actual total) — whole frames only, in seq order; a first frame alone beyond the budget is still delivered, alone, with oversized_frame: true, so delivery always makes progress. Omit since_seq and the unacknowledged frames are redelivered unchanged (idempotent re-read, so a lost response costs nothing). A consumer that lags loses the oldest retained frames beyond 1024, counted cumulatively in dropped_frames; a subscription the session's byte buffer overflowed past counts the gaps in dropped_chunks — never silently. close: true releases the subscription (result carries closed: true). At most 8 subscriptions per session; ones idle beyond 120 s are swept by later stream_poll calls, and closing the session releases them all. Every result folds in the session's live counters as stats. Returns immediately with whatever is available — never waits; a poll with nothing left to deliver on a dead port errors loudly instead of looking healthy. Optionally pass parse: {device, command} when CREATING a subscription (never on a follow-up poll — that is a loud error) to parse every frame server-side with that workspace command's response.parse: each frame then carries parsed (the field values) or parse_error (the per-frame reason; one bad frame never stops the stream), parsed once at arrival so redelivery repeats the identical outcome, and every result echoes parse: {device, command} plus the command's units (same semantics as run_command). A device or command that does not exist, or a command without a response.parse block, fails subscription creation loudly.

Input Schema

NameRequiredDescriptionDefault
closeNoRelease the subscription instead of polling it
parseNoOnly when creating a subscription (with session_id): parse every frame server-side with this workspace command's response.parse — frames carry parsed or parse_error; a follow-up poll passing parse is a loud error
since_seqNoAcknowledge delivery: release frames with seq < since_seq — pass the last delivered frame's seq + 1; omit to redeliver the unacknowledged frames
max_framesNo
session_idNoOpen session to subscribe to; required when no subscription_id is given
subscription_idNoSubscription from an earlier stream_poll; required for follow-up polls and for close
max_inline_bytesNoByte budget for one page's inlined frames, metered as each frame's rendered hex length + text length; whole frames only, except a single first frame beyond the budget (delivered with oversized_frame: true)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.0

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already declare readOnlyHint/destructiveHint/openWorld, but the description adds substantial behavior beyond them: at-least-once gap accounting (dropped_frames, dropped_chunks 'never silently'), idempotent redelivery via omitted since_seq, loud failure on a dead port, retention limit of 1024 frames, 8-subscription cap, 120 s idle sweep, and parse-error isolation per frame. This is unusually rich disclosure.

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

Conciseness3/5

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

Front-loaded correctly with purpose before mechanism, and most sentences carry unique operational information. However, it is one ~450-word run-on paragraph with deeply nested parentheticals and some restatement of schema-level details (parse, max_inline_bytes), making it dense to parse where sub-structuring would help.

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?

With no output schema, the description carries the full burden of explaining return values and does so thoroughly: subscription_id, frames with monotonic seq, next_seq, page_bytes, oversized_frame, dropped_frames/dropped_chunks, stats counters, and parsed/parse_error. For a 7-parameter nested-schema tool this leaves nothing an agent needs to call it correctly.

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 description coverage is 86%, so the baseline is 3, but the description genuinely adds meaning: why to ack with 'last delivered frame's seq + 1, not next_seq' (next_seq can run ahead of a max_frames-capped page) and how max_inline_bytes is metered. The only real gap is max_frames, which is never explained in prose and has no schema description.

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?

States a specific verb and resource ('per-consumer incremental frame poll on an open session') and immediately distinguishes itself from the sibling read tool ('fully independent of `read` (the two never steal frames from each other)'). An agent can select this over read/capture_frames without opening any schema.

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?

Spells out the two call modes ('Call with session_id to create a subscription' vs 'Call with that subscription_id to fetch what arrived since'), when close:true applies, and exactly when parse is legal ('when CREATING a subscription ... never on a follow-up poll — that is a loud error'). Alternatives and exclusions are explicit rather than implied.

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