de en es ja ko ru zh

mcp-dart

Name: mcp-dart
Author: agentladle

by agentladle

Overview Schema Source Related Servers Score Discussions Admin

Python

Remote

AgentLadle MCP DART

Английский | 中文

🇨🇳/🇭🇰 Облачный MCP для компаний, котирующихся на A-share и в Гонконге (годовые отчёты за последние 3 года и последние промежуточные отчёты). Подробнее | Получить API-ключ

Сервер MCP (Model Context Protocol), предоставляющий инструменты для обнаружения, загрузки, разбора и поиска корейских финансовых отчётов DART (금융감독원 전자공시시스템).

Он позволяет ИИ-ассистентам (Claude, Cursor и т.д.) получать доступ к данным Open DART Кореи через 6 структурированных инструментов — от определения названия компании до поиска по ключевым словам на страницах отчётов.

Возможности

6 инструментов MCP для данных DART: определение названия компании, список отчётов, загрузка+разбор, получение TOC, чтение страниц, поиск по ключевым словам
Полная поддержка финансовых отчётов 정기공시 — A001 사업보고서 (годовой), A002 반기보고서 (полугодовой), A003 분기보고서 (квартальный), каждый со специальным разделом toc.yaml, полученным из реальных XML-данных DART
Многоформатный парсер с автоматическим определением — структурированный XML SECTION-N (типы A/B/D/E) направляется в парсер дерева разделов (toc.yaml, если доступен, иначе общее извлечение дерева); одностраничные HTML-раскрытия (I001 수시공시, I002 공정공시/잠정실적) направляются в парсер извлечения HTML. Формат определяется по содержимому файла, а не задаётся жёстко по типу.
Профессиональный разбор документов DART — прямое извлечение по XML-путям (./P, ./TABLE) и стандартное выравнивание TOC (A001: 123 кода / 110 листьев; A002: 53 кода / 43 листа; A003: 59 кодов / 48 листьев)
章节树 + 节内限页 модель пагинации — страницы соответствуют стандартному дереву разделов DART (точность вместо фиксированного разбиения по 4000 символов)
Поиск с учётом корейского языка — поиск по подстроке (без границ слов \b), нормализация TF по количеству символов, подсказки по морфологическим вариантам
Трёхуровневый локальный кэш — ZIP-архивы, извлечённые XML и разобранные JSON хранятся отдельно в ~/.agentladle/mcp-dart/data/{zip,xml,json}/
Идемпотентность — уже загруженные/разобранные отчёты автоматически пропускаются
Чистый Python, кроссплатформенный (Windows / macOS / Linux)

Related MCP server: MCP OpenDART

Предварительные требования

Python 3.10+ — Скачать Python
uv — Установить uv
API-ключ DART (бесплатный) — зарегистрируйтесь на https://opendart.fss.or.kr/

Примечание: После установки 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`

Если вы не хотите передавать ключ через блок env MCP-клиента, скопируйте .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)

Инструменты

#	Tool	Description
1	`list_dart_filings`	Список отчётов DART для корейской компании по коду акции (возвращает `rcept_no`)
2	`download_dart_report`	Скачивает ZIP-архив отчёта DART и разбирает его в JSON-кэш дерева разделов
3	`get_report_toc`	Получить section_tree (TOC) с диапазонами страниц — на основе `toc.yaml`, без эвристики
4	`get_report_pages`	Читает страницы по глобальному номеру страницы или по `section_code`
5	`keyword_search`	Полнотекстовый поиск по подстроке для корейского языка с TF по количеству символов и повышением за позицию
6	`search_dart_company`	Определяет название компании (корейское/английское) в `stock_code` / `corp_code` через локальный кэш `corp_list.csv`

Инструмент 1: `list_dart_filings`

Выводит список доступных отчётов DART для корейской публичной компании.

Parameter	Type	Required	Description
`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 (true для любого допустимого типа DART — парсер автоматически определяет формат документа при разборе).

Инструмент 2: `download_dart_report`

Скачивает и разбирает один отчёт DART. Объединяет download + parse из SEC-потока в один шаг. Идемпотентен (пропускает, если кэш существует и действителен).

Parameter	Type	Required	Description
`rcept_no`	string	✅	14-значный регистрационный номер DART (из `list_dart_filings`)
`stock_code`	string	❌	6-значный код акции для имени JSON-файла (`{stock_code}_{rcept_no}.json`); если не указан, кэшируется как `{rcept_no}.json` — поиск по `rcept_no` по-прежнему работает
`rcept_dt`	string	❌	Дата регистрации `YYYYMMDD` (информационно)
`report_type`	string	❌	Тип детализации DART, по умолчанию `"A001"`. Принимается любой допустимый тип из `types.yaml`; парсер автоматически определяет формат документа (section-tree XML для A/B/D/E, HTML для I001/I002).
`force_parse`	bool	❌	Повторный разбор, даже если кэшированный JSON существует

Инструмент 3: `get_report_toc`

Возвращает полное section_tree (оглавление) DART для разобранного отчёта. Построено непосредственно на основе toc.yaml, согласованного с разобранным XML, — диапазоны страниц являются точными, а не эвристическими.

Parameter	Type	Required	Description
`rcept_no`	string	✅	14-значный регистрационный номер DART
`stock_code`	string	❌	Код акции (улучшает поиск в кэше)

Каждый узел имеет section_code, title, start_page, end_page, local_pages, matched (bool — совпал ли XML с этой записью toc) и children. Передайте любой section_code в параметр section_code инструмента 4, чтобы прочитать всё поддерево.

Инструмент 4: `get_report_pages`

Читает полное содержимое страниц по глобальному диапазону страниц или по section_code.

Parameter	Type	Required	Description
`rcept_no`	string	✅	14-значный регистрационный номер DART
`start_page`	int	❌	Начальная страница (с 1); по умолчанию 1; игнорируется, если задан `section_code`
`page_count`	int	❌	Количество страниц (по умолчанию 3, максимум 10). Игнорируется, если `end_page` > 0.
`end_page`	int	❌	Конечная страница включительно (например, `start_page=12, end_page=14`). 0 = не задано.
`section_code`	string	❌	Код раздела DART (например, `"020100"`); переопределяет аргументы диапазона страниц, возвращает всё поддерево
`stock_code`	string	❌	Код акции (помощь в поиске по кэшу)

Инструмент 5: `keyword_search`

Полнотекстовый поиск с учётом корейского языка. Оценка:

TF = количество вхождений подстроки / количество символов без пробелов (в корейском языке слова не разделяются пробелами)
Повышение за позицию ×1.2, если первое совпадение находится в верхних 20% страницы
Режим ALL даёт бонус ×2.0, если встречается каждое ключевое слово

Parameter	Type	Required	Description
`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 (без сетевых вызовов после первого прогрева). Используйте этот инструмент перед list_dart_filings / download_dart_report, когда пользователь называет компанию по имени, но не указывает 6-значный stock_code.

Параметр	Тип	Обязательный	Описание
`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 (от высшего к низшему):

Настоящая переменная окружения ОС (DART_API_KEY=xxx uvx agentladle-mcp-dart)
Файл .env — сначала ./.env, затем ~/.agentladle/mcp-dart/.env
dart.api_key в ~/.agentladle/mcp-dart/config.yaml

Структура каталога данных

~/.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}_{rcept_no}.json, если stock_code известен; {rcept_no}.json, если stock_code не был указан при скачивании. find_json_file также в качестве запасного варианта использует glob-шаблон *_{rcept_no}.json и устаревшие структуры raw/ / xml/, расположенные в том же каталоге.

Примеры использования

Инструменты следуют подходу EAFP (Easier to Ask for Forgiveness than Permission — «проще попросить прощения, чем разрешения»). ИИ-ассистентам следует пытаться читать или искать напрямую и полагаться на ошибки, которые запускают скачивание.

