Skip to main content
Glama
deenesjakoruzh
agentladle

mcp-dart

by agentladle
OverviewSchemaSourceRelated ServersScoreDiscussionsAdmin
Python
Remote

AgentLadle MCP DART

English | 中文

🇨🇳/🇭🇰 A株・香港上場企業向けのクラウドホスト型MCP（過去3年分の年次報告書と最新の中間報告書）。続きを読む | APIキーを取得

韓国のDART財務報告書（금융감독원 전자공시시스템）の発見、ダウンロード、解析、検索のためのツールを提供するMCP（Model Context Protocol）サーバーです。

これにより、AIアシスタント（Claude、Cursorなど）は、6つの構造化ツールを通じて韓国のOpen DARTデータにアクセスできます。企業名の解決からレポートページ内のキーワード検索までをカバーします。

機能

  • DARTデータ用の6つのMCPツール：企業名の解決、開示情報の一覧表示、ダウンロード＋解析、目次取得、ページ読み取り、キーワード検索

  • 정기공시財務報告書の完全サポート — A001 사업보고서（年次）、A002 반기보고서（半期）、A003 분기보고서（四半期）。それぞれに、実際のDART XMLから導出された専用のtoc.yamlセクションマッピングがあります。

  • 形式を自動検出するマルチフォーマットパーサー — 構造化されたSECTION-N XML（A/B/D/Eタイプ）はセクションツリーパーサーにルーティングされます（利用可能な場合はtoc.yaml、それ以外の場合は汎用ツリー抽出）。HTMLの単一ページ開示（I001 수시공시、I002 공정공시/잠정실적）はHTML抽出パーサーにルーティングされます。形式はファイルの内容によって検出され、タイプによってハードコードされません。

  • プロフェッショナルなDART文書解析 — XMLパス直接抽出（./P、./TABLE）と標準目次整列（A001：123コード / 110リーフ、A002：53コード / 43リーフ、A003：59コード / 48リーフ）

  • セクションツリー＋セクション内ページ制限ページネーションモデル — ページはDARTの標準セクションツリーを尊重します（固定4000文字チャンクではなく正確性を重視）

  • 韓国語対応検索 — 部分文字列マッチング（\b単語境界なし）、文字数ベースのTF正規化、形態変化のヒント

  • 3層ローカルキャッシュ — ZIPアーカイブ、抽出済みXML、解析済みJSONを~/.agentladle/mcp-dart/data/{zip,xml,json}/の下に分けて保存

  • 冪等 — ダウンロード済み/解析済みの開示書類は自動的にスキップされます

  • Pure Python、クロスプラットフォーム（Windows / macOS / Linux）

Related MCP server: MCP OpenDART

前提条件

注意： uvをインストールしたら、ターミナルとMCPクライアント（例：Cherry Studio）を再起動して、uvコマンドが認識されるようにしてください。

クイックスタート

MCPクライアントの設定（Claude Desktop、Cursorなど）に追加します：

{
  "mcpServers": {
    "mcp-dart": {
      "command": "uvx",
      "args": ["agentladle-mcp-dart"],
      "env": {
        "DART_API_KEY": "your_dart_api_key_here",
        "UV_HTTP_TIMEOUT": "300"
      }
    }
  }
}

これだけです。uvxがPyPIからパッケージと依存関係を自動的にダウンロードします。クローンも手動インストールもパス設定も必要ありません。

ネットワークが遅い場合？ 初回のuvx実行では多くの依存関係（dart-fss、pandasなど）をダウンロードします。デフォルトの30秒タイムアウトでは短すぎて、MCP Connection closedが発生する可能性があります。ダウンロードのタイムアウトを避けるには、UV_HTTP_TIMEOUTを"300"に設定してください。それでも失敗する場合は、以下のpip installの代替方法を使用してください。

代替：.envファイル

