Skip to main content
Glama
Sign In

Flexreport Finance

by com.flexreportfinapi.mcp
OverviewDiscussionsAdmin

get_event_ontology

Read-only

The platform's event ONTOLOGY — what an event TYPE means for everything else. Call it FIRST on any real-time, single-company, or event-driven request; it is the map the other calls are planned from.

===> For a named company, `situate(symbols=[...])` returns the cards of the event
types in its web and the table cards they entail — start there. Call this tool
directly for the FULL card of an event type, a relation card, a whole family, or
the unfiltered graph.

===> REQUISITE for: any real-time / live-events request, any "what
happened / why / catch me up" question, and BEFORE aiming explore_data_catalogue or
generate_report_for_stock at a company whose situation is event-driven. Cheap,
synchronous, public, symbol-INDEPENDENT and cacheable — fetch once per event type
(or once unfiltered, ~230 KB) and reuse for the whole conversation.

Pass exactly ONE filter for a small card (~5-10 KB):
  event_type="eps_update"        one event type and the relations it entails
  relation="eod_stock_prices"    one table/view and the event types that entail it
  family="earnings"              every event type and relation in a family
No filter -> the whole class graph (21 event types, ~300 relations, 20 tools).
Web nodes from get_company_event_web carry the join keys verbatim: pass a node's
`type` as event_type, its `relation` as relation, its `family` as family.

An event_type card carries:
  about                    what the event is ABOUT: symbol | filer | strategy. A 13F
                           event is a FILER's action across N names — the symbol
                           you asked about is one of them.
  persisted_in             the durable table to read once the event has aged out
                           of the realtime cache (realtime_cache_ttl_hours, 12h) —
                           list_realtime_events returns [] after that; the data is
                           still there, in this relation.
  entails.<layer>          the relations WRITTEN by the same chain run (mined, with
                           run counts) plus every view above them (pg_depend),
                           bucketed base / silver / gold / dimension / analysis.
                           These are the tables that are FRESH because this event
                           fired — name them explicitly in explore queries.
  entails.realtime_events  event types that usually FOLLOW, each with rate,
                           median_lag_hours, lift, mode (trigger = dispatched by the
                           same chain, near-certain; sequence = world-ordered,
                           independently detected, probabilistic), certainty /
                           expected_within_hours when declared, and persisted_in.
  preceded_by              the inverse — what should ALREADY exist earlier in the web.
  episodes                 named world-order sequences (earnings, realtime_mover,
                           thirteen_f_cycle, news) with this event's position — the
                           whole shape of the situation from any one member.
  produced_by[].schedule   the workflow that publishes it, its cron, and
                           next_run_at (America/New_York).
  deepened_by              the tools that deepen this event once you have its payload.
  informs                  DOMAIN causality (news -> prices, earnings -> estimates):
                           what an analyst checks next. Declared and the WEAKEST
                           edge — never present it as lineage.
  evidence                 how many of these events the platform has seen.

A relation card carries: layer, family, cadence (update_frequency + prose),
derives_from / feeds (pg_depend), computed_from / computes (LLM and model writers),
refreshed_by[].schedule with next_run_at, read_by (the MCP tools that read it),
entailed_by (event types), informs.

THE FRESHNESS CHECK — the reason this tool exists: compare a web node's `at` with a
downstream relation's refreshed_by[].schedule[].next_run_at. If next_run_at is AFTER
the event, that relation does NOT reflect the event yet. Do not query it for the
reaction — use the intraday tools (detect_intraday_outlier_jumps,
get_aftermarket_data) or say the daily table lags.

Every edge carries `provenance` (mined | declared | pg_depend | static:tasks.py |
beat | catalogue | data_model), the same honesty axis as the web's `cause`: mined
and pg_depend are facts, declared is the platform's own judgment, informs is domain
intuition. Quote the grade when you lean on an edge. format="triples" returns raw
subject-predicate-object rows instead of cards. degraded=true means the table has
not been built yet, not that the type is unknown.

Input Schema

NameRequiredDescriptionDefault
familyNoOne family, e.g. "earnings" (a web node's `family`).
formatNocards (grouped, default) or triples (raw subject-predicate-object rows).cards
relationNoOne table/view, e.g. "eod_stock_prices" (a web node's `relation`).
event_typeNoOne event type, e.g. "eps_update" (a web node's `type`). Pass exactly one filter.

Output Schema

NameRequiredDescriptionDefault
as_ofNo
edgesNoSubject-predicate-object rows (triples format).
degradedNoTrue when the ontology table is not built yet, not that the type is unknown.
episodesNo
relationsNoRelation cards, keyed by table/view (cards format).
event_typesNoEvent-type cards, keyed by type (cards format).
realtime_cache_ttl_hoursNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations only declare readOnlyHint=true; the description adds substantial behavior beyond that — cheap, synchronous, public, symbol-INDEPENDENT, cacheable, ~230 KB unfiltered vs ~5-10 KB filtered, a 12h realtime_cache_ttl_hours boundary, and the meaning of degraded=true ('the table has not been built yet, not that the type is unknown'). It also discloses the provenance honesty axis (mined | declared | pg_depend | static:tasks.py | beat | catalogue | data_model) and warns that `informs` is the weakest edge and must not be presented as lineage.

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?

Well front-loaded and visually structured with `===>` markers and a clear filter block, but roughly half the text enumerates what an event_type card and relation card carry (about, persisted_in, entails.<layer>, precedes, episodes, deepened_by, informs, evidence), which duplicates return-value documentation that an output schema already covers. Several paragraphs restate the same caching/requisite point, so the length is not fully earned.

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 zero-required-parameter, four-filter ontology reader with an output schema and a readOnly annotation, the description covers everything an agent needs: what it returns, when to prefer `situate`, cost/size expectations, cacheability, and the freshness comparison rule that motivates the tool's existence. No material gap remains for correct invocation.

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 already documents each filter, but the description adds a real constraint absent from the schema: 'Pass exactly ONE filter for a small card' and the no-filter case ('the whole class graph, 21 event types, ~300 relations'). It also supplies the join contract with `get_company_event_web` (pass a node's `type` as event_type, its `relation` as relation, its `family` as family), which meaningfully disambiguates the string values.

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 resource with a precise framing: 'the platform's event ONTOLOGY — what an event TYPE means for everything else', and explicitly separates itself from `situate` and `get_company_event_web` by describing which slice each returns. An agent can distinguish this from all ~55 siblings without opening a 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?

Explicit when-to-use ('Call it FIRST on any real-time, single-company, or event-driven request', 'REQUISITE for... BEFORE aiming explore_data_catalogue or generate_report_for_stock'), explicit alternative ('for a named company, situate(symbols=[...]) ... start there'), and explicit when-to-call-directly (FULL card, relation card, whole family, unfiltered graph). Also names a downstream decision rule: use intraday tools when next_run_at is after the event.

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

All Flexreport Finance toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources