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.

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: unlike US Form 4, the KR report has NO transaction price — only share counts (no value). Reports are filed within ~5 business days.

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. Dates show when Glama detected each change.

  1. First observed

TDQS

A4.9/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 the description builds on this by adding key behavioral facts: buy/sell is defined by the sign of the share change, KR reports contain no transaction price, filings are delayed ~5 business days, and summary totals cover the entire fetched set regardless of filter. This goes well beyond the annotations and schema.

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 densely informative, with every section earning its place: source, sign semantics, args, return structure, limitations, examples, routing, and error handling. It is front-loaded with purpose and a clear definition of buy/sell, then uses structured sections for details.

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?

Even with a rich output schema present, the description includes the return structure, filter semantics, examples, known limitations (no price, filing lag), and error paths. An agent has everything needed to select, invoke, and interpret this tool correctly without additional context.

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?

The schema already documents all parameters at 100% coverage, so the baseline is 3. The description adds extra value by explaining the sign convention behind tx_type, providing concrete examples for company resolution, and emphasizing the sentiment meaning of insider buying. This lifts it above baseline, though it does repeat some schema content.

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 specific action ('get insider transactions for a listed KR company'), identifies the exact source ('DART elestock'), and explicitly aligns it with SEC Form 4. It names sibling tools for US insiders and institutional holdings, so the tool is clearly differentiated from get_edgar_insider_trades and get_edgar_13f.

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 description provides explicit 'Use when' guidance, names the alternative for US insiders, and explains that unknown companies should be resolved via search_dart_company. It also clarifies that a filter with no matches returns count 0, not an error, which prevents incorrect error handling.

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.2/5.0
Disambiguation4/5

Most tools have clearly distinct resource+action targets, and the overlapping screen_* tools are thoroughly cross-referenced with 'use screen_X instead' guidance. Minor ambiguity exists between get_disclosure_feed, get_dart_filings, and get_dart_major_events, which all surface KR filings from different angles but remain distinguishable.

Naming Consistency5/5

Every tool follows a consistent verb_noun snake_case pattern: get_* for retrievers, screen_* for screeners, search_* for lookups, plus action verbs like analyze_, backtest_, compare_, import_, and query_. Subfamilies (dart_*, edgar_*, fred_*, crypto_*) are consistently prefixed, making tool selection predictable.

Tool Count3/5

37 tools is heavy, and the four momentum screeners (canslim/kell/minervini/schwartz) plus three KR disclosure tools could arguably be collapsed into parameterized variants. However, the server's unusually broad scope—KR/US/TW/JP/EU equities, crypto, macro, portfolio, backtesting—means most tools earn their place, so the count is high but not chaotic.

Completeness4/5

The surface covers the core workflow well: search, prices, fundamentals, filings, insider trades, valuation, screeners, backtesting, and portfolio tracking for KR/US, plus crypto and macro. Notable gaps are the lack of single-company financial-statement tools for TW/JP/EU (only available through screen_companies) and no real-time stock quotes, but these are workable for the stated local-database research purpose.

Resources