Skip to main content
Glama

stream_events

Read-only

Listen for realtime events as they publish — a bounded read of the backend's ad-hoc SSE stream (GET /events), filter passed inline, nothing saved server-side.

DEFAULT DELIVERY — BUILD A DASHBOARD: when the user asks to stream / watch / keep
listening for live events, build a live dashboard (in Claude, an Artifact) whose
page calls this tool in its own loop, carrying `cursor` from read to read, and
renders each event as it lands. One prompt then keeps the stream open with no agent
turn per read. If the page cannot reach this server, run the loop yourself and write
each event into the dashboard's shared store. Stream into chat only when the user
asks for that, or the client cannot render a dashboard.

Returns {"events": [...], "cursor": "<last id seen>", "closed": null | reason,
"elapsed_seconds": n}. Each item in `events` is the same object `list_realtime_events` returns for that
type ({event_type, symbol, payload, published_at, id}) — summary, thesis impact,
significant changes, citations — the moment it publishes, no polling of the 12h
cache. There is NO PDF link on an event: for the research, POST the symbol to
get_latest_report (a fresh plan renders in ~10-20 s; stale/missing -> a
generate_report_for_stock rebuild, ticker only).

THE LOOP: a call returns after `max_events` matched events or `max_wait_seconds`
(cap 55 s), whichever comes first — call it again to keep listening, and ALWAYS
pass the returned `cursor` back in: this stream keeps no state, so without it
the next call starts at "now" and drops whatever published in between. The
cursor advances on heartbeats too (events the filter dropped), so an empty
`events` list with a moved cursor is normal on a quiet tape. Omit `cursor` on
the first call to start at now. For a subscription that resumes by itself, use
register_event_subscription + stream_event_subscription instead.

`topics` (optional, any mix; case-insensitive):
  - an event type from list_options("event_types") — eps_update, 8k_release,
    transcript_update, ir_publication, biggest_mover, 13f_new, strategy_update, ...
  - a family from the same listing — earnings, news, market_movement,
    institutional_ownership, analyst_activity, strategy, prediction — which
    matches every type in it, including types added later;
  - `report_plan` (stream-only): a frame each time a report plan is SAVED
    ({symbol, event_type, planned_at, queued_at, plan_key}); the next step is
    get_latest_report([symbol]), which finds the plan fresh and renders it.
`symbols` (optional): tickers; 13f_* filer events carry the filer's CIK in the
symbol slot. No topics and no symbols = everything. Unknown topic -> 422 with the
allowed lists in `detail`.

`closed` set means the server ended the stream — do not reconnect with that id.
Requires auth (your MCP client attaches the OAuth bearer automatically).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cursorNoThe `cursor` returned by the previous read; resume after it. Omit to start at now.
topicsNoEvent types or families from list_options("event_types") (e.g. "eps_update", "earnings"), plus the stream-only "report_plan"; case-insensitive. Omit for every topic.
symbolsNoTickers to listen for (13f_* filer events carry the filer's CIK in the symbol slot). Omit for every symbol.
max_eventsNoReturn after this many matched events (clamped to 1-200).
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.5/5.0
Behavior4/5

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

Annotations only declare readOnlyHint; the description goes much further: bounded read semantics, no server-side state, cursor advances on heartbeats so empty events + moved cursor is normal, closed means server ended the stream and do-not-reconnect, auth required. Does not contradict annotations. Slightly less than 5 because some operational detail (rate limits, exact 422 shape) is only partially covered.

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?

Much of the content is valuable, but structure is dense: multiple distinct topics (delivery pattern, cursor loop, topics, symbols, closed) are packed with bold headers, inner bullet lists, and parentheticals. It works but is not front-loaded in the sense of a single tight opening; the caller must read the full document to extract the loop protocol.

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 complexity (bounded SSE read with cursor, 5 optional params, output schema present) the description covers consumption guidance, loop semantics, alternatives, and error behavior. Since an output schema exists, it does not over-explain return shapes while still calling out key fields (events, cursor, closed, elapsed_seconds).

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 baseline is 3. Description adds meaningful semantics beyond schema descriptions: topics can be an event type, a family, or stream-only 'report_plan'; symbols note that 13f_* filer events carry CIK; cursor advances on heartbeats; unknown topic -> 422 with allowed lists. That is real added meaning over schema text.

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+resource: 'Listen for realtime events as they publish — a bounded read of the backend's ad-hoc SSE stream (GET /events)'. Names the sibling alternatives and differentiates: 'For a subscription that resumes by itself, use register_event_subscription + stream_event_subscription instead', and references list_realtime_events as the polling counterpart.

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?

Explicit 'DEFAULT DELIVERY' section tells the agent what to do (build a live dashboard, run the loop) vs when to stream into chat only. Names explicit alternatives ('use register_event_subscription + stream_event_subscription instead'), and specifies cursor handling per call. This is a rare example of explicitly covering when/why.

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