MCPクライアントのenvブロックでキーを注入したくない場合は、.env.exampleを次のいずれかにコピーしてください：

  • ./.env（プロジェクトごとの上書き；git無視対象 — 実際のキーをコミットしないでください）

  • ~/.agentladle/mcp-dart/.env（ユーザー全体のデフォルト）

そして設定します：

DART_API_KEY=your_dart_api_key_here

最初に見つかった.envが優先されます。MCPクライアントで明示的に設定された環境変数は常に.envより優先されます。詳細は.env.exampleを参照してください。

代替：pip install

自分で環境を管理したい場合：

pip install agentladle-mcp-dart

その後、設定します（uvxは不要です）：

{
  "mcpServers": {
    "mcp-dart": {
      "command": "agentladle-mcp-dart",
      "env": { "DART_API_KEY": "your_dart_api_key_here" }
    }
  }
}

代替：ソースから実行（ローカル開発）

リポジトリをクローンして直接実行します：

git clone https://github.com/agentladle/mcp-dart.git

次にMCPクライアントを設定します：

{
  "mcpServers": {
    "mcp-dart": {
      "command": "uv",
      "args": ["run", "--directory", "/path/to/mcp-dart", "agentladle-mcp-dart"],
      "env": { "DART_API_KEY": "your_dart_api_key_here" }
    }
  }
}

/path/to/mcp-dartをクローンしたリポジトリの実際のパスに置き換えてください。

データフロー

DART OpenAPI                      Local Files (~/.agentladle/mcp-dart/data/)
────────────                      ──────────────────────────────────────────
corp_list (dart-fss)  ──→         corp_list.csv                (CSV cache, ~114k corps)
search_dart_company    ──→        corp_list.csv lookup         (Tool 6: name → stock_code)
                                     │
search_filings API     ──→        zip/{rcept_no}.zip           (Tool 2: download)
                                     │
