Skip to main content
Glama
holon521

mcp-server-fss-dart

by holon521
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

mcp-server-fss-dart

A Model Context Protocol (MCP) server for FSS Open DART (금융감독원 전자공시시스템) with token-efficient footnote parsing, financial anomaly detection, and historical stock price correlation.

Features

This MCP server equips AI Agents (like Claude Code, Cursor, Windsurf, or Gemini) with the following tools to audit Korean companies:

  1. get_corporate_details: Resolves a corporate name or stock ticker to its DART corporate code.

  2. get_financial_anomalies: Evaluates primary accounting metrics (Debt-to-Equity ratio, Current ratio, Net Income) and flags potential accounting red-flags.

  3. get_footnote_section: Semantic footnote query that unzips and extracts relevant report chunks matching keywords like "litigation" (소송), "debt guarantee" (지급보증), or "related party" (특수관계자) to prevent token bloat.

  4. get_stock_chart: Fetches historical stock price trends and Simple Moving Averages (SMA) from Yahoo Finance to correlate financial anomalies with market activity.

Related MCP server: korean-dart-mcp

설치 및 설정 (Installation)

Prerequisites

1. Installation

Clone this repository and install the dependencies:

git clone https://github.com/<your-username>/mcp-server-fss-dart.git
cd mcp-server-fss-dart
pip install .

2. Configuration for Claude Desktop

Add the following block to your Claude Desktop configuration file (e.g. ~/Library/Application Support/Claude/claude_desktop_config.json on macOS or %APPDATA%\Claude\claude_desktop_config.json on Windows):

{
  "mcpServers": {
    "fss-dart": {
      "command": "python3",
      "args": ["-m", "mcp_server_fss_dart.server"],
      "env": {
        "DART_API_KEY": "YOUR_40_DIGIT_DART_API_KEY_HERE"
      }
    }
  }
}

한국어 안내 (Korean Guide)

본 프로젝트는 AI 에이전트가 금융감독원 Open DART API를 통해 한국 기업의 공시자료와 감사보고서 주석을 분석할 수 있도록 돕는 MCP(Model Context Protocol) 서버입니다.

특징

  • 토큰 효율적 주석 분석: 대용량 감사보고서 주석 중에서 "소송", "보증", "특수관계자" 등 핵심 악재 키워드 매칭 문맥만 핀포인트로 파싱하여 AI 에이전트에 공급합니다.

  • 이상징후 사전 탐지: 부채비율 200% 초과, 유동비율 100% 미만, 당기순이익 적자 등의 재무적 위험 신호를 자동으로 계산하여 감지 플래그로 반환합니다.

  • 실시간 주가 차트 연동: 야후 파이낸스(Yahoo Finance)를 통해 실시간 주가 추이와 이동평균선(SMA5, SMA20)을 가져와 기업의 공시 리스크와 주가 변동의 연관 관계를 분석합니다.

실행 방법

상기 설정(Configuration)을 완료한 후, Claude Desktop 또는 MCP 지원 클라이언트를 실행하면 대화창에서 AI에게 다음과 같이 지시할 수 있습니다.

"카카오(035720)의 재무 상태를 분석하고, 2025년도 감사보고서 주석에서 소송 관련 내용이 있는지 찾아줘. 그리고 최근 주가 차트도 요약해 줘."

License

This project is licensed under the MIT License.

Available Tools

4 tools
get_corporate_detailsB

Look up a Korean corporate name or 6-digit stock ticker code to find its DART corp_code and basic profile.

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

B3.4/5.0
Behavior2/5

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

No annotations are provided, so the description must fully disclose behavioral traits. It mentions the lookup action and output, but does not disclose potential issues like no-match behavior, rate limits, authentication requirements, or whether the query is exact or fuzzy. The minimal disclosure is insufficient for a tool without annotations.

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

Conciseness5/5

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

