Skip to main content
Glama

FinBridge

Taiwan Insider Share-Transfer Pre-Announcements

get_tw_insider_transfers
Read-only

Taiwan insider share-transfer filings from TWSE (上市) and TPEx (上櫃), served from the local finbridge database.

⚠These are PRE-ANNOUNCEMENTS, not executed trades. Taiwan requires directors, supervisors, managers and 10% shareholders to declare a transfer BEFORE selling (內部人持股轉讓事前申報). There is no "sold" table at all — a declaration says what someone intends to transfer and by when. What does exist is the opposite: an 未轉讓 (not-transferred) table listing declarations whose window expired without a sale, with the filer's stated reason. This tool returns both.

This is why it is a separate tool from get_dart_insider_trades (Korea) and get_edgar_insider_trades (US Form 4), which report trades that already happened. Do not compare the numbers across those tools as if they were the same event.

⚠Coverage is short and has permanent holes. The upstream endpoints publish only the CURRENT day's table — there is no historical query — so our history starts when we began collecting and any day the collector missed is unrecoverable. The response's coverage.first_report_date and coverage.days say exactly how much history exists; "no rows" for an earlier date means we never had it, not that nobody filed.

⚠No rankings or aggregates in this version (no "most-sold-by-insiders this month"). A few days of snapshots is not a sample.

Units are SHARES (股) — not the thousands of shares used by Taiwan margin data. No monetary conversion is done: planned shares times a closing price is not a transaction value. Role, method and reason strings are returned in the original Chinese so they can be checked against the source.

Args:

  • company: optional filter — TW 4-digit code, '2330.TW', 'tw:2330', or the company name

  • from / to: report_date range (YYYY-MM-DD)

  • role: substring of the declarant's role in Chinese (董事 / 監察人 / 經理人 / 大股東 / 法人董事代表人)

  • min_shares: minimum planned_shares (applies to the transfer table only)

  • include_untransferred: also return expired declarations that were not acted on (default true)

  • limit: 1-200 (default 50); response_format: 'markdown' | 'json'

Returns: {market, company?, range, transfers: [{report_date, company, declarant_role, declarant_name, method, period_from, period_to, planned_shares, daily_max_shares, transferee, held, planned, after}], untransferred: [{report_date, company, declarant_role, declarant_name, untransferred, held, declared, reason}], coverage: {first_report_date, last_report_date, days}, notes, data_as_of, page_url}

Use when: someone asks what Taiwanese insiders have declared they intend to sell, or whether a declared sale actually went through (an 未轉讓 row means it did not). Don't use it to claim an insider "sold" — this data cannot show that.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
toNoLatest report date (YYYY-MM-DD)
fromNoEarliest report date (YYYY-MM-DD)
roleNoSubstring of the declarant role in Chinese (董事 / 監察人 / 經理人 / 大股東)
limitNoMax rows per table, 1-200 (default 50)
companyNoTW company filter: 4-digit code, '2330.TW', 'tw:2330', or name
min_sharesNoMinimum planned shares (股); transfer table only
response_formatNo'markdown' for tables, 'json' for compact outputmarkdown
include_untransferredNoAlso return expired declarations that were not acted on (default true)

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
notesNo
rangeNo
marketYes
companyNo
coverageNo
page_urlNo
transfersYes
data_as_ofNo
untransferredYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.9/5.0
Behavior5/5

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

While annotations mark readOnlyHint=true and destructiveHint=false, the description goes far beyond by explaining the data is pre-announcements, not executed trades, has short unrecoverable coverage, no historical query, no aggregates, and units are shares. It also notes the 未轉讓 table. This adds critical behavioral context beyond annotations.

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?

The description is long but every sentence carries unique value—scope, warnings, units, usage. It is well-structured with headers and front-loads the core purpose. Slightly verbose but not redundant, earning a 4.

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?

The description is exceptionally complete: it covers return fields, coverage details, units, usage scenarios, and even explains the 未轉讓 table. Given the tool's complexity (8 params, output schema), nothing an agent needs is missing.

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?

Despite 100% schema coverage, the description adds meaning: min_shares applies to transfer table only, include_untransferred default true, role is a Chinese substring, units are shares not thousands, and no monetary conversion. It clarifies the exact meaning and constraints of parameters, exceeding the schema.

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 explicitly states it returns Taiwan insider share-transfer pre-announcements from TWSE and TPEx, clearly distinguishing them from executed trades. It names the sibling tools (get_dart_insider_trades, get_edgar_insider_trades) it is not, making its scope unambiguous.

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?

It provides explicit when-to-use guidance ('Use when: someone asks what Taiwanese insiders have declared they intend to sell...') and when-not-to ('Don't use it to claim an insider sold'). It also warns against comparing numbers across tools, giving clear exclusions and alternatives.

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.