dart-risk-mcp

find_actor_overlap

Compare executives and CB/BW/EB or rights offering acquirers across 2-5 Korean companies to detect shared actors and hidden M&A networks.

Instructions

여러 기업(2~5개)의 임원 겸직과 CB/BW/EB·유상증자 인수자를 비교해 공통 행위자(세력)를 탐지한다.

⚠ 실제로는 임원 겸직이 주 산출물이다. 인수자 쪽은 원문 ZIP을 열어야 해 기업당 CB 3건 + 유상증자 3건으로 상한이 걸린다 — CB를 열 번 스무 번 굴린 회사에서는 최근 3건만 본다(상한에 걸리면 「N건 중 3건 조회 · M건 미조회」로 분모를 적는다). 반면 임원현황은 사업연도 단위 명부를 다년 합집합으로 받아 상한이 없다. 무자본 M&A 세력은 인수마다 새 SPC·조합을 만들어 조합명이 매번 다르지만 사람 이름은 고정점이라, 겸직 쪽이 더 자주 걸린다.

임원은 등기·미등기를 가리지 않고 수집하며 회사별 직위·등기 여부를 함께 표기한다(동명이인을 눈으로 가릴 수 있게 하는 사실 표기이며 필터가 아니다).

DART API 제약상, 분석 대상 기업을 직접 지정해야 한다. "행위자 이름으로 역검색"은 현재 불가능하다.

CB/BW/EB 공시(CB_BW, EB 신호)와 유상증자 공시(3PCA, RIGHTS_UNDER 신호)를 모두 수집해 인수자를 통합 비교하며, 공통 행위자에는 출처 태그 (CB / 유상증자 / 임원)를 표시한다.

무자본 M&A 세력은 인수 시점에 CB를 한 번 박은 뒤 수년에 걸쳐 리픽싱·차환으로 굴리므로, 신규 CB 발행결정 공시는 과거에 몰린다. lookback_years로 조회 윈도우를 넓혀야 단년 창에 안 잡히는 다년 공통 인수자를 포착할 수 있다.

Args: company_names: 비교할 기업명 또는 종목코드 목록 (2~~5개, 예: ["에코프로", "바이오제닉스"]) lookback_years: 조회 기간(년). 기본 1년(하위호환), 1~~5년 범위. watchlist: 저장된 워치리스트 인물명. 지정 시 해당 회사군을 company_names와 합집합으로 분석한다 (manage_watchlist로 관리).

Input Schema

TableJSON Schema

Name	Required	Description	Default
`watchlist`	No
`company_names`	No
`lookback_years`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed7 schema fields changedv1.4.0Jun 21, 2026

addedInput schema / properties / company_names / anyOf

Added value: +[
+  {
+    "items": {
+      "type": "string"
+    },
+    "type": "array"
+  },
+  {
+    "type": "null"
+  }
+]

addedInput schema / properties / company_names / default
```
Added value: +null
```
removedInput schema / properties / company_names / items
```
Removed value: -{
-  "type": "string"
-}
```
removedInput schema / properties / company_names / type
```
Removed value: -"array"
```

addedInput schema / properties / lookback_years

Added value: +{
+  "default": 1,
+  "title": "Lookback Years",
+  "type": "integer"
+}

addedInput schema / properties / watchlist

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

removedInput schema / required
```
Removed value: -[
-  "company_names"
-]
```

First observedv1.0.3May 31, 2026

TDQS

A4.7/5.0

Behavior5/5

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

With no annotations, the description carries the full behavioral burden and does so richly: it discloses that executive overlap is the real primary output, that the acquirer side is capped at 3 CB + 3 rights issues per company (with the 'N건 중 3건 조회' denominator convention), that executive rosters are uncapped multi-year unions, that registered and unregistered executives are both included, and that source tags are attached. This is exactly the kind of limitation and output-composition detail an agent needs.

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?

It is long, but front-loaded with the core purpose and a warning about the actual primary output, and each subsequent paragraph discloses a distinct behavioral trait rather than restating. Only mildly verbose, and the structure (warning, mechanism, args) is easy to scan.

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 an output schema exists, return values need no explanation, and the description still covers mechanism, caps, source tagging, the DART targeting constraint, and lookback semantics. An agent has everything needed to call this 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 description coverage is 0%, so the description must compensate, and it documents all three parameters: company_names (2-5 company names or ticker codes), lookback_years (default 1 year, 1-5 range, and why to widen it), and watchlist (saved person names unioned with company_names, managed by manage_watchlist). Nothing in the Args block is left ambiguous.

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?

States a specific verb (compare/detect) and concrete resources (executive concurrent positions and CB/BW/EB-rights-issue acquirers) across 2-5 companies. An agent can immediately tell this apart from sibling tools like lookup_known_actor or get_executive_compensation.

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?

Gives clear context for when to use it (comparing a 2-5 company group to surface common actors/forces), when to widen lookback_years, and how watchlist interacts via manage_watchlist. It also states a hard usage constraint — that DART requires specifying target companies and reverse search by actor name is impossible — but does not explicitly name a sibling to use instead for reverse lookups.

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