Skip to main content
Glama

list_realtime_events

Read-only

Pull live market events from the backend's Redis-backed cache (12h TTL).

===> Call `situate(...)` FIRST. With symbols, its web says which event types fired
for the company and when — a node older than the 12h cache returns [] here; its
payload lives in the card's `persisted_in` table instead. With no symbols, its
`order` says which types to read and its `cache.count` per type says which are
empty before you call (0 = cold cache, not "nothing happened").
`list_options("event_types")` enumerates the valid type strings. `event_type` is REQUIRED and
has no default on purpose: the type is the whole question, and a default
would answer a different one (eps_update is one slice of the earnings
family, not the family).

Then CONNECT THE DOTS: fetch the type asked about and follow the situation
across its related_events with follow-up calls narrowed by `tickers=[...]`
to the symbols just seen — e.g. eps_update -> check the intraday tape
(detect_intraday_outlier_jumps) -> 8k_release -> ir_publication. One hop
answers most questions; two covers a full earnings cycle. An unfiltered
follow-up call re-pulls the whole cache.

Returns `events`, a list of event objects (keys vary by type). An EMPTY list
means the cache is cold for that event type (12h TTL), not that nothing happened.

A material event here (eps_update, eps_release, 8k_release, financials_release,
ir_publication, transcript_update) means the symbol's report is being written from
it (within minutes; the `report_plan` topic announces each one):
`list_available_reports(event_types=[<this type>])` says which are already current,
and get_latest_report returns them in seconds.

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

Input Schema

NameRequiredDescriptionDefault
sectorNoSector values from list_options("sectors").
tickersNoNarrow to these tickers; always set on follow-up calls (an unfiltered call re-pulls the whole cache).
industryNoIndustry values from list_sub_industries([...]).
event_typeYesREQUIRED realtime event type from list_options("event_types"), e.g. "eps_update", "8k_release", "ir_publication".
market_capNoMarket-cap buckets, e.g. ["Large-cap", "Mega-cap"].

Output Schema

NameRequiredDescriptionDefault
eventsYesCached events of the requested type. Empty means the 12h cache is cold for that type, not that nothing happened.

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, so the description adds the substantive behavior: 12h TTL cache, empty list means cold cache rather than no event, cache.count semantics from situate, coalescing onto report writes, and OAuth bearer requirement. These are exactly the traits an agent would otherwise misread as data absence.

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?

Well front-loaded with the core action first, then the situate prerequisite, then the follow-up pattern. It is longer than needed for a list tool and the arrow-chain examples and repeated cache-TTL mentions add bulk, but almost every sentence carries actionable information.

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 5-parameter filtered read with an output schema and only a readOnlyHint annotation, the description covers prerequisites, valid type strings, follow-up narrowing, empty-result interpretation, and where stale data lives. Nothing material is missing before an agent fires the call.

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 already 100%, yet the description adds genuine meaning: why event_type has no default (a default would answer a different question) and the eps_update-is-one-slice-of-earnings nuance. It also restates the enumerating source (list_options("event_types")) and the tickers narrowing rule, though sector/industry/market_cap are left entirely to the schema.

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 ('Pull live market events from the backend's Redis-backed cache') plus the scoping constraint (12h TTL). An agent can tell it retrieves cached realtime event records by type, distinct from report or streaming siblings.

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 ordering rule ('Call situate(...) FIRST') with the reason for each branch (symbols vs no symbols), the alternative when data is older than the cache ('payload lives in the card's persisted_in table'), the required-first-hop pattern, and the downstream alternatives list_available_reports/get_latest_report. When-not guidance is also given ('an unfiltered follow-up call re-pulls the whole cache').

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