Skip to main content
Glama
deenesjakoruzh
agentladle

mcp-dart

by agentladle
OverviewSchemaSourceRelated ServersScoreDiscussionsAdmin
Python
Remote

AgentLadle MCP DART

English | 中文

🇨🇳/🇭🇰 面向A股及港股上市公司的云托管MCP（过去3年年报及最新中期报告）。了解更多 | 获取API密钥

一个 MCP（模型上下文协议） 服务器，提供用于发现、下载、解析和搜索韩国DART财务报告（금융감독원 전자공시시스템）的工具。

它使AI助手（Claude、Cursor等）能够通过6个结构化工具访问韩国的Open DART数据——从解析公司名称到在报告页面内进行关键词搜索。

功能特性

  • 6个MCP工具用于DART数据：解析公司名称、列出申报文件、下载+解析、获取目录、读取页面、关键词搜索

  • 完整的정기공시财务报告支持 — 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归一化、形态变体提示

  • 三层本地缓存 — ZIP归档、提取的XML和解析后的JSON分别存储在~/.agentladle/mcp-dart/data/{zip,xml,json}/下

  • 幂等 — 已下载/已解析的申报文件自动跳过

  • 纯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安装替代方案。

替代方案：.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安装

如果您更倾向于自行管理环境：

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"（三星电子）

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合并为一步。幂等（如果已缓存且有效则跳过）。

参数

类型

必填

描述

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（布尔值——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. 真实操作系统环境变量（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：最新临时公告（三星业绩指引 / 잠정실적）

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 依赖）

目录/格式配置

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