Сценарий 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)	MCP-сервер со stdio-транспортом
API / скачивание	`dart-fss` (MIT)	Авторизация DART, список корпораций, скачивание ZIP
Разбор XML	`lxml`	Основной движок парсинга
Структурированные данные	`pandas`	CSV-кэш corp_list (зависимость 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

Name	Required	Default
`rcept_dt`	No
`rcept_no`	Yes
`stock_code`	No
`force_parse`	No
`report_type`	No	A001

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

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

Name	Required	Description	Default
`end_page`	No
`rcept_no`	Yes
`page_count`	No
`start_page`	No
`stock_code`	No
`section_code`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

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

Name	Required	Description	Default
`rcept_no`	Yes
`stock_code`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

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.

keyword_searchA

Korean full-text keyword search across a parsed DART report.

Uses substring matching (no \b word boundaries — meaningless for Korean) and character-count TF normalization. Results include section_code / section_title context for each hit.

Args: rcept_no: 14-digit DART receipt number keywords: 1–5 search keywords (Korean or ASCII) match_mode: "ANY" (any match) or "ALL" (all must match), default ANY max_results: Max matching snippets to return (default 5, max 50) stock_code: optional 6-digit stock code for cache hit rate

ParametersJSON Schema

Name	Required	Default
`keywords`	Yes
`rcept_no`	Yes
`match_mode`	No	ANY
`stock_code`	No
`max_results`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A5/5.0

Behavior5/5

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

With no annotations, the description fully discloses behavior: substring matching, character-count TF normalization, no word boundaries, result context, error fallback strategy. No contradictions or gaps.

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?

Well-structured with distinct sections (description, strategy, critical rules, examples, args). Every sentence adds value; no redundancy or verbosity.

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 complexity (5 params, no annotations, but output schema exists), the description is comprehensive. It covers usage, rules, examples, parameter details, and even a fallback strategy, ensuring an AI agent can 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?

Despite 0% schema coverage, the description thoroughly explains each parameter: rcept_no (14-digit), keywords (1-5, include variants, omit particles), match_mode (ANY/ALL), max_results (default 5, max 50), stock_code (optional 6-digit). Adds significant value beyond the 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 performs 'Korean full-text keyword search across a parsed DART report', specifying the action, resource, and scope. It effectively distinguishes from siblings like download_dart_report or get_report_toc, which serve 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 Guidelines5/5

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

The <strategy> section explicitly instructs to use this for targeted fact-finding and provides fallback guidance. <critical_rules> and <examples> offer detailed, actionable usage criteria, including keyword selection and morphological variants.

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

Name	Required	Description	Default
`limit`	No
`bgn_de`	No
`end_de`	No
`stock_code`	Yes
`report_types`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

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

Name	Required	Description	Default
`exact`	No
`limit`	No
`query`	Yes
`include_delisting`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

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.

6 tool updatesv0.1.0Jul 7, 2026
- 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 2026-07-07 17:05 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

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

MyDART A
kr.eocpa
Powerful OpenDART API-based Korean corporate disclosure tools for accounting professionals
Finance Legal & Compliance Open Data
161
jjlabsio-korea-stock-mcpOAuth
ai.smithery
Search company disclosures and financial statements from the Korean market. Retrieve stock profile…
Finance Search Government Data
2175
kr-groundtruth A
io.github.ChloePark85
Korean fact-verification tools for AI agents: business registration, address, DART, apt prices, laws
Government Data Open Data Search
81
EvidInvestOAuth
io.github.EvidInvest
SEC filings and financial data for AI agents: 55 tools for financials, valuation and supply chains.
Finance Open Data Data Platforms
1

Related MCP Servers

Korean Company Information MCP
Finance Search Open Data
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.
Updated 10 months ago (2025-11-20 06:19 UTC)
2
-
MCP OpenDART
Finance Government Data Search
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.
Updated 8 months ago (2026-01-16 05:59 UTC)
85
-
dart-search-mcp
Government Data Finance Open Data
memorise8
F
license
A
quality
B
maintenance
Enables searching corporate disclosures from Korea's DART system, including company info, financial statements, and disclosure search.
Updated 23 days ago (2026-08-18 13:22 UTC)
16
-
opendart-mcp-server
Finance Government Data
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.
Updated 7 months ago (2026-02-14 04:53 UTC)
27
2
MIT

AgentLadle MCP DART

Возможности

Предварительные требования

Быстрый старт

Альтернатива: файл .env

Альтернатива: pip install

Альтернатива: запуск из исходников (локальная разработка)

Поток данных

Инструменты

Инструмент 1: list_dart_filings

Инструмент 2: download_dart_report

Инструмент 3: get_report_toc

Инструмент 4: get_report_pages

Инструмент 5: keyword_search

Инструмент 6: search_dart_company

Конфигурация

Структура каталога данных

Примеры использования

Технологический стек

Лицензия

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Альтернатива: файл `.env`

Инструмент 1: `list_dart_filings`

Инструмент 2: `download_dart_report`

Инструмент 3: `get_report_toc`

Инструмент 4: `get_report_pages`

Инструмент 5: `keyword_search`

Инструмент 6: `search_dart_company`