Skip to main content
Glama

Financial Concept Lookup

GetFinancialFact
Read-only

Retrieve a company's financial concept over time, such as revenue, net income or diluted EPS, from SEC XBRL facts and non-US issuer filings, using restated or as-reported values.

Instructions

Get a single financial concept (e.g. revenue, net income, diluted EPS, total assets, operating cash flow) over time for a company, sourced from SEC Company Facts (structured XBRL), or from the issuer's regulatory filings for a listing outside the US. Returns a time series using the latest restated value unless asOriginallyReported is set: one row per fiscal period for flows, one row per as-of date for balances and share counts. Each row carries its actual period start/end; fiscal years/quarters follow the company's own fiscal calendar. Warns when the selected alias ends materially before the company's other structured facts, which can indicate an XBRL tag change. Dimensioned disclosures such as customer concentration are outside this consolidated-series tool. For a full statement use GetFinancialStatement; to compare peers use CompareFinancialFact.

Input Schema

NameRequiredDescriptionDefault
formNoOptional SEC form filter, e.g. '10-K' or '10-Q'
tickerYesStock ticker symbol (e.g., AAPL, MSFT); a listing on another exchange is MIC:TICKER (XPAR:AIR).
toDateNoOptional latest period-end date, YYYY-MM-DD
conceptYesConcept alias, e.g. 'revenue', 'net-income', 'eps-diluted', 'total-assets', 'operating-cash-flow'. Call with an unknown value to list supported aliases.
fromDateNoOptional earliest period-end date, YYYY-MM-DD
maxResultsNoMaximum periods to return, newest first (default 40, max 200)
fiscalPeriodNoOptional fiscal-period filter: 'FY' (annual only) or 'Q1'..'Q4'. Note that discrete Q4 rows exist only where the filer reported a discrete fourth quarter (most large filers stopped after ~2021).
asOriginallyReportedNoWhen true, show the earliest canonical periodic filing instead of the latest restatement within that source priority. Default false.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

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 carries the behavioral burden and does so well: it discloses the restated-vs-originally-reported default, the row semantics for flows vs balances, the fiscal-calendar behavior, and a warning emitted when an alias ends materially early (tag change). This is rich context beyond the read-only hint.

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 what the tool returns and its source, then the restatement and period-row behavior, then routing to siblings. Dense but every sentence earns its place; slightly long, but nothing is wasted.

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?

With no output schema, the description must explain the return shape and it does: one row per fiscal period for flows, one per as-of date for balances, each row carrying actual period start/end, plus the early-alias warning. Nothing an agent needs to invoke or interpret this tool correctly is missing.

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 baseline is 3, but the description adds real meaning for asOriginallyReported (earliest canonical filing vs latest restatement) and clarifies period semantics tied to fiscalPeriod and the fiscal calendar. It stops short of adding syntax detail for form/fromDate/toDate beyond what the schema already states.

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+resource (get a single financial concept over time for a company), lists concrete concept examples, and names the data source (SEC Company Facts / issuer filings). It explicitly differentiates from siblings by pointing to GetFinancialStatement for full statements and CompareFinancialFact for peer comparison.

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?

Gives explicit routing: use GetFinancialStatement for a full statement, CompareFinancialFact for peers, and states the scope boundary that dimensioned disclosures like customer concentration are outside this consolidated-series tool. When and when-not are both covered.

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