korean-dart-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.9.2
Disambiguation5/5
Each tool has a distinct purpose: quality snapshot, anomaly scoring, document download, financials, XBRL, corporate events, insider trading, etc. Overlaps are minimal and clarified by descriptions.
Naming Consistency3/5
Naming uses mixed conventions: some prefixed with 'get_', others not (e.g., 'buffett_quality_snapshot', 'insider_signal'). Also varied verb forms like 'download_document' vs 'get_attachments'. While mostly readable, the pattern is inconsistent.
Tool Count5/5
15 tools is well-scoped for a comprehensive Korean disclosure server. Covers company info, financials, filings, governance, and anomalies without being overwhelming.
Completeness5/5
The tool set covers the full lifecycle of disclosure analysis: search, retrieve raw documents, extract sections, financials, XBRL, corporate events, shareholder info, executive comp, insider trading, and anomaly detection. No dead ends.
Average 4.1/5 across 15 of 15 tools scored. Lowest: 3.5/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral burden. It mentions 'snapshot' but lacks details on data merging, pagination effects, authorization needs, or output structure.
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?
Two concise sentences in Korean with no redundancy, efficiently conveying the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a 5-parameter tool with high schema coverage, but lacks explanation of output structure (no output schema) and how combined results are presented.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so each parameter is already documented. The description adds little extra meaning beyond naming the two disclosure types, which the schema's include parameter already enumerates.
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 clearly states it is a synthetic query combining two types of equity disclosure (major shareholding and executive holdings), providing a snapshot of insider/outsider history. This distinguishes it from simpler sibling tools like get_shareholders.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for consolidated equity disclosure but provides no explicit guidance on when to use it versus alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility. It explains clustering based on direction and threshold (default 3), but omits details about data source limitations, rate limits, or authentication needs. Some behavioral context is provided, but not comprehensive.
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?
Three sentences, front-loaded with main purpose and key outputs. No fluff, every sentence contributes essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description must clarify return format. It mentions net change, buyer count, cluster presence, and signal, but lacks specifics on structure or data types. Adequate but not fully complete.
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% with Korean descriptions. The description adds meaning by explaining the aggregation logic and signal interpretation, going beyond individual parameter descriptions. However, all content is in Korean, which may limit universal clarity.
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 clearly states the tool aggregates insider transactions into buy/sell clusters, calculates net change, buyer counts, and quarterly clusters, providing a Buffett-style signal. This distinctively separates it from siblings like buffett_quality_snapshot or disclosure_anomaly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. While the purpose is clear, the description does not specify scenarios or exclusions, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It indicates a read operation without side effects, but lacks details on authentication, rate limits, or data freshness. Adequate for a simple retrieval but leaves gaps.
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?
A single sentence front-loads the purpose with specific details. No filler words; every part contributes to clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description covers the essential returned fields and input format. Minor gaps like error conditions or response format are not critical but could enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description covers the 'corp' parameter fully (company name/stock code/corp_code). The tool description adds value by listing output fields but does not enhance parameter semantics beyond 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 clearly states the tool retrieves a company overview, listing specific fields (industry, establishment date, etc.). It uses a specific verb and resource, distinguishing it from sibling tools like search_disclosures and resolve_corp_code.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for getting company overview by name/code, but does not provide explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses parallel execution per company, the mode switching based on input count, and the type of metrics (ROE, Debt, CAGR, checks, rankings). However, it lacks details on what the '4 check types' or '5 indicators' are and does not describe output format, which slightly reduces transparency.
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 three sentences in Korean, front-loading the purpose ('버핏 퀄리티 체크리스트'). It efficiently covers the two modes, time series details, and integration. No redundant or unnecessary content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, no output schema, no annotations), the description provides high-level behavioral context but omits specific definitions of 'check types' and 'indicator rankings'. The output structure is not described, which could leave an agent uncertain about the exact return format. It is adequate but could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all four parameters. The tool description reinforces the corps parameter's mode-switching behavior but adds minimal new meaning beyond the schema. The description introduces output-related terms (ROE, CAGR, checks) but these are not tied to specific parameters, so the added value is marginal.
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 clearly states the tool provides a 'Buffett quality checklist' and distinguishes two modes based on the number of companies: for one company it returns a time series of ROE/Debt/CAGR and four checks; for multiple companies it returns snapshots and rankings. It also mentions integration with the existing 'quality_compare' tool, making its purpose and behavior specific and distinct from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for Buffett quality analysis but does not explicitly state when to use this tool versus alternatives, such as 'get_financials' or 'search_disclosures'. No when-not or exclusion criteria are provided. The integration note with quality_compare gives some context but not clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses key behaviors: custom parser for markdown, default truncation at 100,000 characters, and handling of large documents. Missing details like error handling or authentication, but overall transparent for a download tool.
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?
Two sentences with dense, relevant information. No fluff, front-loaded purpose, every sentence adds value. Ideal conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers return formats, custom processing, truncation, and scope. Missing details on error responses or behavior for missing documents, but adequate given the tool's simplicity and full schema coverage.
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 baseline is 3. The description adds value by explaining the custom parser for markdown and the truncation behavior, providing context beyond the schema's parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns disclosure documents in markdown, raw XML, or plain text, and mentions the custom parser and default format. However, it doesn't explicitly differentiate from sibling tools like get_periodic_report, which may also return document content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It says the tool is used for 'all disclosure originals' and lists examples, implying broad usage. However, it lacks explicit when-not-to-use guidance or references to alternatives among siblings, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It implies read-only behavior by calling it a 'snapshot' and describes the composite nature, but lacks details on side effects, auth requirements, or rate limits.
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?
Two concise sentences: first states purpose, second provides usage guidance. No redundant information, front-loaded with core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite missing output schema, description gives high-level overview of composite output. However, it lacks details about return format and does not fully address all four parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% with some parameter descriptions; the description adds context by naming the four sections, which maps to the sections enum. However, it does not compensate fully for undocumented parameters like year and report.
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?
Description clearly states it provides a governance snapshot with four specific sections (largest shareholder, changes, minority shareholders, total stocks). It distinguishes itself from sibling tool get_periodic_report by noting that tool can be used for individual sections.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly mentions when to use get_periodic_report instead if only specific sections are needed. Provides clear context for tool selection, though does not cover all usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It explains what the tool computes (score, flags, evidence) and that it does not give recommendations. It does not disclose data freshness, rate limits, or side effects of calling the tool.
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?
Description is a single sentence succinctly listing what the tool does and returns, with no wasted words. It is front-loaded with the key concept and then details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema, the description adequately explains the output (score, flags, evidence, data frame). Parameters are fully covered. Sibling tools exist but not explicitly compared. The description is fairly complete for the tool's purpose.
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% with descriptions for all 4 parameters. The added description explains the composite nature of the score and the purpose of audit_years for comparing auditor/opinion, providing meaning beyond schema parameter names.
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?
Description clearly states the tool computes a score (0-100) for accounting/governance anomaly signs including restatement ratio, auditor change, adverse audit opinion, capital stress, and returns structured flags and evidence. This distinguishes it from sibling tools like buffett_quality_snapshot or insider_signal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies use for anomaly detection and provides a data frame for LLM judgment without direct recommendations. However, it lacks explicit when-to-use, when-not-to-use, or mention of alternative tools among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It describes the two modes but does not explicitly state that the tool is read-only, nor does it mention any side effects, rate limits, or auth requirements. The Korean word '조회' implies inquiry, but it is not explicit for non-Korean readers.
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 two sentences, front-loaded with the core purpose. It is concise but could be better structured (e.g., bullet points). Every sentence contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters, 100% schema coverage, and no output schema, the description covers the two modes well but lacks details on return format, pagination, or any constraints. It is moderately complete.
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%, but the description adds value by explaining mode semantics (e.g., timeline auto-selects capital events if event_types not specified) and the corporate parameter. It goes beyond the schema's basic descriptions.
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 clearly states the tool retrieves corporate events from a specific report (DS005) with two modes. It distinguishes itself from sibling tools, none of which query events.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use each mode: single for one event type, timeline for capital-related events over a period, calling it a 'killer mode' for extracting capital stress narratives. It does not explicitly mention when not to use, but the guidance is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description explains scope-dependent behavior, response size impact of sj_div, and speed differences. Lacks error conditions or rate limits but sufficient for safe use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is informative but somewhat verbose with multi-sentence explanations. Core purpose is front-loaded, but could be more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Completeness is good given no output schema; covers all parameters and behavioral nuances. Does not describe return format explicitly but implied by '행' (rows).
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 description coverage is high (83%), but description adds valuable context for scope and sj_div, including corps count limitations and default response size reduction that schema doesn't capture.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states '재무정보 조회' (financial info retrieval) and distinguishes between summary (key accounts) and full (complete statements). However, it could better differentiate from sibling tools like get_xbrl.
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?
Explicitly describes when to use summary (single/multi companies, fast) vs full (single company, detailed), and how sj_div can reduce response size. Also explains constraints on corps count per scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. While '조회' (inquiry) implies a read-only operation, the description does not explicitly state that the tool does not mutate data or require special authorization. It focuses on data retrieval but lacks explicit safety or permission cues.
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 extremely concise: two sentences that front-load the primary purpose and sections, then provide an alternative usage note. Every word earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, composite of 6 sections, no output schema), the description covers the core purpose and usage context well. It could mention the output format to aid agent understanding, but the schema's section descriptions already handle defaults. Adequate for effective tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%, and the description adds value by listing and explaining the six section values for the 'sections' parameter. However, it does not elaborate on the 'corp', 'year', or 'report' parameters beyond what the schema minimally provides, leaving gaps for an agent.
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 clearly states the tool performs a composite query of six sections of executive compensation, listing each section and distinguishing it from the sibling tool get_periodic_report for single-section queries. The verb '합성 조회' (synthetic query) and resource '임원 보수 6개 섹션' are specific and 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?
The description explicitly states when to use this tool (for all six sections at once) and when to use an alternative (get_periodic_report for a single section), providing clear guidance on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses behavioral traits: raw returns original ZIP, markdown is filtered (50 tags, 3 years, 3 columns, ~8KB), markdown_full includes full taxonomy with calculation verification (~30-60KB). No contradictions or missing destructive hints.
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?
Single sentence with a dash structure efficiently conveys all key options and their characteristics. No extraneous information; every part is informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters, 3 enums, and no output schema, the description adequately explains the tool's core functionality and format trade-offs. However, it could explicitly state when to choose each format (e.g., raw for full data, markdown for quick analysis) and what the output structure looks like.
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%, but the description adds value by explaining the format options' implications (e.g., file sizes, industry-specific auto response) and connecting parameters like fs_div and out_dir to specific formats, enhancing understanding beyond 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?
Description clearly states the tool retrieves XBRL financial statements and explicitly differentiates three format options (raw, markdown, markdown_full) with specifics about each, such as file sizes and content scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus sibling tools like get_financials or get_periodic_report. Usage context is implied through format descriptions but not directly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description should disclose behavioral traits. It does not mention read-only nature, authorization needs, rate limits, or side effects. The description focuses on functionality rather than behavior.
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?
Two concise sentences, front-loaded with core information. Every word adds value; no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and 4 parameters, the description covers the tool's purpose, provides examples, and mentions alternatives. It lacks details on return format or pagination, but is adequate for selection.
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 50%. The description adds value by grouping report_type values into semantic categories (주주, 임직원, 보수, etc.) that are not in the schema, aiding understanding beyond the enum list.
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?
Description clearly states the tool retrieves 29 specific sections from a business report using enum values. It gives concrete examples and distinguishes from the sibling tool download_document for full-text retrieval.
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?
Explicitly says to use this for individual sections and notes that download_document is the alternative for full document text, providing clear when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes sorting order and that it returns corp_code candidates. With no annotations, description carries full burden. Does not mention not-found behavior or rate limits, but the read-only nature is implied.
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?
Two sentences, front-loaded with main purpose, no wasted words. Efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description implies a list of candidates. Could be more explicit about return format, but adequate given the tool's simple purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the description repeats the schema's parameter descriptions. Does not add new meaning beyond the schema, but mentions sorting behavior which indirectly helps understand query use.
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?
Description clearly states the tool resolves company names or stock codes to OpenDART corp_code, with sorting logic (listed, exact match, short name). Clearly distinguishes from sibling tools that use internal resolution.
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?
Explicitly states that other tools automatically resolve corp_code internally, and this tool is for checking candidates when results are ambiguous. Provides clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It transparently discloses the scraping-based approach and the kordoc conversion engine. It also mentions truncation and outline parameters, providing insight into limitations. However, it does not detail failure modes, rate limits, or the exact behavior when scraping fails.
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 extremely concise: two sentences that convey the purpose, mode options, file types, and technical background. Every sentence adds essential information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (2 modes, multiple file types, scraping-based) and no output schema, the description covers key aspects. However, it lacks details about the return format for list mode (e.g., what fields are in the attachment list) and the exact structure of the extracted markdown. This minor gap prevents a perfect score.
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?
Schema coverage is 100%, but the description adds significant value beyond the schema. It explains the mode-dependent behavior of index/filename, the special handling of ZIP attachments via zip_index, and the purpose of truncate_at and outline_max_items. This allows an agent to understand parameter interactions and defaults.
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?
Description clearly states the two modes (list/extract) and the types of attachments (HWP/PDF/DOCX/XLSX). It distinguishes the tool as a specialized attachment handler for DART disclosures, which is distinct from other sibling tools that focus on financial data or document downloads.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the two modes and when to use each ('list' for listing attachments, 'extract' for downloading and converting to markdown). It provides context that the tool uses DART viewer scraping due to missing official API endpoints. However, it does not explicitly compare against sibling tools like 'download_document' or provide when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It details behavioral traits: three modes with parallel execution, automatic filter application in preset, concurrency limits, and DART API daily/quota limits. It also links results to download/get_attachments via rcp_no.
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 concise (one sentence) but dense; it packs mode details and linking into a single line. Could benefit from structured formatting, but remains clear and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (13 parameters, 3 modes, no output schema), the description covers modes, parameter notes, and API limits. However, it does not explicitly describe the output format (e.g., that results include rcp_no), which would enhance completeness.
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% with all 13 parameters described. The description adds context beyond schema, e.g., 'days' default for preset vs. normal mode, and concurrency parameter notes about API limits. Baseline is 3, and extra context justifies a 4.
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 clearly states 'DART disclosure search' and lists three distinct modes (basic, preset, all_pages), specifying their use cases. This distinguishes it from sibling tools like download_document or get_attachments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use each mode (basic for single page, preset for automatic filters, all_pages for full period), providing clear context. However, it does not explicitly exclude alternative tools or state prerequisites, as there are no similar sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

korean-dart-mcp MCP server – quality and maintenance score on Glama

Copy to your README.md:

[![korean-dart-mcp MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/aesthetic-legalism5470/korean-dart-mcp/badges/card.svg)](https://glama.ai/mcp/servers/aesthetic-legalism5470/korean-dart-mcp)

Score Badge

Copy to your README.md:

[![korean-dart-mcp MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/aesthetic-legalism5470/korean-dart-mcp/badges/score.svg)](https://glama.ai/mcp/servers/aesthetic-legalism5470/korean-dart-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/aesthetic-legalism5470/korean-dart-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server