Skip to main content
Glama

Dart Kr

by io.github.pipeworx-io
OverviewDiscussionsAdmin

Dart Search Filings

dart_search_filings
Read-onlyIdempotent

AUTHORITATIVE list of recent Korean corporate disclosures filed to DART (Korea's SEC equivalent). Returns rcept_no (receipt ID), rcept_dt (filing date), corp_name, report_nm (disclosure title), corp_code. Filter by company via corp_code (e.g., "00126380" Samsung Electronics; see pack docstring for major chaebol codes), filing date range, or filing type. Use for "what did Samsung file last week", "recent KOSPI material events", "this quarter's ownership changes".

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
bgn_deNoFiling date start (YYYYMMDD). Defaults to 30 days ago when omitted.
end_deNoFiling date end (YYYYMMDD). Defaults to today when omitted.
page_noNoPage number (1-based, default 1).
corp_codeNo8-digit DART corp identifier (Samsung 00126380, SK Hynix 00164779, etc.). Omit to list filings across ALL companies in the date range.
pblntf_tyNoDisclosure category: A (periodic report), B (major events), C (issuance), D (ownership change), E (audit), F (fund), G (asset-backed securities), H (foreign), I (subscriber). Omit for all.
page_countNoResults per page (1-100, default 10).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / examples
      Added value: +[
+  {
+    "bgn_de": "20240101",
+    "corp_code": "00126380",
+    "end_de": "20240131",
+    "pblntf_ty": "B"
+  },
+  {
+    "bgn_de": "20240115",
+    "end_de": "20240131",
+    "page_count": 20
+  }
+]
  2. First observed

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint and idempotentHint, so the description doesn't need to restate safety. It adds useful behavioral details like default date ranges (30 days ago to today) and that omitting corp_code searches all companies, providing transparency beyond annotations.

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

Conciseness5/5

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

The description is a single, focused paragraph that front-loads the purpose and immediately lists key return fields. It uses no filler sentences and has a natural flow from purpose to filters to examples.

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?

The description covers the tool's core functionality, return fields, and filtering options. Although there is no output schema, the description mentions the key return fields (rcept_no, rcept_dt, etc.). It misses some nuances like pagination but is complete for most use cases.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 100% schema description coverage, the description adds value by giving concrete examples for corp_code (e.g., '00126380' for Samsung) and expanding on pblntf_ty categories (e.g., 'B (major events)'). This enriches parameter understanding 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 provides an 'AUTHORITATIVE list of recent Korean corporate disclosures' from DART, with specific fields returned. It includes concrete use cases like 'what did Samsung file last week', distinguishing its purpose effectively.

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 description gives explicit usage examples (e.g., filtering by company, date range, filing type) and specifies the tool is for recent filings. It doesn't explicitly mention when not to use or alternatives, but the context is clear enough for an AI agent.

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

All Dart Kr toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources