Skip to main content
Glama

search_disclosures

Read-only

MyDART MCP의 search_disclosures 도구는 DART 공시 목록에서 접수번호(rcept_no)를 찾습니다 — download_document·get_attachments 진입점.

[Purpose]

  • 사업보고서 섹션 데이터는 get_periodic_report, 동명 회사는 find_corp_code 로 corp_code 확정.

[Usage]

  1. "삼성전자 최근 한 달 공시" → corp="삼성전자", days=30

  2. "작년 유상증자 결정 전부" → preset="rights_offering", start="2025-01-01", end="2025-12-31"

[Response]

  • corp_cls: Y=코스피, K=코스닥, N=코넥스, E=기타(비상장).

  • report_nm [기재정정]/[첨부정정]/[첨부추가] prefix = 정정공시.

[Rules]

  • Always pass corp when a company is named — corp-less searches (page mode too) split into 90-day chunks, batch request budget 60; with corp: 1 request.

  • Counters nest: total_available ≥ total_fetched ≥ matched ≥ returned; matched > returned = cut by limit, incomplete=true = partial (see incomplete_note). collected_periods = the only ranges queried; counters scope to them, the rest is unchecked, not zero.

  • early_stopped:true = limit filled, rest unfetched — matched is a lower bound.

  • Preset batch drops 정정공시; page mode·bare all_pages keep them.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
endNoEnd date (defaults to today)
corpNo회사명/종목코드/corp_code. Omit for all companies — but a batch without corp splits the period into 90-day chunks and sweeps every company, spending up to the per-call request budget (default 60, env SEARCH_MAX_REQUESTS) and taking tens of seconds; on reaching it collection is truncated and flagged incomplete=true. With corp the split disappears and the same query finishes in 1 request and a few hundred ms.
daysNoTrailing N days from today instead of start (1~730; out-of-range values are clamped to the bound). When unset, the preset default applies: 사업·감사 460 / 반기 280 / 분기 180 / 수시·일반 90. For windows longer than 730 days use start/end
kindNo공시유형: periodic/major/issuance/holdings/audit/other/fund/abs/exchange/ftc
pageNoPage number (page mode — the default when neither preset nor all_pages is set). Row shape differs by mode: page mode items are raw DART list rows, batch mode items a 7-key projection (rcept_no·rcept_dt·corp_name·corp_code·corp_cls·report_nm·flr_nm), so any field outside those 7 is only in page mode.
sizeNoPage size (page mode)
limitNoCap on rows finally returned in batch mode (preset given or all_pages=true)
startNoStart date YYYY-MM-DD. When omitted, `days` back from today (and when that is unset, the preset default: 사업·감사 460 / 반기 280 / 분기 180 / 수시·일반 90) — set it explicitly for older filings. (The old parameter name begin is still accepted — unified with start/end in get_corporate_event.)
presetNo22 presets: treasury_buy/sell/trust · cb/bw/eb_issue · rights_offering/bonus_issue/capital_reduction · merger/split/stock_exchange · business_transfer/acquisition · large_holding_5pct · annual_report/half_report/quarterly_report · audit_report · correction_all · insolvency · litigation. Setting one applies kind and a keyword filter automatically and collects every page in parallel.
all_pagesNoCollect the whole period in parallel even without a preset (정정공시 included — the same set as page mode). When true, limit applies instead of page/size.
final_onlyNoOne latest version per event — where a 정정 exists the 구본(원본) is dropped and the latest 정정본 is taken (this does NOT exclude 정정공시 themselves). Use when you need one duplicate-free set.
concurrencyNoCollector workers in batch mode (1~10, default 5). **Effective concurrency is set by a server-wide cap, so raising this usually does NOT make it faster** — to cut latency, set corp (which removes the period split, leaving a single request), narrow the period, or lower limit. The response's dart_requests/cached_chunks report how many DART requests this call spent and how many chunks came from cache — read them when it feels slow.
include_correctionsNoWhether to include 정정공시 ([기재정정] etc.) — preset batch mode ONLY (default false, to avoid double-counting 원본+정정 of the same event; correction_all forces true; ignored when final_only=true since that already removes duplicates). Bare all_pages and page mode ALWAYS include them (raw DART) — for latest-only without duplicates use final_only.

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already mark the tool read-only and non-destructive, so the description goes beyond them by disclosing batch behavior, 90-day chunking, the request budget of 60, counter nesting semantics, early_stopped implications, and correction-disclosure handling. This is rich behavioral context that materially affects how an agent interprets results.

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 long but highly structured with Purpose, Usage, Response, and Rules sections, each earning its place. For a tool with 13 optional parameters and subtle batch-mode behaviors, the density is justified and the most critical operational rules are front-loaded.

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?

With no output schema, the description still explains the response codes (corp_cls, report_nm correction prefixes) and the exact meaning of counters like total_available, matched, returned, incomplete, and early_stopped. It covers the non-obvious result-interpretation traps an agent would otherwise miss, making the definition complete for correct invocation and result understanding.

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

Parameters3/5

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

Schema description coverage is 100%, so the baseline is 3; the schema already documents each parameter in detail. The tool description adds usage examples for corp/days/preset/start/end and stresses the corp parameter's performance implications, but it does not substantially define parameters beyond what the schema already provides.

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 states a precise job: find rcept_no in the DART disclosure list and serve as the entry point to download_document/get_attachments. It also distinguishes itself from get_periodic_report and find_corp_code, so an agent can tell it apart from siblings without opening schemas.

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 [Purpose] section explicitly routes business-report section data to get_periodic_report and same-name company resolution to find_corp_code, giving clear when-not-to-use guidance. The [Usage] examples translate natural-language requests into concrete parameter choices, and the [Rules] section adds operational conditions such as always passing corp when a company is named.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.7/5.0
Disambiguation5/5

Every tool targets a distinct aspect of the DART disclosure domain: full text, attachments, financial figures, audit facts, audit narrative, ICFR, going concern, company profile, events, periodic report sections, XBRL, valuation, usage stats, and two search entry points. Overlaps are resolved by explicit cross-references and clear purpose statements (e.g., get_audit_profile vs get_audit_report vs get_internal_control). No ambiguity remains.

Naming Consistency5/5

All 16 tools follow a consistent snake_case verb_noun pattern, with get_ for data retrieval, search_ for list queries, find_ for ID resolution, and download_ for the one document fetch. There is no mixing of camelCase, action words, or stylistic inconsistency. The pattern is immediately predictable.

Tool Count5/5

16 tools is slightly above the typical 3–15 range but fully justified by the breadth of DART (Korea's electronic disclosure system) – covering company lookup, filings, financials, audit reports, internal control, going concern, events, periodic reports, attachments, XBRL, valuation, and usage stats. Each tool address a distinct functional need, and no tool feels redundant or extraneous. The scope is comprehensive yet not bloated.

Completeness5/5

The tool surface covers the full lifecycle of disclosure data access: finding entities (find_corp_code), locating filings (search_disclosures), retrieving financials (get_financials, get_xbrl), reading full text (download_document), fetching attachments (get_attachments), and drilling into audit-related details (get_audit_profile, get_audit_report, get_internal_control, get_going_concern). Periodic report sections (28 types) and corporate events cover governance and capital changes. No obvious dead ends or missing critical operations for a read-only disclosure access server.

Resources