Skip to main content
Glama

Get a filing statement

get_filing_statement
Read-onlyIdempotent

Return extracted financial statement block(s) for a filing. Two lookup modes (mutually exclusive — pass exactly one): (1) role_label — the filer's original XBRL role string (e.g. 'CONSOLIDATED STATEMENTS OF OPERATIONS' for AAPL; varies per filer); tiered 28/48 credits. (2) statement_type — canonical statement name (e.g. 'Income Statement', 'Balance Sheet', 'Comprehensive Income', 'Stockholders Equity', 'Cash Flow Statement'), 28 credits; available for SEC filings only (other jurisdictions coming soon — use role_label for those). The 5 main statements also have dedicated tools: get_income_statement, get_comprehensive_income, get_balance_sheet, get_cash_flow_statement, get_equity_statement. Use list_filing_statements first to discover what statement_type / role_label values a particular filing actually has. Scope the filing with filing_id OR ticker + fiscal_year (+ optional quarter); form_type defaults to 10-K — pass 20-F or 40-F for foreign issuers; Korean (DART) filings use 10-K / 10-Q. Response shape: {matches: [{block_index, role_label, statement_type, matched_via, block}, ...]}; matches is length 1 for role_label mode, 0..N for statement_type mode (0 → 404). light_weight_mode=true omits block.child_components and a few verbose per-fact fields — saves context when you already know exactly what you need. Charged identically. POST /api/v1/data/statement; FINANCIAL_API_DOCUMENTATION.md.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tickerNoCompany ticker, e.g. "AAPL" (US), "000100" (Korea), "1332" (Japan), "VIRI_F" (Europe), "600519_CN" (China A-share). Use with fiscal_year when filing_id is omitted.
quarterNoQuarter label, e.g. "Q1"–"Q4" or "FY". Only needed to disambiguate quarterly filings.
filing_idNoNumeric filing id (from list_filings). Provide either filing_id, or ticker + fiscal_year.
form_typeNoFiling form. US: "10-K" / "10-Q"; foreign annual: "20-F" / "40-F"; Korean (DART): "10-K" (annual) / "10-Q" (quarterly). Defaults to "10-K".10-K
role_labelNoThe filer's original XBRL role string, e.g. "CONSOLIDATED STATEMENTS OF OPERATIONS" (varies per filer; ≤ 4000 chars). Pass exactly one of role_label or statement_type.
fiscal_yearNoReporting fiscal year (1990–2100). Required together with ticker when filing_id is omitted.
statement_typeNoCanonical statement name, e.g. "Income Statement" / "Balance Sheet" / "Comprehensive Income" / "Stockholders Equity" / "Cash Flow Statement" (case-insensitive). Pass exactly one of role_label or statement_type.
light_weight_modeNoWhen true, return a leaner payload (drops the most verbose nested fields). Charged the same. Saves context when you already know exactly what you need.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Beyond the readOnly/idempotent/destructive annotations, the description discloses mutually exclusive lookup modes, tiered credit costs, a 404 when statement_type yields zero matches, response shape, and light_weight_mode payload changes. It even notes that light_weight_mode is charged identically, which an agent cannot infer from annotations or schema.

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 information-dense and front-loaded with the core behavior and differentiation. Some content repeats schema parameter descriptions (mutual exclusivity, light_weight_mode), and the trailing endpoint/file pointer adds noise, but the structure is transparent and scannable.

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 two-mode, 8-parameter tool with no output schema, the description supplies the response shape, lookup semantics, filing scoping rules, credit implications, and sibling tool routing. Nothing an agent needs to decide between modes or construct a valid request is missing.

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 adds essential cross-parameter meaning: exactly one of role_label/statement_type, filing_id OR ticker+fiscal_year scoping, form_type defaults and DART mapping, and canonical statement names. It also enriches role_label with a real-world example (AAPL) and explains statement_type's SEC-only availability.

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 opens with a specific verb+resource ('Return extracted financial statement block(s) for a filing') and immediately distinguishes this general tool from five dedicated siblings (get_income_statement, get_balance_sheet, etc.). It also names the companion discovery tool list_filing_statements, making the tool's role unambiguous.

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 explicitly routes usage: use the five dedicated tools for main statements, use list_filing_statements first to discover valid role_label/statement_type values, and use role_label for non-SEC filings where statement_type is unavailable. This is direct when-vs-alternative guidance with no reliance on 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