dart-risk-mcp

list_disclosures_by_stock

Retrieve recent DART disclosure receipt numbers by stock code, company name, or DART company code to locate filings for document review and risk checks, including unlisted companies.

Instructions

종목코드·기업명·기업코드로 최근 공시의 접수번호(rcept_no) 목록을 조회한다.

반환된 접수번호는 get_disclosure_document, view_disclosure, check_disclosure_risk 등에 바로 사용할 수 있다. 종목코드가 없는 회사 (상장을 준비하는 비상장사 등)도 기업명이나 기업코드로 조회된다 — 증권신고서·투자설명서의 접수번호를 여기서 찾는다.

Args: stock_code: 종목코드 6자리(예: "086520"), 기업명(예: "데스틴파워"), 또는 DART 기업코드 8자리(예: "01135039"). 같은 이름의 법인이 여럿이면 조회하지 않고 기업코드 목록을 보여 준다. lookback_years: 조회 기간(년). 기본 1년, 1~5년 범위.

Input Schema

Name	Required	Description	Default
`to_date`	No
`from_date`	No
`stock_code`	Yes
`lookback_days`	No
`lookback_years`	No

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv1.21.25Sep 1, 2026

addedInput schema / properties / from_date

Added value: +{
+  "default": "",
+  "title": "From Date",
+  "type": "string"
+}

addedInput schema / properties / to_date

Added value: +{
+  "default": "",
+  "title": "To Date",
+  "type": "string"
+}

Changed4 schema fields changedv1.4.0Jun 21, 2026
- addedInput schema / properties / lookback_days / anyOf
```
Added value: +[
+  {
+    "type": "integer"
+  },
+  {
+    "type": "null"
+  }
+]
```
- changedInput schema / properties / lookback_days / default
```
Previous value: -90New value: +null
```
- removedInput schema / properties / lookback_days / type
```
Removed value: -"integer"
```
- addedInput schema / properties / lookback_years
```
Added value: +{
+  "default": 1,
+  "title": "Lookback Years",
+  "type": "integer"
+}
```
First observedv1.0.3May 31, 2026

TDQS

A3.9/5.0

Behavior4/5

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

No annotations are supplied, so the description carries the full disclosure burden, and it does disclose two non-obvious behaviors: it returns only receipt numbers rather than full documents, and if multiple legal entities share the same name it refuses to query and instead returns a list of company codes. It also states the lookback default and range. Gaps remain: result limits, ordering (newest first?), and pagination are unstated, and read-only status is only implied by '조회한다'.

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?

Structure is sound: a front-loaded purpose sentence, then a short context paragraph about downstream use and unlisted companies, then an Args block. Every sentence carries information and none is filler. The only inefficiency is that some parameter detail lives in prose that the schema could have held, and the stock_code entry is verbose relative to the two-paragraph preamble.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need no explanation, and the description covers the tool's main non-obvious behavior (name ambiguity handling, unlisted company support, lookback default). For a five-parameter tool with zero annotation coverage, however, three undocumented filter parameters and the unresolved precedence between the three different time-window mechanisms leave real ambiguity that an agent could stumble on when calling it with a date range.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must document all five parameters, but it covers only two: stock_code (all three accepted formats with concrete examples like '086520' and '01135039') and lookback_years (default 1, range 1–5). The from_date, to_date, and lookback_days parameters get no explanation at all, and the description never resolves how lookback_years, lookback_days, and the explicit date range interact or which takes precedence when supplied together.

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 opening sentence names a specific verb and resource: list recent disclosure receipt numbers (rcept_no) by stock code, company name, or DART company code. The second paragraph sharpens the distinction further by naming the downstream tools (get_disclosure_document, view_disclosure, check_disclosure_risk) that consume the output, and by noting that unlisted/pre-IPO companies are covered here via name or company code — a scoping statement no sibling tool makes.

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?

It states the usage context clearly: the returned receipt numbers feed directly into document-retrieval and risk-check tools, and unlisted companies (e.g. those filing securities registration statements) should be looked up by name or company code rather than ticker. It does not, however, say when to prefer this over search_market_disclosures, even though that sibling is the most plausible alternative for disclosure lookup, leaving the main routing decision to inference.

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