dart-search-mcp

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct aspect of the DART disclosure system: search, company info, financial statements (summary, full, multi-company, indicators), periodic/major event/shareholder reports, securities reports, and document downloads. Descriptions clearly differentiate overlapping tools like get_financial_statements vs get_financial_statements_full (summary vs full).
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern in snake_case (e.g., search_disclosures, get_company_info, download_document). Verbs are descriptive and uniform (search_, get_, download_), making the API predictable for agents.
Tool Count5/5
16 tools is well-scoped for the domain of corporate disclosure data. Each tool serves a clear purpose, covering search, retrieval, and download operations without redundancy. The count avoids bloat and feels complete for typical financial analysis workflows.
Completeness5/5
The tool set covers the full lifecycle of accessing DART data: company lookup, financial statements (single/multi, summary/full, indicators), periodic reports, major events, shareholder information, securities filings, and raw document/XBRL downloads. No obvious gaps for the stated purpose.
Average 4/5 across 16 of 16 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 64 commits 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
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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?
No annotations provided, so description must fully disclose behavior. It only states it returns a list of accounts, but no info on idempotency, permissions, rate limits, or side effects. For a read-only query, this is minimal.
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, starting with purpose then parameter details. The parameter list is lengthy but necessary. No fluff.
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?
Tool is simple with one parameter and an output schema exists, reducing burden. However, it lacks guidance on how to use the taxonomy (e.g., with financial statement tools). Adequate but not 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?
Despite 0% schema coverage, the description adds detailed enumeration of possible sj_div values with Korean labels, which is essential for correct parameter usage. This compensates well for the schema gap.
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 queries XBRL taxonomy financial statement forms (standard account system). It distinguishes from siblings like get_financial_statements by focusing on the taxonomy structure, but does not explicitly differentiate.
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 indication of when to use this tool versus alternatives. No criteria for choosing sj_div values or when not to use. The description only lists parameters without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It states that the tool returns '증권신고서 주요정보' but does not specify the format, pagination, error handling, or any side effects. While it implies a read operation, it lacks detail on permissions 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with an intro sentence, parameter list, and return statement, but it is somewhat verbose. The parameter descriptions could be integrated more concisely, and the return statement is too vague to be helpful.
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 that an output schema exists (indicated by context signals), the description's vague return statement is partially excused. However, it still fails to convey whether results are paginated, sorted, or contain any notable fields beyond 'key information.' The 0% schema coverage and lack of annotations increase the burden on the description, which it does not fully meet.
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?
With 0% schema description coverage, the description fully compensates by explaining each parameter: corp_code (DART 8-digit number), report_type (with literal list of valid types), bgn_de/end_de (date range format YYYYMMDD). This adds critical meaning beyond the schema's minimal titles.
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 verb '조회' (query) and the resource '증권신고서 주요정보' (securities report key information), with a parameter for type. It effectively distinguishes this tool from sibling tools like get_periodic_report or get_financial_statements by focusing on securities reports with a specific report type enum.
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?
The description provides no explicit guidance on when to use this tool versus alternatives. It does not mention when not to use it, nor does it reference sibling tools or provide contextual cues for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must fully disclose behavior. It mentions return fields vary by type but lacks detail on authentication, rate limits, error handling, or side effects. The tool is a read operation, but this is implied rather than stated.
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?
Description is structured with a clear purpose sentence, parameter explanations, and a return note. It is somewhat lengthy due to the report type list, but this list is essential. Front-loaded with main purpose. Could be slightly more concise, but functional.
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 params, 2 required, 27 report types) and no annotations, the description covers all parameters adequately with examples and enum values. It notes variable return fields, which is important. Lacks detailed output schema (though output schema exists, not described), and error scenarios are not addressed.
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 0%, but description provides extensive meanings: corp_code example ('00126380'), bsns_year format, reprt_code values and mapping, and a full list of 27 report_type options with Korean explanations. This goes far beyond the minimal schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool retrieves key information from DART periodic reports by type, using the verb '조회' (retrieve) and specifying the resource. It distinguishes from siblings by focusing on periodic reports with 27 specific types, which is clear and specific.
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 guidance on when to use this tool vs alternatives. It lists 27 report types but does not explain selection criteria or when other sibling tools should be preferred. No 'when not to use' or alternative recommendations.
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?
Annotations are absent, so the description carries full burden. It implies a read-only operation by stating '조회' (retrieve), but does not explicitly confirm safety, idempotency, or any side effects. No mention of authentication requirements, rate limits, or data freshness. The detailed return list adds some transparency but behavioral context is minimal.
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 well-organized with parameters and returns sections, and immediately states the purpose. The return list is detailed but arguably redundant given the output schema exists. Still, it remains reasonably concise for the complexity, and every section serves a purpose.
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 simple input (one parameter, no nesting) and presence of an output schema, the description covers the essential aspects: parameter format and return content. It lacks usage guidance, but for a straightforward retrieval tool with good output schema, the description is nearly 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 0%, but the description provides a clear explanation of the single parameter (corp_code), including format (8-digit DART number) and an example. This adds necessary semantic meaning beyond the schema's generic 'string' type. The description compensates well for the lack of schema documentation.
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 retrieves executive and major shareholder stock ownership reports from DART, specifying the exact resource and report type. It lists detailed return fields, making the tool's purpose unmistakable. The name and description together effectively distinguish it from sibling tools like get_major_shareholders_report.
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. The description does not mention scenarios or constraints, nor does it contrast with sibling tools such as get_major_shareholders_report or get_periodic_report. The agent must infer usage from the name and context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description does not disclose behavioral traits like overwriting, authentication, rate limits, or error handling. Only states the return message 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?
Very concise: one sentence for purpose, followed by structured parameter and return descriptions. Front-loaded and no wasted words.
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?
Covers basic usage but lacks details on authentication, overwrite behavior, and error scenarios. Output schema not provided, but return value described adequately for a download tool.
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?
Adds crucial meaning beyond empty schema descriptions: rcept_no format (14 digits) and source, output_dir default. Covers both parameters fully despite 0% schema coverage.
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 the tool downloads original disclosure documents. It distinguishes from sibling 'download_xbrl' by using 'original file' vs. XBRL format, but does not explicitly reference sibling.
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?
Provides specific source for rcept_no parameter ('search_disclosures result'), guiding usage. Lacks explicit alternatives or when-not conditions.
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 carry the burden. It describes the action (download) and the return value (result message with file path and list of files), but does not disclose any side effects, authentication needs, or rate limits. The behavioral transparency is adequate 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured with separate sections for parameters and returns. Every sentence is useful, though it could be slightly more concise by combining some parameter descriptions.
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 complexity (4 parameters, 2 required) and presence of an output schema, the description adequately explains parameters and return values. It lacks prerequisites or usage context, but overall provides sufficient completeness for a typical download tool.
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 description coverage is 0%, and the description fully compensates by explaining each parameter: corp_code is 8 characters, bsns_year is a year (example 2024), reprt_code maps codes to reporting periods, and output_dir defaults to current directory. This adds substantial meaning beyond the schema field 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?
The description clearly states 'XBRL 재무제표 원본파일을 다운로드합니다' (download XBRL financial statement original file), with a specific verb and resource. Among siblings like download_document and get_xbrl_taxonomy, it distinguishes itself as a tool for downloading original XBRL files.
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?
The description does not provide any guidance on when to use this tool versus alternatives. It lacks explicit when-to-use or when-not-to-use context, and no sibling differentiation or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits beyond input/output. It mentions only what the tool does and returns, but lacks information about side effects, authorization requirements, rate limits, or data freshness. The read-only nature is assumed but not stated.
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 well-structured with a summary, parameter list, and return description. It is front-loaded with the main purpose. While moderately long, it is efficient given the complexity of four parameters and the return value. Minor redundancy could be trimmed.
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 presence of an output schema and the tool's complexity, the description covers parameters and return info adequately. However, it lacks guidance on when to prefer this over sibling tools (e.g., get_financial_indicators) and does not address error handling or prerequisites, which would enhance completeness.
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 description coverage is 0%, but the description provides detailed explanations for all 4 parameters, including examples (e.g., '00126380,00164779'), defaults, and enum mappings for reprt_code and idx_cl_code. This adds substantial meaning beyond the bare 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 it retrieves major financial indicators for multiple companies ('여러 회사의 주요 재무지표를 한 번에 조회합니다'). This specific verb-resource combination and the 'multi_company' in the name distinguish it from single-company counterparts like get_financial_indicators.
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 provides detailed parameter explanations but does not explicitly state when to use this tool versus alternatives (e.g., single-company tools) or include any when-not-to-use guidance. Usage context is implied by the term '여러 회사' but not formalized.
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 provided, the description bears full responsibility for behavioral transparency. It describes a read-only query operation but lacks details on authentication, rate limits, side effects, or response structure. The return statement hints at varying fields but is not exhaustive.
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 well-structured with a clear purpose sentence, parameter block, and return note. The event type list, though lengthy, is necessary for the tool's usage. A minor improvement would be to abbreviate or group related event types, but overall it is concise relative to the information required.
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?
Despite the presence of an output schema, the description does not leverage it to reduce verbosity. It covers all parameters and return variability, but lacks error handling, pagination, or example responses. However, for a read-only query tool with a rich event type list, it is adequately complete for agent use.
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?
The input schema has 0% description coverage, so the description compensates fully. It explains all four parameters: corp_code format, event_type with 36 explicit values and Korean translations, and date range parameters with examples. This adds substantial meaning beyond the schema titles.
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 major event reports from DART by event type. It lists 36 event types and specifies the report type, distinguishing it from sibling tools that handle other report categories like periodic or securities reports.
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 querying major event reports by event type but does not explicitly guide when to use this tool versus alternatives. No references to sibling tools or exclusion criteria are provided, leaving some ambiguity for the agent.
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 describes return format (list with classification, name, value) but omits behavioral traits like side effects, data freshness, rate limits, or permission requirements. Basic behavior is covered, but not deep transparency.
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?
Well-structured with separate sections for description, parameters, and returns. Concise but thorough; minor repetition of '지표' does not detract. Front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Fully covers all parameters, default values, and return structure. Given the presence of an output schema and 4 parameters (2 required, no enums), the description is complete and provides necessary examples and code mappings.
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 description coverage is 0%, yet the description explains all four parameters with clear examples for corp_code and bsns_year, enumerates reprt_code values, and maps idx_cl_code to financial ratio categories. Significantly adds meaning beyond the bare 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 it retrieves financial indicators for a single company from DART, specifying types (profitability, stability, growth, activity). This distinguishes it from sibling tools like get_financial_statements (returns full statements) and get_multi_company_indicators (multiple companies).
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?
Provides detailed parameter descriptions and defaults, but lacks explicit guidance on when to use this tool versus alternatives like get_financial_statements or get_multi_company_financials. No exclusions or context-dependent recommendations are given.
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 output fields (접수번호, 접수일자, 등) and implies a read-only query. However, it does not disclose potential behaviors like rate limits, data coverage, or whether results are historical only. The description is adequate but lacks some behavioral context.
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, front-loading the main purpose, then detailing parameter and returns. Each sentence serves a purpose, with no fluff. Slightly verbose due to Korean formatting, but overall 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 simple single-parameter tool and the presence of an output schema, the description is fairly complete. It explains the parameter format and lists return fields. Missing details like error handling or data range, but these are not critical for this straightforward query tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter (corp_code) with 0% description coverage. The description adds meaning by stating it is an 8-character DART unique number with an example ('00126380'), which compensates for the schema's lack of detail. This provides valuable guidance 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 major shareholders report information from DART, specifying it returns holder status and changes for those holding 5% or more. The verb '조회' (retrieve) and resource '대량보유 상황보고 정보' are specific, and the details distinguish it from sibling tools like get_major_event_report.
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 indicates the required parameter (corp_code) with format example, implying use for major shareholder reports. However, it does not explicitly compare with sibling tools or state when not to use it. Context is clear but lacks exclusion criteria.
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 discloses that the tool searches a public system, lists all parameters with explanations, and indicates the return format. It does not mention destructive actions, rate limits, or authentication, but for a read-like search tool, this is sufficient transparency.
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 fairly long due to detailed parameter listing, but it is well-structured: a brief purpose sentence, followed by a parameter list with clear formatting, then return information. Every line adds value, though it could be slightly 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?
Given the high parameter count and no annotations, the description explains all parameters and return structure, and suggests related tools. It doesn't cover error handling or pagination specifics, but for a search tool with 0 required parameters, it is reasonably complete.
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?
The input schema has 0% description coverage, so the description must compensate. It provides detailed explanations for each of the 12 parameters, including examples (e.g., 'corp_name: 회사명 (예: 삼성전자)'). This adds substantial meaning beyond the schema's bare titles 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?
The description clearly states it searches the list of disclosures in the DART electronic disclosure system. It specifies the resource (DART system) and the action (searching disclosures), distinguishing it from sibling tools like download_document or get_company_info which serve different purposes.
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 provides a hint about using corp_code with other tools for detailed info, but lacks explicit guidance on when to use this tool versus alternatives, and does not mention when not to use it. It implies usage for searching disclosures but no clear exclusions or prerequisites.
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 states the tool returns detailed items but does not mention any behavioral traits such as authentication, rate limits, data freshness, or error behavior. The description is safe but minimally transparent about side effects or constraints.
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 well-structured with sections for purpose, parameter details, and return overview. Each sentence adds value without redundancy. It is concise yet comprehensive, fitting the tool's complexity.
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?
The description covers the tool's purpose, all parameters, and return contents. With an output schema present, it need not detail return format. However, it misses potential context like pagination or error handling, which slightly reduces completeness for agents.
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 0%, but the description adds rich semantics: corp_code as 8-digit DART code, bsns_year format, reprt_code mappings to report types, and fs_div options with defaults. This fully compensates for the lack of schema comments, providing clear guidance on parameter meaning and valid values.
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 full financial statements (BS, IS, CIS, CF, SCE) from DART for a single company. It distinguishes itself from siblings like get_financial_statements and get_financial_indicators by explicitly listing all five statement types and emphasizing '전체' (full).
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 provides detailed parameter usage with examples, formats, and default values, making it clear when to invoke. However, it does not explicitly exclude alternatives or state when not to use compared to sibling tools like get_financial_statements, leaving some ambiguity for an agent.
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 carry the full burden. It does explain the return structure (comparative, includes CFS/OFS) but does not disclose behavioral traits like rate limits, authentication needs, or potential side effects. The explanation of output format adds some transparency but is incomplete.
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 well-structured with clear sections (Parameters, Returns). Every sentence is informative and earns its place. It's front-loaded with the main purpose and uses bullet points for readability. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the three parameters and the presence of an output schema (not shown but indicated), the description covers purpose, parameter semantics, and return value comprehensively. It differentiates from closely related sibling tools (e.g., multi-company version). The description is complete for an agent to understand and use the tool correctly.
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 description coverage is 0%, but the description provides valuable details for all three parameters: corp_code format (8 digits, example), bsns_year format (example), and reprt_code mapping to report types with default. This adds significant meaning beyond the bare 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 it retrieves major account financial statements for a single company from DART. It lists specific financial items (매출액, 영업이익 등) and mentions comparative format, which distinguishes it from siblings like get_financial_statements_full (probably more comprehensive) and get_multi_company_financials (multiple companies).
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 specifies '단일회사' (single company) and explains parameters, but does not explicitly state when to use versus alternatives. However, the mention of single company and the specific parameter details give implicit guidance. Lacks explicit when-not-to-use or clear alternatives.
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 discloses that the tool returns key accounts and compares by company/statement type, but does not mention authentication, rate limits, or data volume limits. It provides basic behavioral info but lacks depth.
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 well-structured with sections (general, parameters, returns), written in Korean, and is concise with no extraneous content. It is front-loaded with the main purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists (context: has_output_schema=true), the description need not detail return values. It covers the tool's purpose and parameters completely, making it self-sufficient for an agent.
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?
The schema has 0% description coverage, but the description fully explains each parameter: corp_code (comma-separated DART numbers), bsns_year (business year example), and reprt_code (report type with default and codes). This adds significant meaning beyond the 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?
The description clearly states it retrieves key financial statements for multiple companies from DART and lists specific items (매출액, 영업이익 등). The verb '조회' and resource '주요계정 재무제표' are specific, and it distinguishes from siblings like get_financial_statements (single company) and get_multi_company_indicators.
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: to compare key financial items of multiple companies. It implicitly distinguishes from single-company tools, but does not explicitly state when not to use or mention alternatives like get_financial_statements or get_multi_company_indicators.
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 are provided, so the description carries full burden. It lists the return fields (company name, CEO, address, etc.) and implies no side effects. It is transparent enough for a read-only lookup, though more details on error handling or rate limits could enhance it.
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 concise, using only a few sentences to state purpose, input, and output. It is well-structured with separate sections for parameters and returns, maximizing clarity without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one required parameter, no nested objects, and an output schema exists), the description covers all necessary aspects: what it does, what input is needed, and what returns to expect. It is fully adequate for an AI agent to select and invoke correctly.
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?
The input schema provides only the parameter name and type without description (0% coverage). The description compensates fully by specifying it's an 8-digit DART code with an example, adding essential meaning 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 company overview information using a DART unique number. It specifies the input (corp_code) and distinguishes from siblings by referencing how to obtain the code from search_disclosures or search_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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains that the corp_code comes from specific sibling tools, indicating a clear prerequisite. While it doesn't list explicit when-not-to-use scenarios, it provides sufficient context for proper usage.
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 provided, the description fully discloses behavioral traits: it downloads the entire corpCode.xml on first call and caches it in memory. This goes beyond basic purpose and helps the agent understand performance implications and caching 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?
The description is concise (3 sentences plus parameter/returns sections) and well-structured with clear sections. Every sentence adds value: purpose, usage context, caching behavior, and parameter examples. No unnecessary text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single parameter and the presence of an output schema (not shown but referenced), the description is complete. It covers what the tool does, when to use it, how it works internally, and what it returns. No gaps identified.
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?
The only parameter, corp_name, has no description in the input schema (0% schema description coverage). The description fully compensates by providing clear examples ('삼성전자', '카카오', '네이버') and explaining its purpose, making the parameter semantics very clear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool's function: searching for DART's corp_code by company name. It also ties this to its use as a prerequisite for other API calls (e.g., get_company_info), clearly distinguishing it from sibling tools that perform different tasks.
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 this tool (to find corp_code for other API calls) and notes its behavior (downloads and caches corpCode.xml). However, it does not explicitly state when not to use it or mention alternative methods, though the sibling tools list and context make the purpose clear.
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

Copy to your README.md:

[![dart-mcp MCP server](https://glama.ai/mcp/servers/memorise8/dart-mcp/badges/card.svg)](https://glama.ai/mcp/servers/memorise8/dart-mcp)

Score Badge

Copy to your README.md:

[![dart-mcp MCP server](https://glama.ai/mcp/servers/memorise8/dart-mcp/badges/score.svg)](https://glama.ai/mcp/servers/memorise8/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/memorise8/dart-mcp'

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