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 (symbols=[...] for named companies, none for the
market): its `cache.present` / `cache.expired` say which types this tool can
still return, its `plan` carries the exact calls to make, and its `skip` list
names the ones that would return [] — an event older than the 12h cache lives
in the ontology card's `persisted_in` relation, not here. Never call this for a
type situate marked expired. `list_options("event_types")` remains the
enumeration of valid type strings and descriptions. `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 a report plan was saved for the symbol:
`list_available_reports(event_types=[<this type>])` says which of them
get_latest_report renders fresh in seconds.

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

Input Schema

TableJSON 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

TableJSON 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 supply readOnlyHint=true, so the description carries the behavioral load and does so richly: 12h cache TTL, that an EMPTY list means a cold cache rather than no event, that older events live in the ontology card's persisted_in relation, auth requirements, and material-event side effects on report plans.

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 purpose and the critical situate-first constraint, and the workflow, return semantics, and auth note follow in a logical order. It is dense and longer than typical, but nearly every sentence carries operational weight for a multi-step tool, with only mild 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?

Although an output schema exists, the description still clarifies the empty-list meaning, which is essential context. Combined with auth, cache lifetime, and the chained-call workflow, an agent has everything needed to invoke this 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 coverage is 100%, so the schema documents all five params and a baseline 3 applies. The description nonetheless adds real meaning beyond the schema: why event_type is REQUIRED with no default (a default would answer a different question), and that tickers should always be set on follow-up calls to avoid re-pulling the whole cache.

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 distinguishing constraint (12h TTL). It clearly separates this tool from siblings like situate, get_event_ontology, and list_available_reports, which are named and given explicit roles.

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 routing: call situate FIRST, never call for a type situate marked expired, use list_options('event_types') for the enumeration, and follow up on related_events narrowed by tickers. It even states when an empty result is expected versus meaningful, leaving nothing to inference.

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