What can you do with this server?

This server provides 6 MCP tools for discovering, downloading, parsing, and searching Korean DART financial reports. * List DART filings by stock code, with filters for date range, report types, and limit. * Download and parse a specific filing (via rcept_no) into a section-tree JSON cache. * Get a table of contents (TOC) of a parsed report, including section codes and page ranges. * Read report pages by global page range or by section code. * Keyword search across a parsed report (Korean-aware substring matching, TF + position scoring). * Resolve company names (Korean or English) to stock/corp codes via a local CSV cache.

How do I use mcp-dart?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-dart find recent filings for Samsung Electronics" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

de en es ja ko ru zh

mcp-dart

by agentladle

Overview Schema Source Related Servers Score Discussions Admin

Python

Remote

AgentLadle MCP DART

English | 中文

🇨🇳/🇭🇰 Cloud-hosted MCP for A-share & HK listed companies (Past 3 years annual & latest interim reports). Read more | Get API Key

A MCP (Model Context Protocol) server that provides tools for discovering, downloading, parsing, and searching Korean DART financial reports (금융감독원 전자공시시스템).

It enables AI assistants (Claude, Cursor, etc.) to access Korea's Open DART data through 6 structured tools — from resolving a company name to keyword-searching within report pages.

Features

6 MCP tools for DART data: resolve company name, list filings, download+parse, get TOC, read pages, keyword search
Full 정기공시 financial report support — A001 사업보고서 (annual), A002 반기보고서 (semi-annual), A003 분기보고서 (quarterly), each with a dedicated toc.yaml section mapping derived from real DART XML
Auto-detecting multi-format parser — structured SECTION-N XML (A/B/D/E types) routes to the section-tree parser (toc.yaml when available, generic tree extraction otherwise); HTML single-page disclosures (I001 수시공시, I002 공정공시/잠정실적) route to the HTML extraction parser. Format is detected by file content, not hardcoded by type.
Professional DART document parsing — direct XML path extraction (./P, ./TABLE) and standard TOC alignment (A001: 123 codes / 110 leaves; A002: 53 codes / 43 leaves; A003: 59 codes / 48 leaves)
章节树 + 节内限页 pagination model — pages respect DART's standard section tree (precision over fixed 4000-char chunking)
Korean-aware search — substring matching (no \b word boundaries), character-count TF normalization, morphological-variant hints
Three-tier local cache — ZIP archives, extracted XML, and parsed JSON stored separately under ~/.agentladle/mcp-dart/data/{zip,xml,json}/
Idempotent — already-downloaded/parsed filings are automatically skipped
Pure Python, cross-platform (Windows / macOS / Linux)

Related MCP server: MCP OpenDART

Prerequisites

Python 3.10+ — Download Python
uv — Install uv
DART API key (free) — register at https://opendart.fss.or.kr/

Note: After installing uv, restart your terminal and MCP client (e.g. Cherry Studio) to ensure the uv command is recognized.

Quick Start

Add to your MCP client configuration (Claude Desktop, Cursor, etc.):

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

That's it. uvx will automatically download the package and its dependencies from PyPI — no clone, no manual install, no path configuration.

Slow network? The first uvx run downloads many dependencies (including dart-fss, pandas, etc.). The default 30s timeout may be too short and cause MCP Connection closed. Set UV_HTTP_TIMEOUT to "300" to avoid download timeouts. If it still fails, use the pip install alternative below.

Alternative: `.env` file

If you prefer not to inject the key via the MCP client env block, copy .env.example to one of:

./.env (per-project override; git-ignored — never commit a real key)
~/.agentladle/mcp-dart/.env (user-global default)

and set:

DART_API_KEY=your_dart_api_key_here

The first existing .env wins; explicit env vars set in the MCP client always override .env. See .env.example for details.

Alternative: pip install

If you prefer managing the environment yourself:

pip install agentladle-mcp-dart

Then configure (no need for uvx):

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

Alternative: Run from source (local development)

Clone the repository and run directly:

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

Then configure your MCP client:

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

Replace /path/to/mcp-dart with the actual path to the cloned repository.

Data Flow

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)

Tools

#	Tool	Description
1	`list_dart_filings`	List DART filings for a Korean company by stock code (returns `rcept_no`)
2	`download_dart_report`	Download a DART filing ZIP and parse it into a section-tree JSON cache
3	`get_report_toc`	Get the section_tree (TOC) with page ranges — derived from `toc.yaml`, not heuristic
4	`get_report_pages`	Read pages by global page number or by `section_code`
5	`keyword_search`	Korean substring full-text search with character-count TF + position boost
6	`search_dart_company`	Resolve a company name (Korean/English) to `stock_code` / `corp_code` via the local `corp_list.csv` cache

Tool 1: `list_dart_filings`

List available DART filings for a Korean listed company.

Parameter	Type	Required	Description
`stock_code`	string	✅	6-digit Korean stock code, e.g. `"005930"` (Samsung Electronics)
`bgn_de`	string	❌	Start date `YYYYMMDD` (default: 20150101)
`end_de`	string	❌	End date `YYYYMMDD` (default: today)
`report_types`	string[]	❌	DART detail types to filter (default: `["A001","A002","A003"]` — 사업/반기/분기보고서)
`limit`	int	❌	Max filings to return (default 20, max 100)

Returns each filing's rcept_no, rcept_dt, report_nm, corp_code, report_type, and a parseable flag (true for any valid DART type — the parser auto-detects document format at parse time).

Tool 2: `download_dart_report`

Download and parse a single DART filing. Fuses the SEC flow's download + parse into one step. Idempotent (skips if cached and valid).

