Flexreport Finance

list_options

Read-only

Enumerate the valid values for a parameter, straight from the backend.

Call this BEFORE guessing a parameter value. `kind` selects which catalog; three
kinds are scoped by a query parameter (`ticker`, or `q` / `cik`) and refuse the call
without it:

- "event_types"                  -> valid `event_type` for `list_realtime_events`
                                    (eps_update, company_update, biggest_mover, ...)
- "financial_items"              -> standardized EDGAR line items ("revenue",
                                    "operatingIncome") for a CUSTOM report's
                                    `financial_items` (`generate_report_for_stock`,
                                    or a scheduled "create-full-report" step)
- "financial_ratios"             -> EDGAR ratios ("grossProfitMargin") for that
                                    report's `ratios`
- "as_reported_items"            -> NEEDS `ticker`. The filer's OWN tagged XBRL
                                    concepts from its 10-Q / 10-K filings — {concept,
                                    statement_type, label, standard_concept,
                                    latest_period, facts} — for a custom report's
                                    `as_reported_financial_items`
- "revenue_segments"             -> NEEDS `ticker`. The filer's revenue segments as
                                    tagged in its filings — {product_label,
                                    product_member, product_axis, concept,
                                    latest_period, facts} — for a custom report's
                                    `revenue_segment` (pass the product_label).
                                    A name lookup only: never sum members across it
- "institutional_managers"       -> NEEDS `q` (name fragment, e.g. "berkshire")
                                    and/or `cik` (SEC CIK, any width). Managers as
                                    {cik, name, category, aum}, largest AUM first —
                                    pass the `cik` values as a custom report's
                                    `institutional_ownership`, never the names
- "sectors"                      -> valid `sector` filter values
- "institutional_investor_types" -> investor CATEGORIES (not managers) — the keys
                                    `screen_stocks(institutional_ownership=...)`
                                    filters on
- "countries"                    -> covered countries
- "fiscal_quarter"               -> the most recent fiscal quarter being reported
- "market_cap"                   -> valid `market_cap` buckets (Small-cap,
                                    Medium-cap, Large-cap, Mega-cap)
- "intraday_frequency"           -> supported intraday chart frequencies
- "technical_indicators"         -> indicator names accepted by
                                    `get_technical_indicator_data` (rsi, macd,
                                    sma_50, ...); an unknown indicator there
                                    returns a 400 listing this set
- "tickers"                      -> the full covered symbol universe as bare
                                    symbols — equities PLUS ~420 market indices
                                    as caret-prefixed symbols (^GSPC, ^VIX, ...).
                                    NOTE: thousands of names — a large payload
- "tickers_with_names"           -> {symbol, company_name} pairs for the company
                                    universe ONLY — market indices are NOT in
                                    this list, only in "tickers" (an even larger
                                    payload)

Returns `options` (the values for that kind). Authoritative and never stale: it
reads the backend's live config, not a hardcoded list. Public — no auth required.

Input Schema

TableJSON Schema

Name	Required	Description
`q`	No	Manager name fragment, e.g. "berkshire" (institutional_managers).
`cik`	No	SEC CIK, any width, e.g. "1067983" (institutional_managers).
`kind`	Yes	Which catalog to list; see the kinds below.
`ticker`	No	Filer ticker, e.g. "AAPL". Required for as_reported_items and revenue_segments.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`kind`	Yes	The catalog that was listed.
`options`	Yes	The valid values. Usually a list — bare strings for most kinds, records for event_types, tickers, tickers_with_names, as_reported_items, revenue_segments and institutional_managers. fiscal_quarter is a single quarter number.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 15, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations only declare readOnlyHint=true, but the description adds material behavior beyond that: it is authoritative because it reads live backend config (never stale), it is public with no auth required, it enumerates rejection behavior for the query-scoped kinds, and it warns about payload size for tickers/tickers_with_names. That is substantially more than the annotation provides.

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 key imperative and organized as a scannable bulleted catalog, with no filler sentences. It is nonetheless a very long block, which is largely forced by the 15 enum values but does weigh on context budget for a lookup tool.

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?

An output schema exists, so return-value documentation is not required, and the description still notes the returned `options` field. Combined with the per-kind routing, conditional-parameter rules, and payload/auth notes, all information needed to call it correctly is present.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although schema coverage is 100%, the description goes well beyond the schema's flat enum: it defines the semantic content of each kind (e.g. financial_items vs as_reported_items, managers-as-CIKs vs investor categories), states the conditional requirement of ticker/q/cik per kind, and prescribes how returned values must be passed downstream.

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 — enumerate the valid values for a parameter from the backend — and immediately frames the tool as a pre-flight lookup rather than a data-fetch. An agent can distinguish it from siblings like list_realtime_events or generate_report_for_stock because the description says this tool supplies the values those tools consume.

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 instructs 'Call this BEFORE guessing a parameter value,' names which kinds require the ticker/q/cik qualifiers and that they refuse without it, and routes every kind to the consuming tool/parameter (e.g. event_types -> list_realtime_events, institutional_managers -> a report's institutional_ownership). This is exactly when/when-not/alternatives guidance.

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

All Flexreport Finance tools Inspect

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

Need Help?