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
- 2
- 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.5/5 across 7 of 7 tools scored.
Each tool targets a distinct function: server info, company name resolution, stock code resolution, activist monitoring, foreign holder monitoring, industry news, and general filings. Despite possible confusion between the two monitoring tools, descriptions clearly differentiate them by filer type (activist vs passive foreign) and explicitly warn against fallback errors.
Most tools use verb_noun naming (lookup_corp_code, monitor_activist_investors, etc.), but 'koreanpulse_about' breaks the pattern with a service prefix. Verbs include 'lookup', 'monitor', 'resolve', 'search', 'track', which are consistent in style but not all in the same tense. Minor inconsistency but not chaotic.
Seven tools cover the core domain of Korean financial data (DART filings, company identification, industry news) without being excessive. Each tool serves a clear purpose, and the count feels well-scoped for the server's specialization.
The tool set covers key workflows: company lookup, ticker resolution, filing tracking, and specialized monitoring for activists and foreign holders. Missing are detailed financial statements or historical filing search, but for the stated purpose of monitoring and news, it is reasonably complete.
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 10 named filers — KCGI, Align Partners, Truston Asset, Anda Asset, Cha Partners, VIP Asset, Life Asset, Platform Partners — 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 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 paywall message containing
the activation URL — surface that message verbatim to the user.
For LLM clients on a license_required error: surface the activation URL
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, 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
activation URL 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, 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?
Beyond the annotations (readOnlyHint, idempotentHint), the description discloses that a license key is required, describes the paywall error response and required action, and explains how results are tagged with activist matches. 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 front-loaded with a clear purpose but is somewhat lengthy with repeated activist lists and a detailed error handling paragraph. It is well-structured but could be more concise.
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 complexity (6 parameters, output schema exists), the description covers purpose, usage, error handling, and return details. However, it does not mention pagination or rate limits, which might be relevant for such a tool.
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?
All 6 parameters are described in the input schema with clear descriptions (100% coverage). The tool description adds context about the overall behavior but does not significantly expand on individual parameter semantics beyond what the schema provides.
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 activist investor disclosures on DART 5%-rule filings, listing specific activist names. It distinguishes itself from sibling 'track_korean_filings' by noting that activist classification cannot be derived from the raw 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?
Explicitly lists when to use this tool with a comprehensive list of user queries. Provides clear guidance on license key requirement and error handling, and warns against falling back to the free tool track_korean_filings.
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 paywall message containing
the activation URL — surface that message verbatim to the user.
For LLM clients on a license_required error: surface the activation URL
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 activation URL
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 declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint=false. The description adds value by explaining licensing requirements (paywall behavior, how to surface activation URL), the allowlist refresh quarterly, and that it does not generate trading recommendations. 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 lengthy but well-organized: main purpose, usage scenarios, license handling, sibling distinction, allowlist. Minor repetition (allowlist listed twice) could be tightened, but overall structure supports clarity for the agent.
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 6 params (100% schema coverage), output schema present, and rich annotations, the description covers all necessary aspects: purpose, usage guidelines, behavioral trade-offs, licensing, distinction from sibling, and the allowlist. No missing 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?
Input schema has 100% coverage for 6 parameters with descriptions. The description mentions passing license_key but does not add further parameter-level detail beyond what the schema provides. Baseline 3 is appropriate since schema already documents parameters adequately.
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?
Clearly states the verb 'monitor', specific resource 'foreign investor activity in Korean stocks' with DART 5%-rule disclosures, and explicitly distinguishes from sibling tool 'monitor_activist_investors'. The scope (20 named global asset managers and sovereign wealth funds) is enumerated, leaving no ambiguity.
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 lists user queries that should trigger this tool (e.g., 'is BlackRock holding <ticker>', 'foreign capital flow into Korean equities'). Provides direct alternatives for license errors (surface activation URL, do not retry with track_korean_filings) and contrasts with monitor_activist_investors based on passive vs activist intent.
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). 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). None = all. | |
| translate | No | server-side translates `title_en`. Cached aggressively. | |
| 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 already provide readOnlyHint and idempotentHint. Description adds server-side translation, aggressive caching for translate, license gate requirement, and free tier info, offering useful 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two paragraphs with front-loaded purpose and usage guidance. Could integrate 'Free tier.' more succinctly, but overall efficient and well-structured.
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 5 parameters and output schema, description covers sources, translation behavior, caching, license key, and usage context. Adequate for a complex tool with good annotations.
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%, so baseline is 3. Description reiterates industry tags and limit but adds no significant meaning beyond schema descriptions.
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 searches Korean industry news across 16 sectors with on-demand English translation. It specifies the sources (etnews, hankyung) and gives concrete examples of when to use it, distinguishing it from sibling tools like track_korean_filings.
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 says 'Use this tool when the user asks about:' followed by a comprehensive list of scenarios. Implies alternatives by referencing DART filings and listing sibling tools, providing clear guidance on when to use or not.
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 activation
URL from the paywall response 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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds context about the free tier, that returns raw filings, does not classify filers, and includes guidance on handling license errors. 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 well-structured with front-loaded purpose, usage examples, and important caveats. It is slightly verbose but every section adds value. Could be tightened, but overall clear and organized.
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 (7 parameters, multiple siblings, free vs paid), the description is complete. It explains return format, limitations, and how to handle common misunderstandings. Output schema exists, so return values need not be described.
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 the schema itself documents parameters well. The description does not add new parameter-level meaning but reinforces context like free tier and license requirement. Baseline 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 the tool's purpose: tracking Korean DART filings in English. It specifies the resource (DART filings) and the action (track), and distinguishes from siblings by explicitly stating it does not classify filers, directing to monitor_activist_investors and monitor_foreign_holders for that.
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 explicit when-to-use guidance, listing example queries. It also includes when-not-to-use, stating that for activist investors or foreign holders, other tools should be used. It addresses potential misuse and gives alternatives.
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.