Korea Stats MCP

Server Quality Checklist

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

Latest release: v1.1.0
Disambiguation4/5
Tools have distinct purposes with detailed usage hints, but quick_stats and get_statistics_data both return data and could cause minor confusion. Overall, agents can differentiate well.
Naming Consistency4/5
Most names follow verb_noun pattern (get_statistics_data, analyze_time_series), but quick_stats and quick_trend break the pattern with 'quick' as prefix, slightly reducing consistency.
Tool Count5/5
8 tools is ideal for a statistics server, covering listing, searching, data retrieval, comparison, and trend analysis without being overwhelming.
Completeness3/5
Core CRUD-like operations are present but missing get_table_info, which is referenced as a prerequisite. This gap forces agents to work around missing metadata retrieval.
Average 3.6/5 across 8 of 8 tools scored. Lowest: 2.8/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed 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

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 only states the tool compares data, without indicating whether it is read-only, requires specific permissions, or has any side effects. For an 8-parameter tool, more transparency is needed (e.g., whether data is aggregated, if results are paginated).
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 a single sentence, which is concise but lacks structure. It is front-loaded with the core action, but the brevity may leave the agent without enough context to select or invoke the tool correctly. It earns its place but could be slightly more informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 8 parameters, two enums, no output schema, and no annotations, the description is insufficient. It does not hint at return values, error states, or usage patterns (e.g., whether regions are specified via parameters). The agent needs more context to use this tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add additional meaning beyond the schema; it simply restates the tool's purpose. Since the schema already explains parameters adequately, this score is appropriate.
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 compares statistical data across multiple regions, time points, or items, providing a specific verb and resource. It distinguishes from siblings like search_statistics (which implies searching) and get_statistics_data (which implies retrieving raw data). However, it does not explicitly mention the comparison types (period/item) available in the schema.
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 versus alternatives. The description does not state when-not to use it, nor does it mention any prerequisites or fallback tools. Given the sibling tools include analyze_time_series and quick_stats, comparative context is missing.
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?
With no annotations, the description bears full responsibility for disclosing behavioral traits. It states 'recommends', indicating a read operation, but omits details about authentication, rate limits, or any potential side effects. There is no mention of what the recommendation algorithm considers or how results are ordered.
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 a single sentence with no wasted words. It is front-loaded with the key action and resource, making it easy to parse. Every word contributes to the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the basic purpose but lacks information about return format, pagination, or how recommendations are generated. Given no output schema, the description could be more helpful by indicating what kind of data (e.g., table IDs, names) will be in the response. However, for a simple recommendation tool, it is minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (both parameters have descriptions in the schema). The tool description does not add any extra meaning beyond the schema, which already explains the 'topic' enum and 'limit' default/range. Baseline score of 3 is appropriate.
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 verb '추천합니다' (recommends) and resource '주요 통계표' (key statistical tables) with the context of '관심 분야에 맞는' (according to area of interest). It implies filtering by topic but does not explicitly differentiate from sibling tools like 'search_statistics' or 'get_statistics_list', which could also provide topic-based results.
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 implies usage when you need recommendations based on a selected topic, but it does not mention exclusions or compare with siblings such as 'quick_stats' or 'compare_statistics'.
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?
With no annotations provided, the description carries full burden for behavioral traits. It does not disclose whether the operation is read-only, what the output format is, or any side effects, limiting transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with examples, highly concise and front-loaded with the core function.
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 no output schema, the description lacks information about return values or how results are structured. For a search tool, this leaves room for ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters, and the description does not add new information beyond the schema descriptions. Baseline of 3 is appropriate.
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 statistical tables by keyword and provides concrete examples like '인구' and 'GDP', distinguishing it from sibling tools that perform more specialized operations.
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 by giving examples of keywords, but does not explicitly state when to use this tool versus alternatives like analyze_time_series or compare_statistics.
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 carries the full burden. It states the tool calculates trends and growth rates but does not disclose whether it is read-only, what happens on invalid input, rate limits, or other behavioral traits. This lack of transparency is a significant gap for a computation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (three sentences) and front-loaded: first sentence states purpose, second lists outputs, third provides critical usage note. Every sentence adds value, with no redundancy or 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?
Given the tool's complexity (7 parameters, no output schema), the description provides essential prerequisite guidance but lacks details on return format, data interpretation, or constraints. It is minimally viable but leaves gaps for an agent to understand expected outputs fully.
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 100% coverage for parameter descriptions. The description adds value by explicitly linking objL1 and itemId to get_table_info for validation, providing additional semantic context beyond the schema. This justifies a score above the baseline of 3.
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 specifies that the tool analyzes time series trends and calculates growth rates. It provides a specific verb ('analyze') and resource ('time series of statistical data'). However, it does not explicitly differentiate from sibling tools like quick_trend, which may perform similar functions.
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 includes an important prerequisite: to first use get_table_info to validate objL1, objL2, and itemId. This provides clear context and a precondition. However, no guidance is given on when to choose this tool over alternatives like compare_statistics or quick_stats.
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 cover behavioral traits. It only says 'queries actual data,' implying a read operation, but lacks details on error handling, rate limits, or response format. Adequate but not thorough.
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 consists of two concise sentences. The first states the purpose, and the second provides a critical usage note. No extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (11 parameters, no output schema, no annotations), the description provides the core purpose and a key prerequisite. However, it does not explain the output format, pagination (if any), or how this tool differs from analysis siblings. Adequate but could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes all 11 parameters with 100% coverage. The description adds the note about get_table_info for objL1 and itemId, which is also present in the schema descriptions. Therefore, the description adds minimal additional semantic value beyond the 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 the tool queries actual data of a specific statistics table (specific verb+resource). However, it does not explicitly differentiate from sibling tools like analyze_time_series or compare_statistics, which may also retrieve 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 provides an explicit prerequisite: first obtain valid objL1 and itemId values from get_table_info. This guides correct usage but does not specify when not to use this tool or mention 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 provided, so the description carries full burden. It discloses the return format (10 years data, change rate, highest/lowest points, trend summary) and keyword extraction rules. However, it lacks details on data source, rate limits, or any side effects.
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 uses bullet points and clear sections (usage time, return format, keyword tips). It is front-loaded with purpose. However, it is slightly verbose with Korean examples and could be more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters, 1 required, no output schema, and no annotations, the description covers purpose, usage guidance, return format, and parameter semantics. It does not explain return values in detail, but the summary is sufficient for a simple trend analysis 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?
Schema description coverage is 100%, baseline 3. The description adds value by providing examples of what to put in 'keyword' (e.g., '인구', '출산율') and explaining that trend-related words should be removed. It also clarifies the 'region' parameter's optionality.
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 the tool analyzes time series trends for questions about trends, changes, increases, decreases (e.g., "~추세", "~변화"). It uses specific verbs and resources, but does not explicitly differentiate from sibling tools like analyze_time_series.
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 the tool: when the question involves trend/changes in Korean keywords. It gives examples of keyword extraction, but does not mention when not to use it or point to 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 tree structure navigation but lacks details on authentication, rate limits, or behavior with invalid IDs. It adequately describes the browsing behavior but is not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the main action, and contains no redundant or extraneous information. Every sentence contributes to understanding the tool's functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description could explain return format or navigation details (e.g., pagination, depth). It mentions tree structure but not how to traverse deeper levels. It is adequate for a straightforward list tool but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the schema already documents the parameters. The description adds value by explaining the default behavior for empty parentId and listing the specific viewCode values with their meanings, enriching the parameter semantics.
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 uses specific verbs ('탐색합니다' meaning 'explore') and resources ('통계 목록' meaning 'statistics list'), and mentions tree structure navigation. It clearly distinguishes from sibling tools like search_statistics (searching) and analyze_time_series (analysis) by focusing on browsing and hierarchical exploration.
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 browsing statistics by topic or institution, but it does not explicitly state when to use this tool versus alternatives like search_statistics or quick_stats. No exclusions or usage hints are 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 must cover behavioral traits fully. It discloses the result format ('2024년 서울의 실업률은 3.2%입니다') and supported data types, but does not mention error handling, rate limits, or side effects. While sufficient for a read-only tool, it 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections, bullet points, and examples, making it easy to scan. However, it is slightly verbose, containing redundant clarifications (e.g., repeated emphasis on keyword extraction). Overall, it earns its length but could be more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the six parameters, no output schema, and seven sibling tools, the description is very complete. It covers query construction, region handling, time periods, and provides a sample output. It lacks detailed return field documentation, but the example output compensates. The agent has enough context to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed parameter descriptions, but the description adds substantial meaning beyond the schema: it explains keyword extraction rules (e.g., dropping 감소/증가), enumerates supported keywords (90+), lists 17 regions, and provides usage examples for compound queries. This significantly aids correct parameter selection.
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 '한국 통계 수치를 즉시 반환합니다' (returns Korean statistical figures immediately), which is a specific verb+resource. It also distinguishes itself from siblings like analyze_time_series, compare_statistics, etc., by focusing on quick retrieval of static values rather than analysis or comparison.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit triggers (e.g., '~얼마야?', '~알려줘') and gives rules for extracting keywords (e.g., removing modifiers like 감소/증가). It includes multiple examples showing when to use the tool and how to format queries, making it clear for the agent.
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:

[![korea-stats-mcp MCP server](https://glama.ai/mcp/servers/Dayoooun/korea-stats-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Dayoooun/korea-stats-mcp)

Score Badge

Copy to your README.md:

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

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