Skip to main content
Glama

FinBridge

by kr.gronox.mcp

Korean Company Financials (DART)

get_dart_financials
Read-only

Fetch financial statements of a Korean company from OpenDART (fnlttSinglAcntAll: full single-company statements) and normalize them to standard metrics. Amounts are raw KRW (no scaling); EPS is KRW per share.

Args:

  • corp: Company: Korean name (e.g. '삼성전자'), 6-digit stock code (e.g. '005930'), or 8-digit DART corp_code (e.g. '00126380')

  • year: business year 2015-2026 (default: last year). Annual reports are filed ~March of the following year (FY2025 filed 2026-03).

  • report: 'annual' | 'q1' | 'half' | 'q3' (default 'annual')

  • fs: 'consolidated' | 'separate' (default 'consolidated'). If consolidated statements do not exist, automatically retries separate and says so in notes.

  • response_format: 'markdown' (default, tables) or 'json' (compact)

Returns structured {normalized, accounts}:

  • normalized: {company:{name,id,ticker}, basis, periods:[{period, fiscal_year, currency:'KRW', metrics:{revenue, gross_profit, operating_income, net_income, eps_diluted, assets, liabilities, equity, cash_and_equivalents, operating_cash_flow}}], notes}. Annual reports include the prior-year comparative as a second period.

  • accounts: top ~40 raw statement rows [{sj_div (BS/IS/CIS/CF/SCE), account_nm, account_id, thstrm, frmtrm}].

Examples:

  • {corp: '삼성전자', year: 2024} -> FY2024+FY2023, revenue ~3.0e14 KRW

  • {corp: '005930', year: 2025, report: 'q1'} -> Q1 2025 (3-month income-statement figures)

Use for KR-listed company fundamentals. Don't use for US companies (get_edgar_financials) or for filings text (get_dart_filings). Errors: 'no data' (DART status 013) -> try another year/report or fs='separate'; unknown company -> run search_dart_company first.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
fsNoStatement scope: consolidated(연결, CFS) or separate(별도, OFS). Default consolidated.consolidated
corpYesCompany: Korean name (e.g. '삼성전자'), 6-digit stock code (e.g. '005930'), or 8-digit DART corp_code (e.g. '00126380')
yearNoBusiness year (bsns_year), 2015-2026. Default: last year (2025).
reportNoReport type: annual(사업보고서) | q1(1분기) | half(반기) | q3(3분기). Default annual.annual
response_formatNo'markdown' for tables, 'json' for compact machine-readable outputmarkdown

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
accountsNo
normalizedYes

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the readOnlyHint annotation, the description discloses meaningful behavior: raw KRW amounts, EPS units, automatic fallback to separate statements, prior-year comparatives in annual reports, and exact error conditions. This gives the agent an accurate picture of side effects and edge cases.

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 front-loaded with a clear one-sentence purpose, then organized into Args, Returns, Examples, usage, and Errors sections. It is long, and some Args text duplicates the schema, but for a 5-parameter tool with complex return shape and error behavior, the structure keeps it navigable.

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?

Covers the data source, units, normalization, return structure, defaults, fallback behavior, error codes, and sibling-tool boundaries. With an output schema present and annotations already signaling read-only behavior, nothing material is missing for correct invocation.

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 incremental meaning: filing timing for the year parameter, automatic fs retry behavior, the 3-month nature of Q1 figures, and concrete example corp identifiers. This lifts it above baseline without being maximally additive.

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: 'Fetch financial statements of a Korean company from OpenDART' and normalize them to standard metrics. This makes the tool's role unmistakable and distinguishes it from sibling tools like get_edgar_financials and get_dart_filings.

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 says 'Use for KR-listed company fundamentals. Don't use for US companies (get_edgar_financials) or for filings text (get_dart_filings).' It also tells the agent to run search_dart_company for unknown companies and how to recover from the 'no data' error. This is model routing guidance.

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

All FinBridge toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.2/5.0
Disambiguation4/5

Most tools have clearly distinct resource+action targets, and the overlapping screen_* tools are thoroughly cross-referenced with 'use screen_X instead' guidance. Minor ambiguity exists between get_disclosure_feed, get_dart_filings, and get_dart_major_events, which all surface KR filings from different angles but remain distinguishable.

Naming Consistency5/5

Every tool follows a consistent verb_noun snake_case pattern: get_* for retrievers, screen_* for screeners, search_* for lookups, plus action verbs like analyze_, backtest_, compare_, import_, and query_. Subfamilies (dart_*, edgar_*, fred_*, crypto_*) are consistently prefixed, making tool selection predictable.

Tool Count3/5

37 tools is heavy, and the four momentum screeners (canslim/kell/minervini/schwartz) plus three KR disclosure tools could arguably be collapsed into parameterized variants. However, the server's unusually broad scope—KR/US/TW/JP/EU equities, crypto, macro, portfolio, backtesting—means most tools earn their place, so the count is high but not chaotic.

Completeness4/5

The surface covers the core workflow well: search, prices, fundamentals, filings, insider trades, valuation, screeners, backtesting, and portfolio tracking for KR/US, plus crypto and macro. Notable gaps are the lack of single-company financial-statement tools for TW/JP/EU (only available through screen_companies) and no real-time stock quotes, but these are workable for the stated local-database research purpose.

Resources