Korea Public Data Catalog MCP

Overview Schema Related Servers Score Discussions

Server Quality Checklist

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

Latest release: v0.4.0-beta.1
Disambiguation4/5
Most tools have clearly distinct purposes: searching, retrieving details, recommending combinations, designing products, and checking feasibility. However, list_public_data_sources and get_inventory_coverage_status both report on catalog scope and row counts, which could cause confusion for an agent deciding which to call.
Naming Consistency5/5
All tool names follow a consistent verb_noun snake_case pattern (list_, search_, get_, recommend_, design_, check_). The verbs are specific and the naming style is uniform throughout.
Tool Count5/5
Seven tools is well-scoped for a catalog server that covers inventory listing, search, details, recommendation, design, feasibility, and status. Each tool contributes to a coherent workflow without unnecessary bloat.
Completeness4/5
The toolset covers the core lifecycle of exploring and planning public data combinations: inventory awareness, search, details, recommendation, product design, and feasibility checks. Minor gaps exist, such as no explicit way to browse all datasets or compare two datasets directly, but these do not block primary workflows.
Average 4/5 across 7 of 7 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 5 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

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is known. The description adds valuable context by clarifying that it draws from a static list and does not query live data, giving the agent a clear mental model of the tool's behavior beyond the annotations. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured Korean sentence that states the core function and a critical limitation, with no redundancy or filler. It is front-loaded with the primary action and includes an important boundary in the same sentence.
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?
With five parameters and no output schema, the description should explain how inputs influence the result and what the reference design proposal looks like. It mentions the content areas (product composition, data flow, verification procedures, expected outputs) but gives no details on parameter usage or output format, leaving significant gaps for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema lists five parameters (goal, limit, regions, data_needs, desired_outputs) with 0% description coverage. The description makes no mention of any parameter, leaving the agent without any guidance on what values to provide or how the parameters shape the design. The description fails to compensate for the lack of schema 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 the tool creates a reference design proposal for product composition, data flow, verification procedures, and expected outputs, based on a static list of data types and official providers. The verb '만듭니다' (creates) is specific, and the resource is clearly '공공데이터 서비스·제품 설계' (public data service/product design). This distinguishes it from sibling tools that list, search, or recommend data combinations.
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 design tasks rather than actual data retrieval, especially with the note '실제 데이터는 조회하지 않습니다' (doesn't query actual data). However, it does not explicitly mention alternatives or state when to use this tool over others, leaving the guidance implicit rather than explicit.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable behavioral context by stating it does not call or combine raw data, reinforcing that it is a metadata-only check. This goes beyond the annotations by clarifying the tool's non-execution nature.
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 concise sentence that front-loads the primary action and adds a clarifying exclusion. Every clause contributes meaning without 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?
The tool is simple (2 params, no output schema) and the description covers the core function and non-execution behavior. However, it lacks parameter semantics for 'regions' and provides no details about output or return values. It is minimally viable but has clear gaps for an agent's full understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters. It mentions '카탈로그 ID' (catalog ID) which maps to dataset_ids, but does not explain the 'regions' parameter or how it is used. The description only indirectly references 지역 (region) as a check item, leaving the regions parameter semantically unclear.
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 checks whether selected catalog IDs exist and organizes items to verify on the official page (schema, region, auth, join keys). It uses a specific verb (확인, 정리) and distinct resource (catalog IDs). It also explicitly excludes calling or combining raw data, distinguishing it from sibling tools like recommend_data_combination or design_public_data_product.
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 as a preliminary feasibility check before combining data, and notes it does not execute raw data calls or joins. However, it does not explicitly state when to use this tool versus alternatives, nor does it mention cases where it should not be used. No alternatives or exclusions are named.
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 adds meaningful behavioral context beyond the read-only/idempotent annotations: it specifies the snapshot date (2026-06-30), that the source is a fixed local list, that it does not access external APIs or raw data, and that license indications are merely metadata for verification. This helps set accurate expectations about data freshness and limitations.
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: the first states the action and scope, the second clarifies limitations. It is front-loaded and every sentence adds value without redundancy or excessive detail.
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 has 14 parameters and no output schema, the description gives enough high-level context for an agent to know what the tool does and its limitations, but it does not cover parameter semantics, result structure, or pagination behavior. It is adequate for selection but lacks depth for confident invocation without relying on parameter names alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the 14 parameters. It mentions searchable fields (name, agency, classification, format, keyword) but does not map them to schema properties like 'query', 'providers', 'formats', or 'classifications', nor does it clarify how array filters or booleans (e.g., 'include_non_data') behave. The description provides minimal compensation 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?
The description clearly states the tool's function: searching a local static list for metadata fields like name, agency, classification, format, and keyword, plus official link candidates. It uses a specific verb ('검색합니다') and resource, and its scope is delineated from sibling tools that list, fetch details, or recommend combinations.
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 the tool is for searching metadata and distinguishes itself by noting it does not query raw values or external APIs, but it does not explicitly state when to prefer this over sibling tools or when not to use it. No alternatives are named, so usage guidance is only implicit.
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?
Beyond the annotations (read-only, idempotent), the description discloses valuable behavioral traits: it operates only on local data without external network access, and it explicitly cautions about row count discrepancies (96,056 vs 87,581), preventing misinterpretation of national totals. This is rich contextual transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences, front-loaded with the primary purpose, followed by a data quality caveat and a scope clarification. Every sentence adds substantive value without redundancy, achieving a high signal-to-noise ratio.
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 provides important context about local-only operation and data limitations, but with 7 undocumented parameters and no output schema, it leaves the agent short of understanding how to construct queries or interpret results. It is a minimally viable description for a list tool, but gaps remain in parameter and return-value coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any of the 7 parameters (limit, offset, query, enabled, etc.). It mentions 'reference date and row count ranges' but fails to connect these to specific parameters or provide filter guidance, leaving the agent without adequate parameter meaning.
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 action (retrieve/list), resource (static metadata sources), and scope (local runtime only, not external portals). It explicitly says 'does not access external portals,' distinguishing it from sibling tools like search_public_datasets.
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 for when to use the tool: when needing local static metadata sources and their reference date/row count ranges. It notes it does not access external portals, implying a boundary, but does not explicitly name alternative tools or state when not to use this one.
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?
Beyond the readOnly and idempotent annotations, the description adds important behavioral context: it operates on a static list and does not actually fetch, process, or combine data; those steps are left to the user after checking official pages. This boundary-setting is valuable.
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, front-loaded with the core action and followed by a scope clarification. Every sentence carries necessary information with no redundancies.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only recommendation tool, it covers the main workflow and output (data types, institutions, links), but lacks details on optional parameters and result ranking/format. Given the absence of an output schema, more could be added, but it is largely sufficient.
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?
With 0% schema description coverage, the description only partially compensates. It explains that the goal is broken into data needs, which relates to 'goal' and 'data_needs', but it does not describe 'limit' or 'regions' parameters or their formats.
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 decomposes a service/analysis goal into data needs and recommends relevant public data types, institutions, and official verification links from the entire static list. This specific verb+resource+scope distinguishes it from sibling tools like search_public_datasets or list_public_data_sources.
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?
It provides a clear usage context: when the user has a desired service/analysis and wants to identify relevant public data. However, it does not explicitly mention alternatives or when not to use this tool, which would make it a 5.
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 goes beyond annotations by noting that the numbers are a static snapshot, not the current total of all public data in South Korea. It also mentions 'current runtime channel', providing useful context about the tool's scope. Annotations already indicate read-only and idempotent behavior, and the description complements them without contradiction.
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 and front-loaded with the action ('returns') and the specific items returned. The second sentence adds an important caveat, keeping it concise without unnecessary detail. Every word contributes 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 simplicity (zero parameters, no output schema), the description adequately lists all return values and their semantic meaning. The snapshot caveat adds necessary context about data freshness, making the tool's output interpretable without further documentation.
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 tool takes no parameters, so parameter semantics are trivially satisfied. The description does not need to explain parameters, and the empty input schema is fully consistent. The baseline score of 4 applies given the absence of parameters.
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 what the tool does: it returns specific inventory coverage metrics (runtime channel, base date, row counts, differences, type counts). The verb '반환합니다' (returns) and the explicit list of returned data make the purpose unambiguous and distinct from sibling tools that list or search datasets.
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 checking coverage status but does not explicitly state when to use this tool versus alternatives like 'search_public_datasets' or 'list_public_data_sources'. There is no mention of exclusions or alternative tools, so guidance is only implicit via the scope of the returned data.
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 annotations already declare the read-only, idempotent, non-destructive nature. The description adds behavioral context by listing exactly which fields are returned and which are omitted (source description, fields, contact info, actual values, join keys). This goes beyond annotations by clarifying the tool's scope.
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 short sentences. The first sentence lists the returned fields, the second states exclusions. Every word is information-dense with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple detail-retrieval tool with one parameter and no output schema, the description covers the purpose, the data returned, and the exclusions. It could have mentioned that the ID must originate from `search_public_datasets`, but it is strongly implied. Given the tool's simplicity, this is sufficiently 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?
The schema only provides the parameter name (`dataset_id`) and type/length constraints. The description adds crucial semantic meaning by identifying it as a 'search result ID', clarifying that it must come from a previous search operation. This fully compensates 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 uses the specific verb '조회합니다' (retrieves) and enumerates the exact data fields returned (data type, institution, classification, format, update cycle, keywords, official link). It also explicitly states what is not included, which helps differentiate it from tools that return full dataset content. This makes the purpose unambiguous and distinguishes it from sibling tools like search_public_datasets.
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 phrase '검색 결과 ID로' indicates that this tool is intended for use after obtaining an ID from a search result, providing clear context for when to call it. However, it does not explicitly name alternative tools or state exclusions (e.g., 'use this instead of X'). The condition is implied, not fully explicit.
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

korea-public-data-catalog-mcp MCP server

Copy to your README.md:

[![korea-public-data-catalog-mcp MCP server](https://glama.ai/mcp/servers/obundh/korea-public-data-catalog-mcp/badges/card.svg)](https://glama.ai/mcp/servers/obundh/korea-public-data-catalog-mcp)

Score Badge

Copy to your README.md:

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

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