Skip to main content
Glama

stream_event_subscription

Read-only

Read the next events on a saved subscription — a bounded read of GET /event-subscription/{subscription_id} that resumes from the position saved when the previous read closed, so repeated calls see every matching event exactly once with no gap and no replay.

For a live-streaming ask, the default is a dashboard (in Claude, an Artifact) that
loops stream_events with its cursor — see stream_events; a page should prefer that
ad-hoc stream, since a subscription read can stall.

Returns {"events": [...], "cursor": "<last id seen>", "closed": null | reason,
"elapsed_seconds": n} — same shape and event objects as stream_events. A call returns after `max_events`
matched events or `max_wait_seconds` (cap 55 s); call again to keep listening. The
API saves the cursor when this read closes the connection, so the next call resumes
correctly WITHOUT passing `cursor`. Pass `cursor` only to override the saved
position for one connection (e.g. re-read from an earlier frame id); it is not
persisted.

An empty `events` list means nothing matched in the window, not that the
subscription is broken. `closed` = "subscription deleted" means it was removed
mid-stream — do not reconnect. 404 `unknown subscription_id` covers both a missing
id and another user's id (indistinguishable by design).

Acting on what arrives: an `event` item is the full realtime event (use it
directly); to hand over research, get_latest_report([symbol]) first (a fresh plan
renders in ~10-20 s; batch up to 50 symbols per call), and only if it comes back
stale/missing a generate_report_for_stock(ticker) rebuild. A `report_plan` item
means a plan was just saved: get_latest_report([symbol]) renders it fresh.

Requires auth (your MCP client attaches the OAuth bearer automatically).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cursorNoOverride the saved position for this one connection (not persisted). Omit to resume where the last read stopped.
max_eventsNoReturn after this many matched events (clamped to 1-200).
subscription_idYesThe `subscription_id` returned by register_event_subscription.
max_wait_secondsNoReturn after this many seconds even if fewer events arrived (clamped to 1-55).

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
closedNoSet when the server ended the stream (e.g. "subscription deleted"); do not reconnect.
cursorNoLast stream id seen (advances on heartbeats too). Pass it back on the next call; null only when no frame carried an id and none was passed in.
eventsYesMatched events in publish order; empty on a quiet tape. A frame whose data was not JSON comes through as {"raw": <text>}.
elapsed_secondsYesWall time this read held the stream open.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only declare readOnlyHint=true; the description carries the real behavioral load — server-side cursor persistence across connections, the 55 s wait cap, exactly-once/no-replay semantics, closed reasons, and the deliberately ambiguous 404. It also states the auth requirement.

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 core contract and organized into scannable paragraphs, but it runs long and the 'Acting on what arrives' section drifts into downstream-tool guidance (get_latest_report timing, generate_report_for_stock fallback) that belongs closer to those tools.

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?

For a resumable streaming read with a 4-param schema, the description covers return shape, timeout behavior, cursor persistence, terminal closed states, error semantics, and auth. Even though an output schema exists, nothing an agent needs to call or loop this correctly is missing.

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 100%, so the baseline is 3, but the description adds meaning beyond the schema: cursor is an ephemeral per-connection override that is NOT persisted, while the saved position resumes automatically without passing it. That interplay is the key semantic and it is spelled out.

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 ('Read the next events on a saved subscription') and pins the underlying endpoint GET /event-subscription/{subscription_id}. It explicitly distinguishes itself from the sibling stream_events, so an agent can route without opening either 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?

Explicitly says when to prefer the alternative ('a page should prefer that ad-hoc stream, since a subscription read can stall') and when to pass cursor vs omit it. It also covers the edge case of not reconnecting after 'subscription deleted' and how to interpret an empty events list.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources