Skip to main content
Glama

Get company financials

get_company_financials
Read-only

Return multi-period financial statements (income statement, balance sheet, cash flow) and headline figures such as revenue and net income for a Japanese listed company from its EDINET/XBRL filings. Groups facts by statement type across annual and interim periods. Each period also carries a key_metrics object holding the eight headline figures (revenue, operating_income, net_income, total_assets, equity, current_assets, current_liabilities, total_liabilities), each with its value, concept_id, context_ref and resolved period. key_metrics holds the headline figures: the statement buckets are keyed on the filing's statement-type tagging, and many filers — including those using per-company taxonomy extensions or the five-year 主要な経営指標等の推移 (SummaryOfBusinessResults) concepts — report their consolidated top line outside those buckets, where it would otherwise not appear. Values are CONSOLIDATED figures for the filing period only: non-consolidated (parent-only), segment-dimensional and prior-period values are never reported or substituted, EXCEPT for a filer whose DEI declares (or, absent that DEI element, has) no consolidated statements at all, whose non-consolidated (単体) figures ARE its own figures; every metric with a value carries consolidation_basis (consolidated or non_consolidated) so this is always explicit, never silent. A key metric with no consolidated current-period fact is null and carries an omission_reason (no_consolidated_context, no_current_period_fact, reported_nil, no_numeric_value, owners_equity_not_established, not_applicable_to_statement_format, no_total_concept_in_format, concept_absent); Equity is always equity attributable to owners of the parent. J-GAAP filers report no single concept for it, so it is DERIVED as the owner components (株主資本 + 評価・換算差額等) of 純資産, checked to reconcile with the reported total: a derived metric carries derived: true, concept_id null, and a derivation object listing the reconciled_against total (which includes non-controlling interests and is NOT the value) and every component with its role (owner or non_owner), value, context_ref Metrics read from a single fact carry neither field. Every metric also carries unit and decimals (the XBRL unit and precision of the value). Statement-bucket concepts with no consolidated current-period value are listed in that period's omitted_concepts. Revenue does NOT always mean net sales. A resolved revenue metric carries basis and basis_label (en/ja); basis_label states the meaning, which can differ from the concept name and its taxonomy label. net_sales: 売上高 / revenue of a general filer. operating_revenue: 営業収益 of a general filer. ordinary_revenue_bank and ordinary_revenue_insurance: 経常収益, the GROSS top line of a Japanese-GAAP bank or insurer (interest, fees, premiums, investment revenue). It is revenue, NOT profit, even though its concept is named OrdinaryIncome... and EDINET's English label says 'Ordinary income'; 経常利益 (ordinary profit) is a different line and is never reported as revenue. operating_revenue_securities: gross 営業収益 of a securities firm, before 金融費用. operating_revenue_finance: 営業収益 of a finance, commodity-futures, investment-management or construction-guarantee filer. insurance_revenue_ifrs: IFRS 17 insurance revenue of an IFRS insurer, which excludes investment and other revenue. revenue_financial_filer_unverified: a bank, insurer or securities firm not filing Japanese GAAP whose revenue line's meaning is not established; it is not comparable with net sales. statement_format reports the EDINET industry format (general, bank, insurance, insurance_life, insurance_nonlife, securities, ...), the DEI industry code and accounting standard as filed. operating_margin_denominator is the figure operating margin must divide by: the revenue metric for most filers, but 純営業収益 (basis net_operating_revenue_securities) for a securities firm, whose gross revenue includes interest later deducted as 金融費用. Omission reason not_applicable_to_statement_format: the filing's format has no such line (a Japanese-GAAP bank or insurer has no operating income, current assets or current liabilities, so no operating margin or current ratio); no other subtotal is substituted, and it is not missing data. no_total_concept_in_format: the format tags only component lines for the metric and the filer reported no total. Source: EDINET (https://disclosure2.edinet-fsa.go.jp/), PDL 1.0 (https://www.digital.go.jp/resources/open_data/public_data_license_v1.0). Data is processed by Kabuken, not raw unprocessed FSA data. Figures are calculated by Kabuken from EDINET filings, not reported directly by EDINET. Not investment advice.

Input Schema

NameRequiredDescriptionDefault
periodsNoNumber of most recent filing periods to return (1–20, default 3; values below 1 are treated as 1). The response reports periods_requested and periods_returned; periods_returned is lower when fewer filings are available.
entity_codeYesEDINET entity code (e.g. "E02144" for Toyota).
period_typeNoFilter by filing period type. ANNUAL = 有価証券報告書; INTERIM = semi-annual/quarterly; ALL = both. Default: ANNUAL.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.6/5.0
Behavior5/5

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

Beyond the readOnly/openWorld annotations, the description discloses the critical behavioral traits an agent could not get elsewhere: consolidation basis is explicit per metric, non-consolidated figures are used only when the filer has no consolidated statements, omitted metrics carry enumerated omission_reason codes, and derived equity is flagged with derivation metadata. It also warns about semantic traps, such as 経常収益 being revenue rather than profit and 純営業収益 being the correct margin denominator for securities firms.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is front-loaded in the first sentence, but the body is an extremely dense wall of run-on clauses covering revenue bases, derivation mechanics, omission codes, licensing and disclaimers. Much of this is relevant, but the lack of paragraphs or bullet structure makes it difficult to scan and pushes the description well past a reasonable size.

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 carry the return-value burden, and it does: it explains period grouping, statement buckets, the eight key_metrics fields, omitted_concepts, consolidation_basis, derivation objects, and statement_format. Given the complexity of EDINET/XBRL data, this is essentially complete for correct interpretation of results.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the three parameters are already fully documented. The description reinforces that results span annual and interim periods and multiple periods, but it adds no syntax or constraint detail beyond the schema's own defaults and enum definitions. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence names the specific resource (multi-period financial statements for a Japanese listed company from EDINET/XBRL) and enumerates the statement types and headline figures, which is far clearer than a tautology. It does not explicitly contrast itself with siblings such as get_financial_facts or get_segment_breakdown, so an agent must infer the boundary rather than read it.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no sentence telling the agent when to call this versus alternatives like get_financial_facts or compare_companies, nor any stated prerequisites. The context of retrieving EDINET financials is implied by the topic, but no routing guidance is provided.

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.