Skip to main content
Glama

AkkruData

by ai.akkrudata
OverviewDiscussionsAdmin

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); any symbol the company has traded under. 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. Changed1 schema field changed
    • changedInput schema / properties / ticker / description
      Previous value: -"Company 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."New value: +"Company ticker, e.g. \"AAPL\" (US), \"000100\" (Korea), \"1332\" (Japan), \"VIRI_F\" (Europe), \"600519_CN\" (China A-share); any symbol the company has traded under. Use with fiscal_year when filing_id is omitted."
  2. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare read-only, idempotent, non-destructive behavior, and the description goes well beyond them: credit pricing per mode (28 vs tiered 28/48), the 0-match → 404 contract, the concrete response shape, and the context-saving tradeoff of light_weight_mode with the assurance it is 'charged identically'. This is exactly the kind of behavior an agent cannot infer from structured fields.

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?

It is a single dense paragraph rather than a list, but every clause carries load: mode definitions, pricing, jurisdiction limits, sibling routing, prerequisite, scoping, and return shape. Front-loads the core purpose and the two modes; the length is justified by the tool's breadth, though the run-on structure slightly hurts scannability.

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 an 8-parameter tool with no output schema, the description supplies the missing pieces: the exact response shape, the 404-on-zero-matches case, and the light-weight payload variation. Nothing needed to call this correctly is left unstated.

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; the description adds a little beyond the schema, chiefly the mutual-exclusivity constraint restated at the mode level and the cost differential between role_label and statement_type. It does not, however, add much about filing scoping composition (filing_id vs ticker + fiscal_year + quarter) beyond what the schema already documents.

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 ('Return extracted financial statement block(s) for a filing') and immediately distinguishes itself from sibling tools by naming get_income_statement, get_balance_sheet, and the other dedicated statement tools, plus list_filing_statements as the discovery step. An agent can route correctly without reading any 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?

Explicitly enumerates both lookup modes and declares them mutually exclusive ('pass exactly one'), states when statement_type is unavailable ('SEC filings only ... use role_label for those'), gives the prerequisite 'Use list_filing_statements first', and points to dedicated tools for the 5 main statements. Both when-to-use and when-not-to-use are covered.

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

All AkkruData 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