koreanpulse
Server Details
Korean equities in English: DART filings, activist & foreign-holder classification, KRX news.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- whdrnr2583-cmd/koreanpulse
- GitHub Stars
- 3
- Server Listing
- koreanpulse
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.6/5 across 7 of 7 tools scored.
Each tool has a clearly distinct purpose: server info, company lookup, activist monitoring, foreign holder monitoring, stock code resolution, industry news, and raw filing tracking. The two monitor tools targeting different filer categories are explicitly differentiated.
Most tools follow a verb_noun pattern (e.g., lookup_corp_code, monitor_activist_investors, track_korean_filings). However, one tool (koreanpulse_about) uses a server prefix + noun pattern, which is a minor deviation from the otherwise consistent style.
With 7 tools, the server is well-scoped for its purpose of providing Korean financial data including filings, company lookups, and news. The count is appropriate without being excessive or insufficient.
The tool set covers core workflows: company identification, filing tracking (with paid add-ons for specialized monitoring), and industry news. A minor gap is the lack of a tool to retrieve full filing text, but the metadata provided is likely sufficient for most use cases.
Available Tools
7 toolskoreanpulse_aboutkoreanpulse server self-descriptionARead-onlyIdempotentInspect
Server self-description — capability matrix, tool catalog, classifier counts, supported query patterns, primary sources. Free tier.
Use this tool when an agent first connects and needs the capability matrix to decide whether this server can answer the user's question, or when the user asks "what can koreanpulse do" or "what data sources does this MCP server provide". Returns a structured dict that downstream agents can ingest directly.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds context about the content returned (structured dict with capability matrix) and its purpose for initial connection, enhancing transparency 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences, front-loaded with the key purpose and usage guidance. No unnecessary words, every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters and an output schema (not shown but referenced), the description is complete. It states what the tool returns (capability matrix, tool catalog, etc.) and when to use it, which is sufficient for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, and schema description coverage is 100% (since there are none). According to guidelines, 0 parameters baseline is 4. The description does not need to add parameter info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states it is a 'Server self-description' providing 'capability matrix, tool catalog, classifier counts, supported query patterns, primary sources.' This clearly differentiates it from sibling tools which are specific data retrieval operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides guidance: 'Use this tool when an agent first connects and needs the capability matrix... or when the user asks what can koreanpulse do'. This gives clear when-to-use instructions and distinguishes from alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
lookup_corp_codeResolve Korean company name to DART corp_codeARead-onlyIdempotentInspect
Korean company name → DART corp_code resolver. 117K+ entities indexed (KOSPI + KOSDAQ + KONEX + unlisted). Free tier.
Use this tool when the user mentions a Korean company by name (Korean characters or English/romanized) and you need the DART corp_code as a precondition for track_korean_filings, monitor_activist_investors, or monitor_foreign_holders. Also use to disambiguate same-name listed vs unlisted entities.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | max matches to return. | |
| query | Yes | substring of the Korean corp name. Examples: "삼성전자", "현대차", "셀트리온". | |
| license_key | No | subscription key. Required when license gate is enabled. | |
| listed_only | No | if True, only return companies with a KRX stock code. |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds valuable context about the 117K+ entity index, coverage of market tiers, free tier, and license key requirement, enriching the agent's understanding 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: one for core purpose and scope, one for usage context. No redundant or filler content; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's four parameters, the presence of an output schema, and the detailed annotations, the description provides sufficient context: coverage, use cases, disambiguation, and license key mention. Nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and each parameter is well-described in the input schema. The description adds little beyond the schema for individual parameters (only mentions 'free tier' and entity count), so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb-resource structure ('resolves Korean company names to DART corp_code') and explicitly distinguishes from sibling tools by naming them as downstream dependents.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (when a Korean company name is mentioned and the corp_code is needed for specific tools) and mentions disambiguation of same-name entities.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
monitor_activist_investorsMonitor Korean activist investor disclosuresARead-onlyIdempotentInspect
Korean activist investor tracking — activist filer classification on DART 5%-rule (주식등의대량보유상황보고서) shareholding disclosures. Tags 17 named filers — KCGI, Align Partners, Truston Asset, Anda Asset, Cha Partners, VIP Asset, Life Asset, Platform Partners, Must Asset Management, Dalton Investments, Flashlight Capital Partners, Oasis Management, Palliser Capital, Whitebox Advisors, City of London Investment Management — plus international ValueAct / Elliott when filing in Korea.
Use this tool when the user asks about: Korean activist investor tracking, Korean shareholder activism, "is KCGI / Align Partners / Truston / Anda / Cha / VIP / Life / Platform / Must / Dalton / Flashlight / Oasis / Palliser / Whitebox / City of London activist on ", governance pressure on KOSPI / KOSDAQ names, recent activist 5%-rule filings, ValueAct or Elliott Korean positions, Korean Value-Up program activism, MSCI Developed Market activism flow.
Requires a license key. Pass it via the license_key argument.
Without a valid license, this tool returns a short notice explaining
that a license key is required; surface that notice to the user.
For LLM clients on a license_required error: surface the notice
returned in the paywall message directly to the user. Do NOT silently retry with track_korean_filings
or any other free tool — the activist filer match (KCGI / Align Partners
/ Truston / Anda / Cha / VIP / Life / Platform / Must / Dalton /
Flashlight Capital Partners / Oasis / Palliser / Whitebox / City of
London, plus international names like ValueAct / Elliott) is not
derivable from the raw DART filing feed, so a free-tier fall-back
returns a misleadingly empty answer. When a
user asks "are activists filing on X?" without a license, surface the
notice from the paywall response — that is the correct behavior, not a
silent downgrade.
Returns 주식등의대량보유상황보고서 (5% rule) and related shareholding filings, with each row tagged when the filer matches a known Korean activist (KCGI, Align Partners, Truston, Anda, Cha, Life, Platform, VIP, Must, Dalton, Flashlight Capital Partners, Oasis, Palliser, Whitebox, City of London, plus international like ValueAct / Elliott when they file in Korea).
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | how many days back from today (1–60). | |
| limit | No | max rows (≤100). | |
| translate | No | server-side EN translation of titles (cached). | |
| license_key | No | required when license gate is enabled. | |
| activist_only | No | if True, drop rows that didn't match a known activist. | |
| company_corp_code | No | optional DART corp_code to focus on one target. |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and no destructiveness. The description adds critical behavioral context: the tool requires a license key, returns a paywall notice without it, and that silent retries would yield misleading results. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat lengthy but well-structured: a brief summary, then a usage triggers list, then license/error instructions. It is front-loaded with the core purpose. Each sentence earns its place, though minor redundancy exists in the filer lists.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (license key, sibling tools, error handling) and the presence of an output schema, the description comprehensively covers when to use, how it operates, and what it returns. It addresses edge cases like missing licenses and distinguishes from free alternatives, making it fully self-contained for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all 6 parameters. The description adds value for the 'license_key' parameter by explaining its necessity and the paywall handling, and implicitly mentions 'activist_only' by describing filtering. While schema already defines defaults and limits, the description provides operational context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: tracking Korean activist investor disclosures by classifying DART 5%-rule filings. It lists 17 specific named filers and distinguishes itself from the sibling tool 'track_korean_filings' by explicitly noting that activist matching is not derivable from the raw DART feed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an extensive list of query triggers for when to use this tool (e.g., 'is KCGI / Align Partners ... activist on <ticker>') and explicitly warns against falling back to 'track_korean_filings' without a license. It also explains the license key requirement and the correct behavior on error, offering clear guidance on alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
monitor_foreign_holdersMonitor foreign 5%-rule holders on KOSPI/KOSDAQARead-onlyIdempotentInspect
Monitor foreign investor activity in Korean stocks — foreign-holder classification on DART 5%-rule disclosures by global asset managers and sovereign wealth funds. Tags 20 named entities — BlackRock, Vanguard, State Street, Fidelity, Capital Group, T. Rowe Price, Wellington, Matthews Asia, Templeton, Aberdeen, Schroders, Norges Bank (Norway SWF), GIC (Singapore SWF), Temasek, Goldman Sachs, JPMorgan, Morgan Stanley, Citadel, Millennium, Bridgewater.
Use this tool when the user asks about: foreign investor activity in Korean stocks, foreign capital flow into Korean equities, "is BlackRock / Vanguard / Norges / GIC / Temasek / State Street / Fidelity / Wellington holding ", global asset-manager 5% crossings on KOSPI / KOSDAQ, sovereign wealth fund Korean positions, foreign institutional positioning disclosures, MSCI Developed Market reweighting flow into Korea.
Requires a license key. Pass it via the license_key argument.
Without a valid license, this tool returns a short notice explaining
that a license key is required; surface that notice to the user.
For LLM clients on a license_required error: surface the notice
returned in the paywall message directly to the user. Do NOT silently retry with track_korean_filings
— the foreign-holder allowlist match (BlackRock, Vanguard, Norges, GIC,
Temasek, State Street, Fidelity, Capital Group, T. Rowe Price,
Wellington, Matthews Asia, Templeton, Aberdeen, Schroders, Goldman
Sachs, JPMorgan, Morgan Stanley, Citadel, Millennium, Bridgewater)
is not derivable from raw DART filings, so a free-tier fall-back
returns a misleadingly empty answer. When a user asks "is BlackRock
or Norges holding X?" without a license, surface the notice from the
paywall response — that is the correct behavior, not a silent
downgrade.
Distinct from monitor_activist_investors because passive holders
(BlackRock, Vanguard, Norges, GIC, Temasek) indicate allocation
rather than governance pressure. Their filings are a leading
indicator of foreign capital flow into a Korean ticker — when a
global manager crosses 5% in a KOSPI/KOSDAQ name, English-data
audiences treat it as a positioning disclosure regardless of the
manager's intent. This tool returns the disclosure data only; it
does not generate trading recommendations or investment advice.
Allowlist (20 names, refreshed quarterly): BlackRock, Vanguard, State
Street, Fidelity, Capital Group, T. Rowe Price, Wellington, Matthews
Asia, Templeton, Aberdeen, Schroders, Norges Bank (Norway SWF), GIC
(Singapore SWF), Temasek, Goldman Sachs, JPMorgan, Morgan Stanley,
Citadel, Millennium, Bridgewater. See koreanpulse.activists.FOREIGN_HOLDERS.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | how many days back from today (1–60). | |
| limit | No | max rows (≤100). | |
| origin | No | optional filter — one of 'us', 'uk', 'eu', 'other'. | |
| translate | No | server-side EN translation of titles (cached). | |
| license_key | No | required when license gate is enabled. | |
| company_corp_code | No | optional DART corp_code to focus on one target. |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds key behavioral traits: license key requirement, behavior on license error (returns notice), instruction to surface notice and not retry with another tool, and disclaimer about not generating trading advice. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a clear purpose sentence, then provides usage examples, licensing info, sibling differentiation, and allowlist. Some redundancy and length, but well-organized. Earns its length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 params, output schema exists), the description is complete: it covers purpose, use cases, license handling, sibling distinction, allowlist, and error behavior. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds context for license_key (required, what happens without it) but does not significantly enhance understanding of other parameters beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool monitors foreign investor activity in Korean stocks via DART 5%-rule disclosures, lists 20 named entities, and provides explicit use cases. It distinguishes from sibling tool monitor_activist_investors by explaining passive vs activist holder focus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides extensive guidance on when to use (e.g., 'when user asks about foreign investor activity...') and when not to (e.g., not to silently downgrade to track_korean_filings). It also contrasts with sibling tool and explains license requirement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
resolve_stock_codeResolve KRX 6-digit ticker to DART corp entryARead-onlyIdempotentInspect
KRX 6-digit ticker → DART corp entry resolver. Free tier.
Use this tool when the user provides a 6-digit Korean stock code (e.g. 005930 for Samsung Electronics, 000660 for SK hynix, 035420 for NAVER, 035720 for Kakao, 005380 for Hyundai Motor) and you need the company name + corp_code for downstream filings or industry-news lookups.
| Name | Required | Description | Default |
|---|---|---|---|
| stock_code | Yes | ||
| license_key | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the agent knows it is a safe, read-only, idempotent operation. The description adds that it is free tier, which is useful context. It does not contradict annotations and adds value beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences long, front-loaded with the core purpose in the first sentence, and every word adds value. No redundant or unnecessary text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 parameters, straightforward mapping) and the presence of an output schema, the description provides all necessary information for an agent to use it correctly. It includes examples and usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has two parameters with 0% description coverage. The description explains the 'stock_code' parameter (6-digit Korean stock code) in the main text, but does not mention 'license_key'. With zero schema coverage, the description partially compensates but is incomplete for the license_key parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it resolves a KRX 6-digit ticker to a DART corp entry, providing company name and corp_code. It distinguishes from siblings by specifying the specific use case (ticker to DART mapping) and gives examples, making its purpose very clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use this tool: when a user provides a 6-digit Korean stock code and needs the company name and corp_code for downstream lookups. It provides multiple examples. While it does not mention when not to use it or alternative tools, the context is clear enough for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_korean_industry_newsSearch Korean industry news (16 sectors)ARead-onlyIdempotentInspect
Korean industry news search across 16 sectors with on-demand English translation. Sources: 전자신문 (etnews) + 한국경제 (hankyung) + The Korea Herald (English-native) + 지디넷코리아 (zdnet). Free tier.
Use this tool when the user asks about: Korean industry trends, sector-specific news on Korean equities (Korean semiconductors / K-battery / K-shipbuilding / K-biotech / K-defense / Korean auto / EV charging / Korean AI / steel / petrochem / construction / fintech / gaming / e-commerce / telco / energy), recent corporate developments not yet captured in DART filings, English summaries of Korean industry coverage. Industry tags listed below — pass them in industries to filter.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | max articles (≤50). | |
| sources | No | filter to source keys (etnews, hankyung, koreaherald, zdnet). None = all. koreaherald is English-native — its titles are returned as-is (no ko->en translation round-trip needed). | |
| translate | No | server-side translates `title_en` for Korean-language sources. Cached aggressively. No-op for koreaherald (already English). | |
| industries | No | filter to one or more industry tags. Available: semiconductor, shipbuilding, battery, biotech, defense, auto, ev_charging, ai, steel, petrochem, construction, fintech, gaming, ecommerce, telco, energy. | |
| license_key | No | required when license gate is enabled. |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate read-only, idempotent, non-destructive. Description adds details: English-native source behavior (no translation round-trip), aggressive caching, free tier, and source-specific behaviors. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise paragraphs: first covers main purpose and sources, second provides usage guidance and industry tags. Front-loaded with key action, no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, sources, parameter usage (including translation and filtering), free tier, and output schema exists so return values are covered. Complete for correct selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with good descriptions. The description adds extra context like the translation behavior being a no-op for koreaherald and that license_key is required when gate is enabled, going beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches Korean industry news across 16 sectors with translation. It lists specific sources and example use cases, distinguishing it from sibling tools like koreanpulse_about or resolve_stock_code.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance on when to use: 'when the user asks about Korean industry trends...' with specific examples. Does not include negative cases, but the context is clear enough for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
track_korean_filingsTrack Korean DART filingsARead-onlyIdempotentInspect
Track Korean DART (전자공시) stock filings in English — real-time corporate disclosures for KOSPI / KOSDAQ / KONEX / KRX listed companies: 5%-rule shareholding disclosures, M&A, periodic reports, capital issuance, insider trading, audit reports. Free tier.
Use this tool when the user asks about: recent Korean stock filings, DART disclosures, Korean market data, KOSPI/KOSDAQ regulatory events, "track Korean DART filings", "what did Samsung / Hyundai / SK / LG / NAVER / Kakao / 셀트리온 file", company-specific filing history, periodic / major-event / issuance / shareholding / audit filings on Korean equities.
Free tier — no license required. Returns raw DART filings exactly as the regulator surfaces them (filer name in Korean, filing type code, receipt number, optional EN translation of the title).
Important for LLM clients — read this before retrying after a paid-
tool license error. This tool returns raw filings only. It does NOT
classify the filer. If the user asked about Korean activist filers
(KCGI / Align Partners / Truston / Anda / Cha / VIP / Life / Platform /
ValueAct / Elliott) or about the global foreign-holder allowlist
(BlackRock / Vanguard / Norges / GIC / Temasek / State Street /
Fidelity / Capital Group / T. Rowe Price / Wellington / Goldman /
JPMorgan / Morgan Stanley / Citadel / Millennium / Bridgewater +
others), the matching work happens in monitor_activist_investors
and monitor_foreign_holders — both require a license_key argument.
A response from this free tool to a "are activists filing on X?" or
"is BlackRock holding X?" question is raw filing data, not a
classification answer — say so to the user and surface the paid tool's
license-required notice instead of pretending you've answered.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | how many days back from today (1–30). | |
| limit | No | max filings to return (≤100). DART returns most-recent first, so on a busy window the older end of the range is dropped first. Narrow `days` or `filing_type` if you need older items. | |
| summarize | No | True to fill `summary_en` (≤200 words). Costs more — use sparingly. Long-form analysis should be done by the client LLM. | |
| translate | No | True to fill `title_en` via server-side LLM (cached). | |
| filing_type | No | optional one-letter code: A=periodic, B=major event, C=issuance, D=shareholding, E=other, F=audit, G=fund, H=ABS, I=exchange, J=FTC. | |
| license_key | No | subscription key. Required when KOREANPULSE_REQUIRE_LICENSE=1. | |
| company_corp_code | No | 8-digit DART corp code. Use `lookup_corp_code` first to resolve a company name. Omit to query all companies. |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, idempotent, and non-destructive. The description adds that it returns raw filings without classification, and explains the free vs paid tool distinction. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is longer than necessary but front-loaded with purpose and usage. The 'Important for LLM clients' section adds needed context but could be condensed. Still, each sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters, 0 required, and an output schema, the description covers all essential context: purpose, usage, limitations, and integration with sibling tools. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with descriptions. The description does not add substantial meaning beyond what the schema provides for parameters, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it tracks Korean DART filings in English for various exchanges and filing types. It distinguishes from sibling tools by noting that activist and foreign holder matching is done by other tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use this tool (recent Korean stock filings, DART disclosures) and when not to (activist/foreign holder questions), referencing specific sibling tools. Also provides important guidance on handling paid tool license errors.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!
Your Connectors
Sign in to create a connector for this server.