Skip to main content
Glama

FinBridge

Get KR Insider Trades (DART 임원·주요주주 소유보고)

get_dart_insider_trades
Read-only

Korean insider transactions for a listed KR company, from DART's 임원ㆍ주요주주 특정증권등 소유상황보고서 (elestock) — the Korean equivalent of SEC Form 4. Includes a buy-vs-sell summary and an optional buy/sell filter.

Not this tool for: US insiders (get_edgar_insider_trades) or institutional managers, which are a different kind of holder entirely (get_edgar_13f).

Buy vs sell is the SIGN of the reported share change (증감수): positive = 취득 (acquire / buy), negative = 처분 (dispose / sell). Insider BUYING is a stronger sentiment signal.

Args:

  • company (required): KR 6-digit stock code (e.g. '005930'), company name, or 8-digit DART corp_code

  • limit: number of most-recent reports to return, 1-100 (default 20)

  • tx_type: 'all' (default) | 'buy' (share change > 0) | 'sell' (share change < 0)

  • response_format: 'markdown' (default) or 'json'

Returns: {company:{corp_code, corp_name}, tx_type, summary:{buys:{count,shares}, sells:{count,shares}}, count, trades:[{filedAt, reporter, position, registered_exec, major_shareholder, change, shares_after, change_rate}], notes}. summary totals cover the whole fetched set regardless of the filter.

Important: this elestock summary API does not provide transaction dates or prices. filedAt is the filing date, not the transaction date. The underlying filing may contain these details; use get_dart_document with the returned rcept_no to inspect its tables.

Examples:

  • "삼성전자 임원 매수" -> {company:'005930', tx_type:'buy'}

  • "SK하이닉스 내부자 매도 최근" -> {company:'000660', tx_type:'sell'}

Use when: monitoring KR officer / major-shareholder buy/sell activity. For US insiders use get_edgar_insider_trades. For institutional holdings use get_edgar_13f. Errors: unknown company -> use search_dart_company; a filter with no matches returns count 0 (not an error).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoNumber of most-recent reports (default 20)
companyYesKR 6-digit stock code (e.g. '005930'), company name, or DART corp_code
tx_typeNo'all' (default), 'buy' = acquisitions (change > 0), 'sell' = disposals (change < 0)all
response_formatNo'markdown' for a table, 'json' for compact machine-readable outputmarkdown

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
countNo
notesNo
tradesYes
companyYes
summaryNo
tx_typeNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare read-only/non-destructive, but the description adds rich behavioral context beyond them: the buy/sell sign semantics, that the API provides no transaction dates or prices, that filedAt is the filing date not the transaction date, that summary totals cover the whole fetched set regardless of filter, and that an empty filter match returns count 0 rather than an error.

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?

Well front-loaded with purpose first, then exclusions, args, returns, caveats, examples, and usage. It is on the longer side, but nearly every block carries actionable information; the Returns block partially duplicates the output schema.

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 a filter-heavy tool with an output schema, this definition is fully sufficient: it states scope, alternatives, argument formats, the derived semantics of the buy/sell field, error handling, and the data-availability caveat, so an agent can call it correctly without further inference.

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?

Schema coverage is 100%, so the baseline is 3, but the description adds domain meaning beyond the schema: it spells out the accepted company identifiers (6-digit code / name / 8-digit corp_code), explains buy/sell as the sign of 증감수 at the conceptual level, and clarifies the summary-vs-filter interaction.

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+resource scoped to Korean listed companies, names the DART filing type (elestock) and explicitly equates it to SEC Form 4. It also names what it is NOT (get_edgar_insider_trades, get_edgar_13f), so an agent can distinguish it 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?

Has explicit 'Not this tool for:' and 'Use when:' sections that route to the correct sibling for US insiders and institutional holdings, plus an Errors section telling the agent what to do when a company is unknown.

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.