korean-stat-mcp

Server Quality Checklist

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

Latest release: v0.1.4
Disambiguation5/5
Each tool has a clear, distinct purpose. Tools like search_statistics and search_key_indicators target different data types (general tables vs. key indicators), and browse_categories vs. list_key_indicators similarly avoid overlap. Detailed descriptions ensure no ambiguity.
Naming Consistency5/5
All tool names follow a consistent verb_noun snake_case pattern (e.g., search_statistics, get_table_metadata, filter_statistics). Convention is uniform across all 16 tools, with no mixing of styles or vague verbs.
Tool Count5/5
16 tools is well-scoped for the domain of Korean statistics. The set covers discovery, browsing, metadata, data retrieval, filtering, aggregation, verification, key indicators, and stored data management without being excessive.
Completeness5/5
The tool surface covers the full statistical workflow: searching and browsing tables, inspecting metadata, retrieving data, filtering, aggregating, verifying claims, and accessing key indicators. Stored data management and power-user tools round out the offering without significant gaps.
Average 4.2/5 across 16 of 16 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses parameter priority (start/end date overrides recent_n) and pagination behavior. Also states the return structure. However, with no annotations, it fails to mention whether the tool is read-only, requires authentication, or has rate limits, leaving gaps in safety and usage constraints.
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 introductory sentence, a code-like service call, then Args and Returns sections. It is somewhat verbose, but the structure aids readability. Could be more concise by removing redundant elements like the service call string.
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 parameters and return format adequately given the tool's complexity (6 params, 1 required). However, it lacks broader context such as how it differs from get_key_indicator (which may also provide details), and does not mention output schema details even though one exists. The tool sits in a large sibling set, but no comparative info is provided.
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?
Since the input schema has 0% description coverage, the description fully compensates by explaining each parameter: jipyo_id (required), start_date/end_date with examples, recent_n with conflict behavior, and page/limit. This adds significant meaning beyond the schema's type/default info, though date format specifics could be clearer.
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 states it queries 'time series detailed data of KOSIS statistical key indicators', clearly identifying the resource and action. It distinguishes from sibling tools like list_key_indicators and search_key_indicators which are for listing or searching, while this tool provides details for a specific indicator.
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. It does not mention prerequisites, when not to use, or compare with siblings like get_key_indicator or get_statistics_data, leaving the agent to infer 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 disclose behavioral traits. It does not state whether the tool is read-only, any side effects, authentication needs, or rate limits. The return format is described, but not operational behavior.
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 Args and Returns sections, and each parameter is clearly explained. It is not overly verbose, though some redundancy in Korean text could be trimmed. Still, it is mostly 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 absence of annotations and the presence of an output schema (which we don't see but is noted), the description provides a good overview of inputs and the return format. However, it lacks behavioral context and does not mention prerequisites or error cases, which are needed for full 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?
The description fully explains all four parameters: by (with enum values), value (with context-dependent meaning), page, and limit. It provides enough detail for an agent to correctly populate them, compensating for the 0% schema description coverage.
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 that the tool searches KOSIS statistical key indicators by name or unique ID. It provides specific endpoints and distinguishes itself from sibling tools like search_statistics by targeting key indicators specifically.
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 explains the two search modes (by name or ID) and their parameters, but does not explicitly state when to use this tool versus alternatives like browse_categories or search_statistics. No 'when not to use' guidance is provided.
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 full responsibility. It discloses that data_id avoids loading into LLM context and describes the return format. However, it does not confirm read-only behavior, potential side effects, authorization requirements, or rate limits. The behavioral disclosure is adequate but incomplete.
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: a one-sentence purpose, then usage notes, then a clean parameter list with examples. It is reasonably concise but the parameter descriptions could be more succinct (e.g., combining data_id and data_json explanation). Still, it is front-loaded and every sentence adds value.
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 (5 params, output schema exists), the description covers parameters, return format, and an example. It explains the summary vs raw format. However, it does not address error cases (e.g., conflicting data sources, missing parameters) or edge cases like default values for agg_func and format. The output schema reliance is reasonable, but some gaps remain.
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%, so the description must compensate. It lists all parameters with detailed explanations: group_by supports comma-separated values, agg_func includes enumerated options (sum, mean, min, max, count), and explains the trade-off between data_id and data_json. This provides meaningful guidance beyond the bare schema.
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 it aggregates statistics by group, and explains the two data sources (data_id and data_json). However, it does not explicitly differentiate from sibling tools like get_statistics_data or filter_statistics, which may also involve grouping or aggregation. The purpose is clear but lacks sibling differentiation.
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 explicit guidance on when to use data_id (efficient, avoids context pollution) vs data_json, and includes an example. However, it does not specify when to prefer this tool over alternatives like browse_categories or filter_statistics, nor does it mention prerequisites or constraints (e.g., one of data_id or data_json should be provided).
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?
The description discloses that the tool returns a result or error, and that args mismatch leads to an error. However, it doesn't warn about potential side effects of calling arbitrary tools (destructive actions), which is a notable gap given its role as an escape hatch.
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 front-loaded with the purpose. It could be slightly more structured (e.g., bullet points), but it efficiently conveys key information in a few sentences.
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?
The tool has a moderate complexity as a meta-tool. The description explains the return format and error behavior, but lacks details on handling invalid tool names or other error scenarios. Given that it can call any tool, more safety-related context 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?
With 0% schema description coverage, the description compensates well by explaining that 'name' comes from discover_tools() and 'args' are keyword arguments. It also describes the return format, adding 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 it invokes any registered tool by name, identifying it as a 'power user escape hatch'. This distinguishes it from sibling tools, which are specific data retrieval tools.
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 clear context: it's for advanced users, and suggests using discover_tools() to get valid tool names. Though it doesn't list when not to use it, the context is sufficient for an experienced agent.
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 fully covers behavior: extraction of numbers, relative error comparison, return of match status. It also notes accuracy impact when table_id is omitted. No contradictory information.
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 summary, then Args and Returns sections. It is efficient but slightly verbose with the code-style blocks. Front-loaded with 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?
The description covers inputs, process, and output fields (VerifyResult). It mentions the accuracy trade-off for table_id. Output fields are described, compensating for lack of output schema in context.
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 0%, but the description explains each parameter: claim (the statement), table_id (optional, format, accuracy impact), tolerance (default 0.01). Adds meaning beyond 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 verifies numeric claims against KOSIS data, specifying the action (verify) and resource (KOSIS). It distinguishes from sibling tools like search_statistics or browse_categories by focusing on verification of claims.
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 explains the tool is used to verify claims with numbers, time, region, and indicator. It gives context about the extraction process but does not explicitly state when not to use it or provide direct comparisons to sibling tools.
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 provides moderate transparency: it reveals the return format (dict with keys: exposed, internal, total, exposed_count) and the V1_EXPOSED distinction, but lacks details on side effects, rate limits, or authentication.
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 and a return line. The purpose is front-loaded, and every sentence is informative with no wasted words.
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 parameters, no annotations, and the presence of an output description, the description is fairly complete. It covers purpose, alternative tool, and return keys, though it could mention if the listing is paginated or limited in any way.
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?
No parameters exist (0 params), so baseline is 4. The description adds no param info (none needed), and the empty schema fully covers what's expected.
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 lists exposed and internal tools, using specific verbs ('조회' meaning view/list), and directly distinguishes from sibling execute_tool by explaining how internal tools can be called.
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 get the full list) and mentions the alternative execute_tool for calling internal tools, but does not explicitly state when not to use this tool.
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 that data_id reads stored data without including it in context, and returns a JSON string (with optional summary). No annotations exist, so description carries the burden; it adequately discloses the tool's read-only, filtering nature.
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 Args section and example. Slightly verbose but each sentence adds value. Could be more concise, but effective.
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 both data sources, all parameters, return format, and an example. Missing details on error handling or edge cases, but sufficient for a filtering tool with output schema.
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: regions, periods, items, format (enumeration of 'summary'/'raw'), data_id (source), and data_json (alternative source). Examples clarify usage.
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 filters statistics data and explains two modes (data_id vs data_json). It does not explicitly differentiate from sibling tools like search_statistics or aggregate_statistics, but the purpose is clear.
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 guidance on when to use data_id (efficient, avoids LLM context) vs data_json. Includes an example. However, lacks comparison with alternative sibling tools for filtering or searching.
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 implies a read-only metadata query (no destructive actions) but does not explicitly state behavior such as idempotency, authentication requirements, or rate limits. The example and return structure give some transparency, but the lack of explicit behavioral disclosure prevents a higher score.
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 relatively compact, with a clear front-loaded purpose sentence followed by usage context, specific parameter explanations, and an example. The return structure is detailed but relevant. It could be slightly more concise by omitting the explicit return JSON if the output schema is sufficient, but it still earns its place.
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 lack of annotations and the presence of an output schema, the description covers the essential aspects: purpose, usage context, parameters, return values, and an example. It does not address error cases or limitations, but for a metadata query tool with an output schema, 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, but the tool description's Args section fully explains both parameters: org_id as '기관 ID (예: "101")' and tbl_id as '테이블 ID (예: "DT_1B040A3")'. This provides clear semantics beyond the schema, satisfying the need for parameter 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?
The description clearly states '통계표의 메타데이터(구조 정보)를 조회합니다' (queries metadata of statistical tables) and elaborates on the specific structural information (분류항목, 항목, 기간 정보). It differentiates from sibling tools like get_statistics_data by focusing on pre-query metadata inspection.
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 explicitly says '데이터 조회 전에 어떤 필터가 가능한지 확인하는 데 유용합니다' (useful for checking available filters before querying data), indicating when to use it. However, it does not explicitly state when not to use or mention alternative tools, so it loses one point.
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 the full burden. It discloses that the tool returns a list with specific fields like data_id, file_path, record_count, and provides a hint for accessing data. It does not mention any destructive behavior or special requirements, which is appropriate for a read-only listing tool.
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 includes a full return example and a hint, which are helpful but slightly redundant (the hint is repeated in the example). It could be more concise without losing clarity, but it is well-structured and front-loaded.
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 no parameters and an existing output schema, the description is complete. It explains the purpose, usage context, and provides an example return value, fully equipping an AI agent to use the tool correctly.
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 zero parameters and 100% schema coverage, but the description adds value by explaining the tool's purpose in the context of get_statistics_data and showing the return structure. Since there are no params, the description is sufficient.
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 '조회합니다' (retrieve) and the resource '저장된 원본 데이터 파일 목록' (list of stored original data files). It distinguishes itself from sibling tools like read_stored_data by indicating that this tool lists files and the other accesses specific data.
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 workflow: large data from get_statistics_data is automatically saved to a file, this tool lists those files, and read_stored_data accesses them. This provides clear context on when to use this tool, though it does not explicitly state when not to use it or mention alternatives.
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 fully discloses behaviors: explains two response formats (summary vs raw), warns about context size for raw, and describes how new_est_prd_cnt limits periods. It does not mention authentication or error handling but is thorough for a read-only data retrieval tool.
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 Args and Returns sections, and front-loaded with purpose. The Returns section is verbose with a full JSON example, which aids clarity but could be trimmed. Overall, it is appropriately sized for a complex tool.
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 (8 parameters, nested output), the description covers all aspects: purpose, prerequisites, parameter details, return formats, and examples. It lacks error handling and edge cases but is otherwise 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?
Schema description coverage is 0%, but the description compensates fully with detailed parameter explanations, including examples, default values, and mapping to KOSIS concepts (e.g., prd_se values, newEstPrdCnt). 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 the verb '조회' (query) and the resource '통계 데이터' (statistical data) from KOSIS. It explicitly distinguishes from sibling tools like search_statistics and get_table_metadata by indicating that this tool retrieves actual data from tables identified by those tools.
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 guides when to use by stating it works after search_statistics or get_table_metadata. It provides examples and parameter details. However, it does not explicitly mention when not to use or alternatives among siblings like filter_statistics or aggregate_statistics.
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 does not explicitly state that the tool is read-only or non-destructive, but the search nature and guidance on sort options give some behavioral context. However, it lacks explicit safety or side-effect disclosure.
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 a clear purpose line, usage advice, parameter list, returns, and examples. Every sentence is useful, and the most important information is front-loaded.
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?
Despite the tool having 4 parameters and an output schema, the description is complete: it explains the return structure, includes a next_step suggestion, and provides examples. It covers all necessary context for correct 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?
Schema coverage is 0%, but the description compensates fully with detailed parameter explanations, examples (e.g., org_id codes, sort options with recommendations), and default values, adding significant 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 it searches KOSIS statistics tables by keyword, with a specific verb and resource. It positions itself as the first tool to use, distinguishing from siblings like browse_categories and search_key_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 explicitly says it is the first tool for finding statistics data and suggests the next step (get_table_metadata). It provides examples but does not explicitly exclude scenarios where alternatives might be preferred.
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 transparently explains the three browsing modes, how 'code' behaves for each, and the return format. It does not mention side effects, authentication, or rate limits, but the tool appears to be a read-only data browser, and the description sets proper expectations.
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 Args, Returns, and Example sections. It front-loads the purpose. Some redundancy (e.g., listing all vwCd values could be condensed), but overall it is efficient and every sentence adds value.
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 moderate complexity (2 params, 3 modes, variable return shape), the description is complete. It covers inputs, examples, and output format. Sibling tools like 'search_statistics' are handled by the purpose distinction. No output schema is provided, but the description offers a clear return structure.
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% (no descriptions in schema), but the description fully documents both parameters. It explains all valid values for 'by' and how 'code' maps to each mode with concrete examples. This adds significant meaning 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 clearly states the tool browses KOSIS statistics lists by institution, theme, or custom view. It specifies the resource ('KOSIS 통계 목록') and the action ('탐색합니다'). This distinguishes it from siblings like 'search_statistics' (search) and 'filter_statistics' (filter), which have 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides detailed guidance on when to use each 'by' value with examples and code explanations. It doesn't explicitly state when not to use or mention alternative tools, but the context is clear enough for an agent to choose correctly.
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 exist, so the description bears full responsibility. It discloses the tool's read-only nature (listing), pagination behavior, and return format. It does not mention authentication or rate limits, but the behavior is straightforward.
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 (8 lines) with clear sections (Args, Returns) and no extraneous content. Every sentence is necessary and 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?
The description covers the main functionality, parameters, and return structure. It lacks clarification on handling null 'value' or defaults, but given the output schema exists and the input schema defines defaults, it is nearly 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 fully compensates by explaining each parameter: 'by' (category/period), 'value' (listId or prdSe), page, and limit, with examples. This adds significant meaning beyond the raw 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 lists KOSIS key indicators by category or period, with specific parameters and endpoints. It distinguishes from sibling tools like search_key_indicators and get_key_indicator by focusing on listing rather than searching or details.
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 (by=category or period) with examples. However, it does not explicitly state when not to use this tool versus alternatives like search_key_indicators or get_key_indicator.
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?
The description discloses chunking behavior, default chunk size, and return format including meta, data, and chunk_info. It mentions that without chunk_index, all data is returned. No annotations are provided, but the description adequately covers behavioral traits.
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 and well-structured with clear sections (Args, Returns, Example). Every sentence adds value, and the example clarifies usage without redundancy.
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 moderate complexity, the description covers all necessary aspects: parameter explanations, return format with example, and reference to sibling tools for obtaining data_id. It is complete despite missing annotations.
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 0%, so the description compensates by explaining each parameter: data_id source, chunk_index start and optionality, chunk_size default. This adds meaning beyond the schema alone.
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 purpose: '저장된 원본 데이터를 읽습니다' (reads stored original data). It specifies the resource (stored data) and verb (read), and distinguishes from sibling tools that focus on statistics or browsing.
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 the tool (to read stored data, with chunking for large data) and provides examples. It does not explicitly state when not to use or compare to alternatives, but the context 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 are provided, so the description carries full burden. It discloses that the tool reads data and returns a list of values with count and example. It does not describe error handling for invalid inputs, but the read-only nature is clear.
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, front-loaded with the purpose, and structured with Args and Returns sections. Every sentence adds value, and an example is included without unnecessary repetition.
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 (2 parameters, no nested objects), the description fully covers purpose, parameter details, return format, and an example. It is complete 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?
Schema description coverage is 0%, but the description adds extensive meaning for both parameters: data_json is described as a KOSIS data JSON string from get_statistics_data, and field is explained with examples and field descriptions for common 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 available values for a specific field from data, with a specific verb (조회) and resource (available values). It distinguishes itself from siblings like filter_statistics by stating it's used to check filtering options.
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 explicitly says to use this tool when checking filtering options or deciding filter values. It provides an example, but does not explicitly mention when not to use it or name alternatives.
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?
No annotations are provided, so the description carries full burden. It transparently discloses the tool's behavior: it is a retrieval operation (조회), explains the two internal services used, parameter mapping, and return structure. No contradictions or hidden behaviors.
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 Korean overview, parameter details, return format, and an example. Every sentence adds value, and it is concise without redundancy.
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 has 4 parameters, no annotations, and an output schema, the description fully covers usage, parameter semantics, return structure, and provides an example. It is complete and self-contained.
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 fully explains each parameter: 'by' values and their meaning, 'value' dependency on 'by', and defaults for 'page' and 'limit'. 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 the tool retrieves explanation data of KOSIS Key Indicator and specifies two sub-services based on the 'by' parameter. It distinguishes itself from siblings like list_key_indicators, search_key_indicators, and get_key_indicator_details by focusing on explanation retrieval with ID or name lookup.
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 'by' parameter with values 'id' or 'name' and provides examples. However, it does not explicitly state when not to use this tool or mention alternatives like search_key_indicators for broader queries.
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:

[![korean-stat-mcp MCP server](https://glama.ai/mcp/servers/seolcoding/korean-stat-mcp/badges/card.svg)](https://glama.ai/mcp/servers/seolcoding/korean-stat-mcp)

Score Badge

Copy to your README.md:

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

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