Skip to main content
Glama

get_financial_statement

Read-onlyIdempotent

Get a full financial statement (income statement, balance sheet or cash flow) with line-item detail, for US (SEC XBRL) and Nordic (HEL, STO; ESEF annual filings) companies, in one shape for both. For a compact KPI summary use get_company_financials. Each metric carries metric_name (filing label), metric_name_en for US companies (use it for display), value, unit and currency.

Nordic companies have annual line items only: a quarterly request returns a quarterly_line_items_not_available error with alternatives (get_company_financials(period_type="quarterly"), search_filing_content).

Args: company: Name or ticker, e.g. "Apple", "AAPL". statement: "income_statement" (default), "balance_sheet" or "cash_flow". years: Most recent periods to return (1-25, default 10). market: "nordic" or "us"; omit to auto-detect (the Nordic result wins when both exist). period_type: "annual" (default), "quarterly" or "auto" (US: both mixed, newest first; Nordic: annual with a note). year / quarter: Filter to the company's OWN fiscal year / quarter (1-4), not calendar periods: check each period's period_end. min_coverage: Drop periods below "complete" (>= 80% of core line items), "partial" (30-79%) or "sparse"; omit to keep all and read each period's coverage_status.

Returns: periods[] (year, quarter, coverage_status, missing_core_metrics, metrics) with per-figure source_url, coverage_summary, sources[] and source_policy. Cite with sources[].citation_markdown; never print a raw page_id. US quarterly periods carry no filing link. On miss: {"error", "company", "tried_markets"}.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "company": "<company>"
    },
    "name": "get_financial_statement"
  }
}

Input Schema

NameRequiredDescriptionDefault
yearNo
yearsNo
marketNo
companyYes
quarterNo
statementNoincome_statement
period_typeNoannual
min_coverageNo

Output Schema

NameRequiredDescriptionDefault

No arguments

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?

Annotations already cover readOnly/idempotent/non-destructive, and the description goes well beyond them: the Nordic quarterly void returns a named error with alternatives, market auto-detect resolves to Nordic when both exist, US quarterly periods lack filing links, and misses return {error, company, tried_markets}. It also discloses citation policy (use sources[].citation_markdown, never raw page_id), which is unusual and useful operational context.

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 purpose and sibling routing, then Args, then Returns — a clean structure with no filler sentences. It is long, and the Returns block partially restates a field-level contract that an output schema already exists for, so a little could be trimmed without losing meaning.

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 zero schema description coverage, the description covers every parameter, the cross-market behavioral differences, the error contract, and the citation requirement. Nothing an agent needs to invoke it correctly 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?

Schema description coverage is 0%, so the description carries the full burden and does: it enumerates allowed values for statement, market, and period_type, gives the years range (1-25, default 10), defines min_coverage thresholds (complete >=80%, partial 30-79%, sparse) with omit-behavior, and crucially warns that year/quarter are the company's OWN fiscal periods, not calendar periods.

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 ('Get a full financial statement') with the exact sub-resources (income statement, balance sheet, cash flow), the granularity ('line-item detail'), and the coverage (US SEC XBRL, Nordic ESEF). It also names the sibling it is not ('For a compact KPI summary use get_company_financials'), so an agent can separate it from alternatives without opening a 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?

Explicit routing is given: compact KPIs go to get_company_financials, full detail goes here. It also names concrete fallbacks for the Nordic quarterly case (get_company_financials(period_type="quarterly"), search_filing_content), so when-not and alternatives are both covered.

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.