The description is concise at two sentences, front-loading the purpose and input/output. Every clause is necessary and adds value, with no redundant information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (1 parameter, simple lookup) and the presence of an output schema, the description provides a sufficient overview. It covers the essential purpose and parameters. However, completeness is slightly reduced by the lack of usage guidelines and behavioral transparency, but for a basic tool it is adequate.

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?

With 0% schema description coverage, the description partially compensates by specifying that the query can be a Korean corporate name or 6-digit stock ticker code. This adds context beyond the schema's mere 'string' type. However, it does not specify format constraints or examples, so it only moderately adds meaning.

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 clearly states the tool's action ('Look up'), the resource ('Korean corporate'), the input ('name or 6-digit stock ticker code'), and the output ('DART corp_code and basic profile'). It distinguishes well from sibling tools like get_financial_anomalies, get_footnote_section, and get_stock_chart, which have different purposes.

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?

The description does not provide explicit guidance on when to use this tool versus alternatives (siblings). It implies usage when needing to look up corporate details, but lacks when-not conditions or comparisons, leaving the agent without clear selection criteria.

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

get_financial_anomaliesB

Analyze key financial metrics (Debt ratio, current ratio, operating profit trend) and scan for potential accounting anomalies or distressed patterns for a given year (e.g. 2025).

ParametersJSON Schema
NameRequiredDescriptionDefault
yearYes
corp_name_or_codeYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

B3.2/5.0
Behavior2/5

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

No annotations provided; description only mentions the analysis and scanning function. Lacks disclosure of behavioral traits like read-only nature, authentication needs, rate limits, or what constitutes an 'anomaly'.

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?

Description is a single sentence, concise and to the point, but lacks structural elements like paragraphs or bullet points that could improve readability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the presence of an output schema, the description does not need to detail return values, but it omits information about the output format or what constitutes an anomaly, leaving some gaps for a tool of moderate complexity.

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?

With 0% schema description coverage, description adds minimal meaning: clarifies year expects a format like '2025' and corp_name_or_code is a corporate identifier. Does not elaborate on valid values or syntax.

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?

Description clearly states the tool analyzes key financial metrics (Debt ratio, current ratio, operating profit trend) and scans for anomalies/distressed patterns for a given year, distinguishing it from sibling tools like get_corporate_details or get_stock_chart.

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?

No explicit guidance on when to use or not use this tool versus alternatives. Only implies usage for financial anomaly detection without contextual conditions.

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

get_footnote_sectionB

Query the corporate audit footnotes and extract relevant sections matching specific risk keywords (e.g. '소송', '보증', '특수관계자', '담보') to identify hidden liabilities.

ParametersJSON Schema
NameRequiredDescriptionDefault
yearYes
keywordYes
corp_name_or_codeYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

B3.4/5.0
Behavior2/5

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

No annotations are provided, so the description carries full weight. It states it 'extracts relevant sections' matching keywords, but does not disclose important behavioral traits such as whether it returns full footnotes or only excerpts, how matches are ordered, error handling for missing data, or any limitations (e.g., single year only). This lack of transparency hinders the agent's ability to predict tool behavior accurately.

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 a single, focused sentence that front-loads the action and includes relevant keyword examples. It is efficient and contains no unnecessary words. However, it could be slightly improved by separating the purpose from the examples for even faster scanning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 3 required parameters and no annotations, the description provides a clear purpose and partial parameter guidance but lacks details on behavioral expectations (e.g., output format, error handling). The presence of an output schema reduces the need to describe return values, but other contexts like pagination or edge cases are unaddressed. The description is adequate but not complete.

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 0% meaning no descriptions for individual parameters. The description compensates partially by explaining the 'keyword' parameter through examples, but 'year' and 'corp_name_or_code' are not described beyond their names. The context implies that 'corp_name_or_code' identifies the company and 'year' selects the fiscal year, but this is not explicit. Overall, the description adds some value but does not fully compensate for the lack of schema descriptions.

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 clearly states it queries corporate audit footnotes to extract sections matching specific risk keywords. It provides concrete examples of keywords ('소송', '보증', etc.) and explicitly ties the action to identifying hidden liabilities. The verb 'Query' and resource 'corporate audit footnotes' are specific, and the tool is well-differentiated from siblings like get_financial_anomalies or get_stock_chart.

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