ZIP extraction         ──→        xml/{rcept_no}/*.xml           (Tool 2: extract)
                                     │
dart_parsers + toc.yaml ──→       json/{stock_code}_{rcept_no}.json  (Tool 2: parse)
                                     │
Local TF search        ──→        search results               (Tool 5: keyword_search)
TOC (section_tree)     ──→        section_tree + page ranges   (Tool 3: get_report_toc)
Page range read        ──→        page content                 (Tool 4: get_report_pages)

ツール

#

ツール

説明

1

list_dart_filings

韓国企業のDART開示情報を株式コードで一覧表示します（rcept_noを返します）

2

download_dart_report

DART開示書類のZIPをダウンロードし、セクションツリーJSONキャッシュに解析します

3

get_report_toc

ページ範囲付きのsection_tree（目次）を取得します — toc.yamlから導出され、ヒューリスティックではありません

4

get_report_pages

グローバルページ番号またはsection_codeでページを読み取ります

5

keyword_search

文字数TF＋位置ブーストによる韓国語部分文字列全文検索

6

search_dart_company

ローカルのcorp_list.csvキャッシュを介して、会社名（韓国語/英語）をstock_code / corp_codeに解決します

ツール1：list_dart_filings

韓国の上場企業で利用可能なDART開示情報を一覧表示します。

パラメータ

型

必須

説明

stock_code

string

✅

6桁の韓国株式コード。例："005930"（Samsung Electronics）

bgn_de

string

❌

開始日 YYYYMMDD（デフォルト：20150101）

end_de

string

❌

終了日 YYYYMMDD（デフォルト：今日）

report_types

string[]

❌

フィルタするDART詳細タイプ（デフォルト：["A001","A002","A003"] — 사업/반기/분기보고서）

limit

int

❌

返す開示情報の最大件数（デフォルト20、最大100）

各開示情報のrcept_no、rcept_dt、report_nm、corp_code、report_type、およびparseableフラグを返します（有効なDARTタイプであればtrue — パーサーは解析時に文書形式を自動検出します）。

ツール2：download_dart_report

単一のDART開示書類をダウンロードして解析します。SECフローのdownload + parseを1ステップに統合します。冪等（キャッシュが有効な場合はスキップされます）。

パラメータ

型

必須

説明

rcept_no

string

✅

14桁のDART受信番号（list_dart_filingsから取得）

stock_code

string

❌

JSONファイル名用の6桁の株式コード（{stock_code}_{rcept_no}.json）。省略時は{rcept_no}.jsonとしてキャッシュされます — rcept_noによる参照は引き続き機能します。

rcept_dt

string

❌

受信日 YYYYMMDD（参考情報）

report_type

string

❌

DART詳細タイプ。デフォルトは"A001"。types.yamlの有効なタイプならすべて受け付けます。パーサーは文書形式を自動検出します（A/B/D/EはセクションツリーXML、I001/I002はHTML）。

force_parse

bool

❌

キャッシュされたJSONが存在する場合でも再解析します

ツール3：get_report_toc

解析済みレポートの完全なDART section_tree（目次）を取得します。解析済みXMLと整列されたtoc.yamlから直接構築されるため、ページ範囲は信頼でき、ヒューリスティックではありません。

パラメータ

型

必須

説明

rcept_no

string

✅

14桁のDART受信番号

stock_code

string

❌

株式コード（キャッシュ検索を向上）

各ノードはsection_code、title、start_page、end_page、local_pages、matched（bool — XMLがこの目次エントリに一致したかどうか）、およびchildrenを持ちます。任意のsection_codeをツール4のsection_codeパラメータに渡すと、そのサブツリー全体を読み取れます。

ツール4：get_report_pages

グローバルページ範囲またはsection_codeで完全なページ内容を読み取ります。

パラメータ

型

必須

説明

rcept_no

string

✅

14桁のDART受信番号

start_page

int

❌

開始ページ（1始まり）。デフォルトは1。section_codeが設定されている場合は無視されます。

page_count

int

❌

返すページ数（デフォルト3、最大10）。end_pageが正の値の場合は無視されます。

end_page

int

❌

終了ページ（両端を含む。例：start_page=12, end_page=14）。0 = 未設定。

section_code

string

❌

DARTセクションコード（例："020100"）。ページ範囲引数を上書きし、サブツリー全体を返します。

stock_code

string

❌

株式コード（キャッシュ検索の補助）

ツール5：keyword_search

韓国語向けの全文検索。スコアリング：

  • TF = 部分文字列の数 / 空白以外の文字数（韓国語には空白で区切られた単語がありません）

  • 最初のヒットがページの上位20%にある場合、位置ブースト×1.2

  • ALLマッチモードでは、すべてのキーワードがヒットした場合に×2.0のボーナス

パラメータ

型

必須

説明

rcept_no

string

✅

14桁のDART受信番号

keywords

string[]

✅

1〜5個の韓国語（またはASCII）キーワード。["매출", "매출액"]のような形態変化を渡します。

match_mode

string

❌

"ANY"（デフォルト）または"ALL"

max_results

int

❌

最大マッチ数（デフォルト5、最大50）

stock_code

string

❌

株式コード（キャッシュ検索の補助）

各マッチはpage_number、score、keyword_hits、snippet（**...**でハイライト）、およびセクションコンテキスト（section_code/section_title）を返します。

ツール6：search_dart_company

会社名（韓国語または英語）をstock_code / corp_codeに解決します。ローカルにキャッシュされたcorp_list.csvを照会します（最初の事前読み込み以降はネットワーク呼び出しなし）。ユーザーが会社名を指定しても6桁のstock_codeを提供しない場合は、list_dart_filings / download_dart_reportの前にこれを使用してください。

パラメータ

型

必須

説明

query

string

✅

会社名（韓国語のcorp_nameまたは英語のcorp_eng_name）。例: "삼성전자"または"Samsung"

exact

bool

❌

true = 名前の完全一致; false（デフォルト）= 大文字小文字を区別しない部分文字列一致

limit

int

❌

最大一致数（デフォルト20、最大50）

include_delisting

bool

❌

true = 上場廃止・非上場企業も返す; false（デフォルト）= 6桁のstock_codeを持つ上場企業のみ

各一致結果にはcorp_name、corp_eng_name、stock_code、corp_code、modify_dateが含まれる。複数の一致結果が返された場合は、正しいstock_codeを選択してlist_dart_filingsに渡す。

設定

初回実行後、デフォルトの設定ファイルが~/.agentladle/mcp-dart/config.yamlに作成される:

dart:
  api_key: ""

paths:
  data_dir: "~/.agentladle/mcp-dart/data"
  zip_dir: "~/.agentladle/mcp-dart/data/zip"
  xml_dir: "~/.agentladle/mcp-dart/data/xml"
  json_dir: "~/.agentladle/mcp-dart/data/json"

parsing:
  page_char_limit: 4000
  max_pages_per_section: 10      # soft target (precision preserved on overflow)

download:
  delay_between_requests: 0.2

DART_API_KEYの解決優先順位（高い順）:

  1. 実際のOS環境変数（DART_API_KEY=xxx uvx agentladle-mcp-dart）

  2. .envファイル — 最初に./.env、次に~/.agentladle/mcp-dart/.env

  3. ~/.agentladle/mcp-dart/config.yaml内のdart.api_key

データディレクトリ構造

~/.agentladle/mcp-dart/
├── .env                              # Optional user-global API key (git-ignored)
├── config.yaml                       # Configuration (auto-created)
└── data/
    ├── corp_list.csv                 # ~114k Korean companies (CSV cache, dart-fss)
    ├── zip/
    │   └── {rcept_no}.zip            # Original DART archive (retained after download)
    ├── xml/
    │   └── {rcept_no}/               # Extracted XML per filing
    │       ├── {rcept_no}.xml        # Main DART XML
    │       └── {rcept_no}_NNNNN.xml  # Optional attachments
    └── json/
        └── {stock_code}_{rcept_no}.json   # Parsed section_tree + pages + coverage

ファイル命名規則: stock_codeが判明している場合は{stock_code}_{rcept_no}.json、ダウンロード時にstock_codeが省略された場合は{rcept_no}.json。find_json_fileは*_{rcept_no}.jsonグロブと従来のraw/ / xml/併置レイアウトにもフォールバックする。

使用例

ツールは**EAFP（Easier to Ask for Forgiveness than Permission）**アプローチに従う。AIアシスタントは直接読み取り/検索を試み、エラーに頼ってダウンロードをトリガーする必要がある。

シナリオA: ファイルが既にローカルに存在する場合（最短パス）

User: "Analyze Samsung's latest financial report."

1. keyword_search(rcept_no="<rcept_no>", keywords=["매출", "매출액", "영업이익"])
   → Returns page snippets matching the keywords immediately.

シナリオB: ファイルが存在しない場合（フォールバックがトリガーされる）

User: "What does LG Energy Solution's latest annual report say about R&D?"

1. keyword_search(rcept_no="<rcept_no>", keywords=["연구개발", "R&D"])
   → Error: Parsed report not found.
2. list_dart_filings(stock_code="373220", report_types=["A001"])
   → Returns the correct rcept_no.
3. download_dart_report(rcept_no="<rcept_no>")
   → Downloads ZIP, extracts XMLs, parses to JSON cache.
4. keyword_search(rcept_no="<rcept_no>", keywords=["연구개발", "R&D"])
   → Now returns hits with section context.

シナリオC: 最新の随時開示（Samsungの業績ガイダンス / 잠정실적）

User: "Analyze Samsung's latest earnings guidance."

1. list_dart_filings(stock_code="005930", report_types=["I002"], limit=1)
   → Returns the latest 공정공시 (e.g. 잠정실적 / provisional earnings).
2. download_dart_report(rcept_no="<rcept_no>", stock_code="005930", report_type="I002")
   → Parses the HTML single-page disclosure.
3. keyword_search(rcept_no="<rcept_no>", keywords=["매출", "영업이익", "실적"])
   → AI summarizes revenue, operating profit, and YoY change.

技術スタック

コンポーネント

採用技術

目的

MCPフレームワーク

mcp (FastMCP)

stdioトランスポートを使用するMCPサーバー

API / ダウンロード

dart-fss (MIT)

DART認証、企業リスト、ZIPダウンロード

XML解析

lxml

コアパーサーエンジン

構造化データ

pandas

corp_list CSVキャッシュ（dart-fssの依存関係）

TOC / フォーマット設定

pyyaml

toc.yaml / types.yaml / formats.yamlのローダー

検索

Python標準

文字数TF + 位置ブースト

ライセンス

MIT

Available Tools

6 tools
download_dart_reportA

Download and parse a single DART filing. Combines the SEC flow's download_sec_report + parse_sec_report into one step.

Args: rcept_no: 14-digit DART receipt number (from list_dart_filings) stock_code: optional 6-digit stock code for the JSON filename ({stock_code}_{rcept_no}.json). When omitted, resolves from an existing cache or uses {rcept_no}.json. rcept_dt: optional receipt date YYYYMMDD (informational) report_type: DART detail type code, default "A001". Any valid type from types.yaml is accepted; the parser auto-detects the document format. force_parse: re-parse even if a cached JSON exists

ParametersJSON Schema
NameRequiredDescriptionDefault
rcept_dtNo
rcept_noYes
stock_codeNo
force_parseNo
report_typeNoA001

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.7/5.0
Behavior4/5

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

With no annotations, the description fully carries the transparency burden. It discloses caching behavior, auto-detection of document format, and parsing routes for different report types. It lacks explicit mention of side effects like network usage, but covers core behavioral traits.

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 longer but well-structured with strategy and critical rules in XML tags. Every sentence adds value, and the purpose is front-loaded. Minor room for cutting verbosity 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?

Given the tool's complexity (5 parameters, multiple report types, caching), the description covers workflow, error handling, auto-detection, parameter usage, and sibling relationships. The presence of an output schema complements the description.

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 coverage is 0%, but the description provides rich parameter details: rcept_no's format and source, stock_code's role in file naming, rcept_dt's informational nature, report_type's default and flexibility, and force_parse's meaning. This adds significant value over the bare schema.

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 ('Download and parse a single DART filing') and distinguishes it from siblings by noting it combines two SEC flow steps. This provides specificity and uniqueness.

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?

The description includes an explicit strategy that tells the agent when to invoke this tool (only on 'file not found' errors from other tools) and critical rules that prevent misuse (never assume download before search). This provides thorough usage guidance.

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

get_report_pagesA

Retrieve page content from a parsed DART report.

Two modes:

  • By global page range: pass start_page + (page_count OR end_page). If both are given, end_page wins (inclusive). Per plan §Verification step 4: get_report_pages(rcept_no, start_page=12, end_page=14).

  • By section_code: pass section_code (e.g., "020100"); returns all pages in that section (overrides start_page/page_count/end_page).

Args: rcept_no: 14-digit DART receipt number start_page: Starting page number (1-based); ignored if section_code is set page_count: Consecutive pages to return (default 3, max 10). Ignored when end_page is positive. end_page: Inclusive end page (1-based). Use for start_page=12, end_page=14 style ranges (plan §Verification). 0 = interpret as not-set. section_code: Optional DART section code (e.g., "020100"); overrides start_page/page_count/end_page and returns all of that section stock_code: optional 6-digit stock code for cache hit rate

ParametersJSON Schema
NameRequiredDescriptionDefault
end_pageNo
rcept_noYes
page_countNo
start_pageNo
stock_codeNo
section_codeNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.9/5.0
Behavior5/5

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

With no annotations, the description clearly explains parameter interactions (end_page wins over page_count, section_code overrides others), default values, and cache hint via stock_code. No contradictions.

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 well-structured with sections and bullet points, but slightly verbose with some repeated explanations (e.g., end_page winning). Still, each sentence adds value, so it remains efficient.

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?

Despite no annotations, the description covers all aspects: modes, parameter usage, strategy, rules, and acknowledges the output schema (not shown). It is complete for an agent to use the tool correctly.

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 coverage is 0%, but the description provides detailed parameter meanings, default values, interactions, and examples (e.g., stock_code for cache hit rate), going far beyond the bare schema.

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 retrieves page content from a parsed DART report, specifies two modes (page range vs section_code), and distinguishes from sibling tools like keyword_search and get_report_toc.

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?

The description includes a <strategy> block advising to use this tool for reading large continuous blocks and to prefer keyword_search for targeted fact-finding. <critical_rules> advise keeping page_count reasonable and using get_report_toc for section_code.

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

get_report_tocA

Retrieve the complete DART section_tree (Table of Contents) for a parsed report. Each entry includes start_page, end_page, local_pages, and children.

Args: rcept_no: 14-digit DART receipt number (from list_dart_filings) stock_code: optional 6-digit stock code (improves cache hit rate when JSON file naming uses standard prefix)

ParametersJSON Schema
NameRequiredDescriptionDefault
rcept_noYes
stock_codeNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.6/5.0
Behavior4/5

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

With no annotations, the description carries the full burden. It discloses that the tool does NOT use heuristic page-scan; section_tree is built directly from toc.yaml and parsed XML, making page ranges authoritative. It also notes that an optional stock_code improves cache hit rate, adding behavioral insight.

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 well-structured with sections (main description, <strategy>, <critical_rules>, args). It is front-loaded with the key purpose. Every sentence adds value with no redundancy.

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?

Given the presence of an output schema (not shown but indicated), the description need not explain return values. It adequately covers purpose, usage guidelines, behavioral transparency, and parameter semantics for a simple tool with 2 parameters (1 required) and a well-defined output.

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 coverage is 0%, so the description compensates fully. It explains that rcept_no is a 14-digit DART receipt number from list_dart_filings, and stock_code is an optional 6-digit code that improves cache hit rate. This adds valuable context beyond the schema's title and default.

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 retrieves the complete DART section_tree (Table of Contents) for a parsed report, specifying entry fields (start_page, end_page, local_pages, children). This distinguishes it from siblings like get_report_pages (which reads sections) and list_dart_filings (which lists filings).

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?

The <strategy> block explicitly says 'Directly invoke this tool to understand the structural layout of the report' and explains that returned section_code values can be passed to get_report_pages. This provides clear guidance on when to use and how it integrates with sibling tools, though it does not explicitly state when not to use it.

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

list_dart_filingsA

List DART filings for a Korean listed company by stock code.

Args: stock_code: 6-digit Korean stock code, e.g. "005930" (Samsung Electronics) bgn_de: Start date YYYYMMDD, e.g. "20230101" (optional) end_de: End date YYYYMMDD, e.g. "20241231" (optional) report_types: DART report detail types to filter (default: ["A001","A002","A003"]) limit: Maximum number of filings to return (default 20, max 100)

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNo
bgn_deNo
end_deNo
stock_codeYes
report_typesNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.5/5.0
Behavior4/5

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

With no annotations, the description carries full burden. It discloses that the parser auto-detects format, that non-parseable types are flagged, and that omitting dates returns most recent filings. This provides useful behavioral context beyond parameter syntax.

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?

Description is well-structured with separate strategy and critical rules sections, concise sentences, and no redundant information. Every sentence adds distinct 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?

Despite having an output schema (not shown), the description mentions that it returns rcept_no and flags non-parseable types. For a 5-parameter tool, this is sufficient to understand the tool's role and output, though additional return value details could be included.

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 description compensates fully. It provides concrete examples for stock_code ('005930'), format for dates (YYYYMMDD), default values for report_types and limit, and max value for limit. All five parameters are clearly explained.

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 uses specific verb 'List' and explicitly states resource 'DART filings for a Korean listed company by stock code'. It clearly distinguishes from sibling tool 'download_dart_report' by mentioning it returns 'rcept_no' needed for download.

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?

The strategy section instructs to invoke this tool before downloading, and the critical rules provide concrete guidance on using return value for download_dart_report and handling date parameters. However, it does not explicitly contrast with other siblings like get_report_pages.

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

search_dart_companyA

Search Korean listed companies by name (Korean or English) and return their stock_code / corp_code. Use this when the user references a company by name without providing a 6-digit stock_code.

Args: query: Company name (Korean or English), e.g. "삼성전자" or "Samsung" exact: If True, match the name exactly; if False (default), substring contains. limit: Max number of matches to return (default 20, max 50). include_delisting: If True, also return delisted / non-listed companies (those without a 6-digit stock_code). Defaults to False.

ParametersJSON Schema
NameRequiredDescriptionDefault
exactNo
limitNo
queryYes
include_delistingNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.9/5.0
Behavior5/5

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

With no annotations provided, the description fully discloses behavior: case-insensitive matching, exact vs. substring modes, returning all candidates on multiple matches (not guessing), and the include_delisting option. No contradictions.

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 well-structured with sections for strategy, critical rules, and examples. It is comprehensive but slightly lengthy; however, every sentence adds value. Front-loading the core purpose helps efficient reading.

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?

Given the tool's complexity (4 parameters, ambiguity resolution, sibling coordination) and presence of an output schema, the description is complete: it explains purpose, usage, parameter details, return behavior, and provides examples. No gaps remain.

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?

The description details all 4 parameters beyond the schema: query (Korean/English name), exact (exact match vs substring), limit (default 20, max 50), include_delisting (returns delisted companies). Schema coverage is 0%, so the description fully compensates.

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 searches Korean listed companies by name (Korean or English) and returns stock_code/corp_code. It distinguishes from sibling tools like list_dart_filings by explicitly stating to resolve stock_code first. Examples solidify the purpose.

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?

The <strategy> section explicitly says to invoke this tool FIRST when a company name is given without a stock_code. The <critical_rules> specify to SKIP if a stock_code is already provided and call list_dart_filings directly. This provides clear when-to-use and when-not-to-use guidance with alternatives.

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. Dates show when Glama detected each change.

  1. 6 tool updatesv0.1.0
    • First observeddownload_dart_report
    • First observedget_report_pages
    • First observedget_report_toc
    • First observedkeyword_search
    • First observedlist_dart_filings
    • First observedsearch_dart_company
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.7/5.0

Scored across 6 tools

Disambiguation5/5

Each tool targets a distinct task: company lookup, filing listing, downloading/parsing, table of contents retrieval, page reading, and keyword search. There is no overlap in functionality.

Naming Consistency4/5

Most tools follow a verb_noun pattern (search_dart_company, list_dart_filings, download_dart_report, get_report_toc, get_report_pages). One tool (keyword_search) uses a noun_verb structure, which is a minor deviation but still understandable.

Tool Count5/5

Six tools cover the core workflow for DART financial filings: search company, list filings, download, get structure, read pages, and search within. The count is well-scoped for the domain.

Completeness5/5

The tool set provides comprehensive coverage for a read-only financial filings system: find company, list filings, download/parse, navigate structure, read content, and search. No obvious gaps for the intended purpose.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

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
    -

  • MCP OpenDART

    ChangooLee
    F
    license
    C
    quality
    Not graded
    maintenance
    Enables AI assistants to access South Korea's financial disclosure system (OpenDART), allowing users to retrieve corporate financial reports, disclosure documents, shareholder information, and automatically extract and search financial statement notes through natural language queries.
    85
    -

  • 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.
    27
    2
    MIT