Parameter	Type	Required	Description
`rcept_no`	string	✅	14-digit DART receipt number (from `list_dart_filings`)
`stock_code`	string	❌	6-digit stock code for the JSON filename (`{stock_code}_{rcept_no}.json`); when omitted, caches as `{rcept_no}.json` — lookup still works via `rcept_no`
`rcept_dt`	string	❌	Receipt date `YYYYMMDD` (informational)
`report_type`	string	❌	DART detail type, default `"A001"`. Any valid type from `types.yaml` accepted; parser auto-detects document format (section-tree XML for A/B/D/E, HTML for I001/I002).
`force_parse`	bool	❌	Re-parse even if cached JSON exists

Tool 3: `get_report_toc`

Retrieve the complete DART section_tree (Table of Contents) for a parsed report. Built directly from toc.yaml aligned with the parsed XML — page ranges are authoritative, not heuristic.

Parameter	Type	Required	Description
`rcept_no`	string	✅	14-digit DART receipt number
`stock_code`	string	❌	Stock code (improves cache lookup)

Each node has section_code, title, start_page, end_page, local_pages, matched (bool — whether XML matched this toc entry), and children. Pass any section_code to Tool 4's section_code parameter to read that whole subtree.

Tool 4: `get_report_pages`

Read full page content by global page range or by section_code.

Parameter	Type	Required	Description
`rcept_no`	string	✅	14-digit DART receipt number
`start_page`	int	❌	Start page (1-based); default 1; ignored if `section_code` set
`page_count`	int	❌	Pages to return (default 3, max 10). Ignored when `end_page` is positive.
`end_page`	int	❌	Inclusive end page (e.g. `start_page=12, end_page=14`). 0 = unset.
`section_code`	string	❌	DART section code (e.g. `"020100"`); overrides page-range args, returns whole subtree
`stock_code`	string	❌	Stock code (cache lookup aid)

Tool 5: `keyword_search`

Korean-friendly full-text search. Scoring:

TF = substring count / non-whitespace character count (Korean has no whitespace-delimited words)
Position boost ×1.2 if first hit is in the top 20% of the page
ALL match mode applies ×2.0 bonus when every keyword hits

Parameter	Type	Required	Description
`rcept_no`	string	✅	14-digit DART receipt number
`keywords`	string[]	✅	1–5 Korean (or ASCII) keywords; pass morphological variants like `["매출", "매출액"]`
`match_mode`	string	❌	`"ANY"` (default) or `"ALL"`
`max_results`	int	❌	Max matches (default 5, max 50)
`stock_code`	string	❌	Stock code (cache lookup aid)

Each match returns page_number, score, keyword_hits, snippet (highlighted with **...**), and the section context (section_code/section_title).

Tool 6: `search_dart_company`

Resolve a company name (Korean or English) to a stock_code / corp_code. Queries the locally cached corp_list.csv (no network call after first preheat). Use this before list_dart_filings / download_dart_report whenever the user mentions a company by name but does not provide a 6-digit stock_code.

Parameter	Type	Required	Description
`query`	string	✅	Company name (Korean `corp_name` or English `corp_eng_name`), e.g. `"삼성전자"` or `"Samsung"`
`exact`	bool	❌	`true` = exact name match; `false` (default) = case-insensitive substring contains
`limit`	int	❌	Max matches (default 20, max 50)
`include_delisting`	bool	❌	`true` = also return delisted / non-listed companies; `false` (default) = only listed companies with a 6-digit `stock_code`

Each match contains corp_name, corp_eng_name, stock_code, corp_code, modify_date. When multiple matches are returned, pick the correct stock_code and pass it to list_dart_filings.

Configuration

After first run, a default config file is created at ~/.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 resolution priority (highest to lowest):

Real OS environment variable (DART_API_KEY=xxx uvx agentladle-mcp-dart)
.env file — ./.env first, then ~/.agentladle/mcp-dart/.env
dart.api_key in ~/.agentladle/mcp-dart/config.yaml

Data Directory Structure

~/.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

File naming convention: {stock_code}_{rcept_no}.json when stock_code is known; {rcept_no}.json when stock_code was omitted at download time. find_json_file also falls back to *_{rcept_no}.json glob and legacy raw/ / xml/ co-located layouts.

Example Usage

The tools follow an EAFP (Easier to Ask for Forgiveness than Permission) approach. AI assistants should attempt to read/search directly and rely on errors to trigger downloads.

Scenario A: File already exists locally (Shortest Path)

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

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

Scenario B: File missing (Fallback triggered)

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.

Scenario C: Latest ad-hoc disclosure (Samsung earnings guidance / 잠정실적)

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.

Tech Stack

Component	Choice	Purpose
MCP Framework	`mcp` (FastMCP)	MCP server with stdio transport
API / Download	`dart-fss` (MIT)	DART auth, corp list, ZIP download
XML Parsing	`lxml`	Core parser engine
Structured Data	`pandas`	corp_list CSV cache (dart-fss dependency)
TOC / Format Config	`pyyaml`	`toc.yaml` / `types.yaml` / `formats.yaml` loaders
Search	Python built-in	Character-count TF + position boost

License

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

Features

Prerequisites

Quick Start

Alternative: .env file

Alternative: pip install

Alternative: Run from source (local development)

Data Flow

Tools

Tool 1: list_dart_filings

Tool 2: download_dart_report

Tool 3: get_report_toc

Tool 4: get_report_pages

Tool 5: keyword_search

Tool 6: search_dart_company

Configuration

Data Directory Structure

Example Usage

Tech Stack

License

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

Alternative: `.env` file

Tool 1: `list_dart_filings`

Tool 2: `download_dart_report`

Tool 3: `get_report_toc`

Tool 4: `get_report_pages`

Tool 5: `keyword_search`

Tool 6: `search_dart_company`