Usage Guidelines3/5

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

The description implies usage for extracting footnote sections with risk keywords to uncover hidden liabilities, but it does not explicitly state when to use or avoid this tool, nor does it mention alternative tools. The context is clear but lacks explicit guidance on exclusions or prerequisites.

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

get_stock_chartA

Fetch historical stock price chart information and simple moving averages (SMA) from Yahoo Finance to correlate financial anomalies with market movements. Use ticker format: '035720.KS' (KOSPI) or '060720.KQ' (KOSDAQ). If suffix is missing, the tool will try both formats automatically.

ParametersJSON Schema
NameRequiredDescriptionDefault
tickerYes
range_strNo1mo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.2/5.0
Behavior4/5

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

No annotations provided, so description carries full burden. It discloses data source (Yahoo Finance), automatic suffix handling, and includes SMA. Could mention more about output, but output schema exists.

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

Conciseness5/5

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

Two sentences, front-loaded, no redundancy. Every word adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given output schema exists, description is fairly complete for a financial data tool. Could mention available ranges, but overall adequate.

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 description coverage is 0%; description explains ticker format well but does not describe range_str parameter beyond default value. Adds value for ticker but not for range.

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 clearly specifies the tool fetches historical stock chart info and SMA from Yahoo Finance, and the purpose of correlating with financial anomalies. It distinguishes from siblings which focus on corporate details, anomalies, and footnotes.

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

Usage Guidelines4/5

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

Provides explicit ticker format and automatic suffix handling. Mentions use case but does not explicitly contrast with siblings or state when not to use.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 4 tool updatesv0.1.0
    • First observedget_corporate_details
    • First observedget_financial_anomalies
    • First observedget_footnote_section
    • First observedget_stock_chart
Deploy Server
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

TDQS

A3.8/5.0

Scored across 4 tools

Disambiguation5/5

Each tool targets a clearly distinct aspect: company lookup, financial anomaly analysis, footnote extraction, and stock chart data. No overlapping functionality.

Naming Consistency5/5

All tool names follow a consistent 'get_' prefix and snake_case pattern, making them predictable and easy to distinguish.

Tool Count5/5

Four tools is well-scoped for a specialized financial analysis server, covering key areas without being too sparse or bloated.

Completeness4/5

The set covers the core workflow from company details to anomaly detection, footnote mining, and market correlation. Minor gaps exist (e.g., no direct financial statement extraction) but the surface is largely complete for its stated purpose.

Maintenance

ActivitySlowing
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • Korean Company Information MCP

    SeoNaRu
    F
    license
    Not graded
    quality
    D
    maintenance
    Enables AI agents to query Korean listed companies' financial statements, public disclosures, executive information, and shareholder structures in real-time using the DART API.
    2
    -

  • korean-dart-mcp

    aesthetic-legalism5470
    A
    license
    A
    quality
    C
    maintenance
    Enables AI assistants to analyze Korean financial disclosures (DART) with insider trading signals, accounting risk scores, Buffett-style quality checklists, and automatic conversion of HWP/PDF attachments to markdown.
    15
    203 npm
    3
    MIT

  • opendart-mcp-server

    SongHyojun0228
    A
    license
    Not graded
    quality
    D
    maintenance
    Enables AI agents to access Korean corporate disclosure data from DART, allowing natural language queries about companies, financial statements, and disclosures.
    33 npm
    2
    MIT

  • Korea Stock Insight MCP

    yjhann33-design
    A
    license
    A
    quality
    C
    maintenance
    Enables LLM agents to access Korean stock market data including DART disclosures, financial statements, and KOSPI/KOSDAQ prices, with an English-first interface designed for non-Korean speaking analysts.
    6
    MIT