Skip to main content
Glama

company_financials

Read-only

A company's EDGAR financial statements, read directly — the targeted tool for "what did X report", revenue / EPS / margins / cash flow by quarter or year, and the tables a financials_release refreshes.

===> Prefer this over explore_data_catalogue for one company's reported statements:
it is synchronous, takes seconds, and returns the rows directly. In a `situate`
result the relation cards of these six tables list it in `read_by`: when one of them
refreshed for the event (a same_chain_run edge to it in the web), call this with
financial_type=<that table>.

TABLES (`financial_type`, each value is the table name):
  edgar_quarterly_financials (default)  standardized quarterly statements
  edgar_annual_financials               standardized annual statements
  edgar_10q_financials / edgar_10k_financials
                                        the facts AS FILED (XBRL concepts) with
                                        accession and filing_url
  edgar_eight_k                         financial tables extracted from 8-Ks
  edgar_financials_yoy_change_m         year-over-year change per line item

PASS line_items. The standardized tables hold dozens of line items per period, the
as-filed tables hundreds of facts: an unfiltered edgar_10q_financials pull cost
28K-108K tokens in testing and was only ever made "for provenance". It is never
needed for that — cite a row with `trace_data_sources` (below) instead.

Rows come back newest period first. A standardized row is {date, fiscal_year, period,
reported_currency, filing_date, accepted_date, symbol, statement, line_item, value,
mapping, last_updated}; `mapping` holds the accession, filing date, XBRL inputs and the
formula. netIncome appears TWICE per quarter — once from the income statement, once
from the cash flow statement; read the `statement` column.

STALE YoY: edgar_financials_yoy_change_m refreshes after the transcript arrives and at
19:00 ET on weekdays, so on the evening of a print it can still show the PRIOR quarter.
Treat it as stale unless its current_period matches the latest date in
edgar_quarterly_financials, and compute the change from the 5 quarters there instead.

CITE A ROW: trace_data_sources(relation=<this financial_type>, keys=[{"symbol": "MAR",
"date": "2026-09-30", "statement": "income statement", "line_item": "epsDiluted"}])
returns the 10-Q / 10-K and its sec.gov link. For the YoY view the keys are symbol,
line_item and current_period.

US SEC filers only (the EDGAR side); a non-filer has no rows here — situate's
`source_routing` says which side a company is on. A 404 means the symbol is not
covered (onboard_symbol), a 422 a bad argument. Requires auth (your MCP client
attaches the OAuth bearer automatically).

Input Schema

NameRequiredDescriptionDefault
limitNoMost recent periods to return (1-12, default 5). 5 quarters include the same quarter last year; lower it only when the year-ago comparison is not wanted.
symbolYesCovered ticker, e.g. "MAR".
line_itemsNoOnly these line items (max 50). Standardized camelCase names for the standardized and growth tables, e.g. ["revenue", "operatingIncome", "netIncome", "epsDiluted", "operatingCashFlow", "freeCashFlow"]; XBRL concepts for the as-filed tables, e.g. ["us-gaap_Revenues"]. Not allowed for edgar_eight_k.
financial_typeNoThe table to read (default edgar_quarterly_financials). Standardized statements: edgar_quarterly_financials / edgar_annual_financials. As filed (XBRL facts with accession and filing_url): edgar_10q_financials / edgar_10k_financials — pass line_items. edgar_eight_k: financial tables from 8-Ks. edgar_financials_yoy_change_m: year-over-year change per line item.edgar_quarterly_financials

Output Schema

NameRequiredDescriptionDefault
noteNoSet only when no rows came back: what an empty result can mean.
rowsYesNewest period first. Standardized rows: date, fiscal_year, period, reported_currency, filing_date, accepted_date, symbol, statement, line_item, value, mapping (accession, XBRL inputs, formula), last_updated. As-filed rows carry concept, accession and filing_url.
countYesRows returned.
symbolYes
financial_typeYesThe table read; pass it as trace_data_sources(relation=...) to cite a row.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedOutput schema / properties / note
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "Set only when no rows came back: what an empty result can mean.",
      +  "title": "Note"
      +}
  2. Added

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the readOnlyHint annotation, the description discloses important behavior: the call is synchronous, returns rows directly, and can be very token-expensive if as-filed tables are pulled without line_items. It also warns about newest-first ordering, duplicate netIncome rows across statements, stale YoY data, auth requirements, and error semantics.

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?

The description is long, but it is front-loaded and clearly structured with headings for tables, line_items, row shape, stale YoY, citation, and access constraints. Nearly every section earns its place, though some prose around the token-cost warning and citation workflow could be tightened.

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 tool's complexity, multiple financial tables, high token-cost risk, and output schema, the description is complete enough for an agent to call it correctly. It covers routing, table selection, filtering, return ordering, citation, stale data, auth, and error handling.

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%, so the baseline is 3, but the description adds meaningful operational semantics for financial_type values, line_items usage, and the stale YoY caveat. It explains which tables are standardized versus as-filed and how line_items should be chosen, though it adds little beyond the schema for the limit parameter.

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?

The description states a specific verb and resource: reading a company's EDGAR financial statements, including revenue, EPS, margins, and cash flow by quarter or year. It also distinguishes the tool from siblings by explicitly saying to prefer it over explore_data_catalogue for one company's reported statements and by linking its use to situate's read_by relation cards.

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?

It gives explicit when-to-use guidance: use this for one company's reported statements, especially when a relation card lists it in read_by after a table refresh. It names the main alternative, explore_data_catalogue, explains why this tool is preferable, and adds edge-case guidance for non-filers, 404s, and 422s.

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