Which integrations are available for this server?

Provides access to Naver web data, allowing users to search for news articles and retrieve detailed information and reviews for locations via Naver Places and Naver Maps.

korean-data-mcp

by leadbrain

Overview Schema Related Servers Score Discussions

Python

Remote

🇰🇷 Korean Data MCP

Real-time Korean web data for AI assistants — powered by Apify actors.

PyPI License: MIT MCP

A Model Context Protocol (MCP) server that gives Claude, Cursor, and other AI tools direct access to live Korean web data — including Naver reviews, Melon music charts, Daangn/Bunjang marketplace listings, Korean news, and Musinsa fashion rankings.

🛠 Available Tools

Tool	Description
`get_naver_place_reviews`	Fetch reviews for any Naver Place (restaurant, cafe, shop, etc.)
`get_melon_chart`	Real-time / daily / weekly Korean music chart (실시간 차트)
`search_daangn`	Search Daangn Market (당근마켓) C2C listings
`search_bunjang`	Search Bunjang (번개장터) marketplace
`search_naver_news`	Search Naver News articles by keyword
`search_naver_places`	Search Naver Map places by keyword + location
`get_musinsa_ranking`	Musinsa fashion ranking by category

Related MCP server: Web Intelligence MCP Server

🚀 Quick Start

1. Get an Apify API Token

2. Install

pip install korean-data-mcp

Or with uv (recommended):

uv add korean-data-mcp

3. Set Environment Variable

export APIFY_TOKEN="your_apify_token_here"

4. Run the MCP Server

korean-data-mcp

⚙️ Claude Desktop Configuration

Add to ~/Library/Application Support/Claude/claude_desktop_config.json:

{
  "mcpServers": {
    "korean-data": {
      "command": "korean-data-mcp",
      "env": {
        "APIFY_TOKEN": "your_apify_token_here"
      }
    }
  }
}

Or with uvx (no install needed):

{
  "mcpServers": {
    "korean-data": {
      "command": "uvx",
      "args": ["korean-data-mcp"],
      "env": {
        "APIFY_TOKEN": "your_apify_token_here"
      }
    }
  }
}

💬 Usage Examples

Once connected to Claude Desktop or another MCP client:

"What are the top 10 songs on Melon chart right now?"

"Find cafes near Hongdae on Naver Map and show their reviews."

"Search Daangn for iPhone 15 Pro listings in Seoul."

"What are the trending news stories on Naver today about 인공지능?"

"Show me the Musinsa top 50 outer clothing items."

🔧 Cursor / VS Code Configuration

Add to .cursor/mcp.json or .vscode/mcp.json:

{
  "servers": {
    "korean-data": {
      "type": "stdio",
      "command": "korean-data-mcp",
      "env": {
        "APIFY_TOKEN": "your_apify_token_here"
      }
    }
  }
}

📊 Data Sources

All data is fetched live via Apify actors:

Actor	Apify Store
Naver Place Reviews	oxygenated_quagmire/naver-place-reviews
Melon Chart	oxygenated_quagmire/melon-chart-scraper
Daangn Market	oxygenated_quagmire/daangn-market-scraper
Bunjang Market	oxygenated_quagmire/bunjang-market-scraper
Naver News	oxygenated_quagmire/naver-news-scraper
Naver Place Search	oxygenated_quagmire/naver-place-search
Musinsa Ranking	oxygenated_quagmire/musinsa-ranking-scraper

💰 Pricing

Apify Free Tier: $5/month credit — enough for ~1,000–5,000 tool calls
Actor runs are billed per 1,000 items returned ($0.50/1K items)
No additional cost for this MCP server itself

🏗 Development

git clone https://github.com/leadbrain/korean-data-mcp
cd korean-data-mcp
pip install -e ".[dev]"
export APIFY_TOKEN="your_token"
python -m korean_data_mcp.server

📄 License

MIT License — see LICENSE

🤝 Contributing

Issues and PRs welcome at github.com/leadbrain/korean-data-mcp

Built on FastMCP · Data from Apify

Available Tools

7 tools

get_melon_chartB

Fetch the Melon music chart (멜론 차트).

ParametersJSON Schema

Name	Required	Description	Default
`chart_type`	No	Chart to fetch — 'realtime' (실시간), 'hot100', 'daily', or 'weekly'	realtime
`limit`	No	Number of songs to return (default 100, max 100)

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.2/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must carry the full burden. It merely states 'Fetch' without disclosing behavioral traits such as rate limits, authentication requirements, or pagination behavior. The output schema exists but does not compensate for lack of operational context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence with no wasted words. It is concise and front-loaded with the essential verb and resource, though it could be slightly more informative without losing conciseness.

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 simplicity (2 optional parameters, output schema exists), the description is minimally adequate but could be improved by mentioning the output format or typical use cases. It does not cover edge cases or error conditions.

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 schema already explains both parameters. The description does not add additional meaning beyond what the schema provides, resulting in a baseline score 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 uses a clear verb 'Fetch' and specifies the resource 'Melon music chart', which distinguishes it from sibling tools focused on shopping, reviews, and news. However, it does not explicitly differentiate from potential similar chart tools on other servers.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool versus alternatives. Since sibling tools are from different domains, usage context is implied but not stated. No exclusion criteria or prerequisites are mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_musinsa_rankingA

Fetch Musinsa (무신사) fashion ranking — Korea's leading fashion platform.

ParametersJSON Schema

Name	Required	Description	Default
`category`	No	Category slug, e.g. 'all', 'outer', 'top', 'bottom', 'shoes', 'bag'	all
`max_items`	No	Maximum number of items to return (default 50, max 100)

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.6/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must disclose behaviors like rate limits, data freshness, or authentication needs. It only states 'fetch ranking' without any such details, leaving the agent unaware of potential constraints.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence with no wasted words. It front-loads the key purpose and provides enough context for a simple fetch 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 output schema exists and the tool is straightforward, the description is largely complete. However, briefly mentioning the category or max_items parameters could enhance completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% coverage with clear parameter descriptions. The description adds no extra meaning beyond the schema, so a baseline score 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 the verb 'Fetch' and the resource 'Musinsa fashion ranking', immediately conveying the tool's function. It differentiates well from sibling tools which target other platforms like Melon or Naver.

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 fetching Musinsa ranking but provides no explicit guidance on when to use it versus alternatives, nor any context about prerequisites or typical use cases.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_naver_place_reviewsA

Fetch reviews for a Naver Place (네이버 플레이스) listing.

ParametersJSON Schema

Name	Required	Description	Default
`place_url`	Yes	Naver Place URL, e.g. https://map.naver.com/v5/entry/place/1234567890
`max_reviews`	No	Maximum number of reviews to return (default 20, max 100)

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.7/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden for behavioral disclosure. It only says 'Fetch reviews' with no mention of authentication, rate limits, or side effects. The read-only nature is implied but not explicit, and no constraints are communicated.

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 of 8 words, front-loaded with the core action. Every word earns its place, making it highly efficient and easy to parse. No verbose or redundant 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?

With an output schema present, return values are covered elsewhere. However, the description lacks context on prerequisites (e.g. valid URL format) and any usage limitations. It is minimally adequate but could benefit from additional context like required authentication or scope.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with both parameters described in the input schema. The description adds no additional meaning beyond what the schema already provides. Baseline score of 3 is appropriate as the schema does the heavy lifting.

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 fetches reviews for a Naver Place, using a specific verb 'Fetch' and resource 'reviews for a Naver Place'. It effectively distinguishes from sibling tools which focus on other services like music charts or search for other platforms.

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 that the tool is for fetching Naver Place reviews, implying usage when reviews are needed. No exclusions or alternatives are explicitly stated, but the sibling tools are distinct enough that confusion is unlikely.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_bunjangB

Search Bunjang (번개장터) — Korea's largest C2C marketplace.

ParametersJSON Schema

Name	Required	Description	Default
`keyword`	Yes	Search keyword in Korean or English
`max_items`	No	Maximum number of listings to return (default 30, max 100)
`sort`	No	Sort order — 'recent' (최신순) or 'popular' (인기순)	recent

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.1/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided; the description only states the tool searches a marketplace. No disclosure of side effects, authentication needs, or rate limits. The read-only nature is implied but not explicit.

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?

A single sentence that is efficient and direct. No wasted words, though it could benefit from more structure or detail.

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?

Despite having a complete input schema and output schema, the description lacks usage guidance and behavioral context. For a tool with siblings, it is insufficiently complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so all parameters have descriptions. The tool description adds no additional semantic value beyond what the schema already provides, resulting in a baseline score.

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 searches Bunjang, Korea's largest C2C marketplace, with a specific verb and resource. Among siblings like search_daangn, it is distinguished by naming the exact platform.

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 sibling search tools (search_daangn, search_naver_news, etc.). No explicit context for choosing this tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_daangnB

Search Daangn Market (당근마켓) listings.

ParametersJSON Schema

Name	Required	Description
`keyword`	Yes	Search keyword in Korean or English
`region`	No	Optional region filter (e.g. '서울', '강남구')
`max_items`	No	Maximum number of listings to return (default 30, max 100)

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.2/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description bears full responsibility for behavioral disclosure. It only states 'Search listings' with no mention of pagination, 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single sentence that is direct and contains no superfluous information. Efficient communication.

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?

Despite having an output schema, the description fails to provide context about the tool's scope, behavior, or what constitutes a listing. It is too minimal for a complex search tool.

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 description covers 100% of parameters, so the description adds no extra value. According to guidelines, baseline 3 is appropriate when schema coverage is high.

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 identifies the action ('Search') and the specific resource ('Daangn Market listings'), distinguishing it from sibling tools like search_bunjang which targets a different marketplace.

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 such as search_bunjang or search_naver_places. The description lacks context for selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_naver_newsC

Search Naver News (네이버 뉴스) for Korean news articles.

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	Search query in Korean or English
`max_articles`	No	Maximum number of articles to return (default 20, max 100)
`sort`	No	Sort order — 'date' (최신순) or 'sim' (관련도순)	date

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It only states it 'searches' but does not mention whether it is read-only, any authentication requirements, rate limits, or what happens on error or empty results. The input schema adds some detail (sort, max_articles) but the description adds no behavioral context beyond the action.

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 a single sentence with no wasted words. It is front-loaded with the key action and resource. However, it is very brief and could benefit from a second sentence adding context (e.g., language scope) without being verbose.

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 3 parameters, no annotations, and an output schema (assumed defined), the description is too minimal. It lacks usage guidance, output format hints, and behavioral disclosures. While the schema covers parameters, the description does not integrate with the tool's operational context (e.g., when to use this vs other search tools).

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 has 100% description coverage, so parameters are already documented (query in Korean/English, max_articles range, sort options). The description adds no additional meaning beyond the schema. Baseline score of 3 is appropriate as the schema does the heavy lifting.

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 searches Naver News for Korean news articles. It distinguishes from sibling tools like search_bunjang (marketplace) and search_naver_places (places) by specifying the news domain. However, it could be more specific about the scope (e.g., only Korean-language articles) which is implied but not explicit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives like search_bunjang or search_daangn. There are no exclusions, prerequisites, or context about typical use cases. Agents are left to infer from the name and sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_naver_placesB

Search Naver Map (네이버 지도) places by keyword.

ParametersJSON Schema

Name	Required	Description
`keyword`	Yes	Place type or name, e.g. '카페', '맛집', 'cafe'
`location`	No	Location context, e.g. '홍대', '강남역', 'Itaewon'
`max_places`	No	Maximum number of places to return (default 20, max 100)

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden of behavioral disclosure, but it only states 'Search ... by keyword.' It does not mention pagination, result limits beyond the max_places parameter, authentication requirements, regional restrictions, or the format of returned data. This is insufficient for a search tool that may have specific behaviors.

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 that is short and front-loaded, but it omits important details like output format or usage context. While concise, it sacrifices informativeness, making it mediocre for a tool with no annotations.

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?

Although an output schema exists (not shown), the description does not hint at what the tool returns (e.g., a list of places with details). Combined with no annotations and minimal behavioral info, the description is incomplete for the tool's complexity. A more complete description would mention that it returns search results and possibly the structure.

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?

Input schema coverage is 100%, with clear descriptions for each parameter (e.g., examples for keyword and location, and limits for max_places). The tool description itself adds no additional parameter semantics beyond what the schema provides. Baseline score of 3 is appropriate as the schema already documents the parameters well.

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 searches Naver Map places by keyword, using a specific verb 'Search' and resource 'Naver Map (네이버 지도) places'. Among sibling tools, it is distinct as the only one focused on map place search, while others target music, fashion, reviews, or second-hand goods.

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 usage guidelines are provided. The description does not indicate when to use this tool versus alternatives, nor does it mention any prerequisites or exclusions. For example, it does not clarify that this tool is for Korean map data or how it differs from other search tools like search_bunjang or search_naver_news.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

7 tool updatesMay 2, 2026

Changedget_melon_chart2 fields changed

addedInput schema / properties / chart_type / description

Added value: +"Chart to fetch — 'realtime' (실시간), 'hot100', 'daily', or 'weekly'"

addedInput schema / properties / limit / description

Added value: +"Number of songs to return (default 100, max 100)"

Changedget_musinsa_ranking2 fields changed

addedInput schema / properties / category / description

Added value: +"Category slug, e.g. 'all', 'outer', 'top', 'bottom', 'shoes', 'bag'"

addedInput schema / properties / max_items / description

Added value: +"Maximum number of items to return (default 50, max 100)"

Changedget_naver_place_reviews2 fields changed

addedInput schema / properties / max_reviews / description

Added value: +"Maximum number of reviews to return (default 20, max 100)"

addedInput schema / properties / place_url / description

Added value: +"Naver Place URL, e.g. https://map.naver.com/v5/entry/place/1234567890"

Changedsearch_bunjang3 fields changed

addedInput schema / properties / keyword / description

Added value: +"Search keyword in Korean or English"

addedInput schema / properties / max_items / description

Added value: +"Maximum number of listings to return (default 30, max 100)"

addedInput schema / properties / sort / description

Added value: +"Sort order — 'recent' (최신순) or 'popular' (인기순)"

Changedsearch_daangn3 fields changed

addedInput schema / properties / keyword / description

Added value: +"Search keyword in Korean or English"

addedInput schema / properties / max_items / description

Added value: +"Maximum number of listings to return (default 30, max 100)"

addedInput schema / properties / region / description

Added value: +"Optional region filter (e.g. '서울', '강남구')"

Changedsearch_naver_news3 fields changed

addedInput schema / properties / max_articles / description

Added value: +"Maximum number of articles to return (default 20, max 100)"

addedInput schema / properties / query / description

Added value: +"Search query in Korean or English"

addedInput schema / properties / sort / description

Added value: +"Sort order — 'date' (최신순) or 'sim' (관련도순)"

Changedsearch_naver_places3 fields changed

addedInput schema / properties / keyword / description

Added value: +"Place type or name, e.g. '카페', '맛집', 'cafe'"

addedInput schema / properties / location / description

Added value: +"Location context, e.g. '홍대', '강남역', 'Itaewon'"

addedInput schema / properties / max_places / description

Added value: +"Maximum number of places to return (default 20, max 100)"

7 tool updatesv0.1.0Mar 21, 2026
- First observedget_melon_chart
- First observedget_musinsa_ranking
- First observedget_naver_place_reviews
- First observedsearch_bunjang
- First observedsearch_daangn
- First observedsearch_naver_news
- First observedsearch_naver_places

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.6/5.0

Disambiguation5/5

Each tool targets a distinct Korean data source (music chart, fashion ranking, marketplace, news, etc.) with no overlap in purpose, ensuring clear differentiation.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern: 'get_' for fetching entities and 'search_' for search operations, naming clearly reflects function.

Tool Count5/5

7 tools is well-scoped for a server focused on Korean data—covers multiple domains without being overwhelming or too sparse.

Completeness4/5

The set covers major Korean data categories (music, fashion, marketplace, news, places) but could be complemented with additional services like shopping or social media.

Maintenance

ActivityInactive

ResponsivenessUnresponsive

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

apify-mcp-serverOAuth
com.apify
Extract data from any website with thousands of scrapers, crawlers, and automations on Apify Store ⚡
Web Scraping Data Platforms App Automation
26,070
agent-signals-mcpOAuth
io.github.hassanahashish-design
Hiring, SEC, research papers, GitHub & Hacker News as JSON for AI agents. Pay-per-result on Apify.
Search Open Data Research & Data
2
kdata-gate C
io.github.loved0543-dotcom
Korean market data for AI agents: K-beauty/K-food products, Naver trends, stocks, real estate.
E-commerce & Retail Finance Real Estate
2621
kr-groundtruth A
io.github.ChloePark85
Korean fact-verification tools for AI agents: business registration, address, DART, apt prices, laws
Government Data Open Data Search
81

Related MCP Servers

actors-mcp-serverofficial
Browser Automation Search
apify
A
license
A
quality
A
maintenance
Use 3,000+ pre-built cloud tools from Apify, known as Actors, to extract data from websites, e-commerce, social media, search engines, maps, and more
Updated 14 hours ago (2026-09-05 20:11 UTC)
10
37,909
6,070
MIT
Web Intelligence MCP Server
ErnestaLabs
F
license
Not graded
quality
D
maintenance
Provides AI agents with real-time web capabilities including live search results, markdown web scraping, business lead generation, and detailed company information. It enables agents to bypass knowledge cutoffs by accessing current web data through a monetized Apify Actor.
Updated 6 months ago (2026-03-05 02:22 UTC)
-
webpeelofficial
Web Scraping Browser Automation Search
webpeel
A
license
Not graded
quality
B
maintenance
The web data platform for AI agents. Fetch, search, crawl, extract, monitor, and screenshot any URL. 55+ domain extractors, 65-98% token savings. 7 MCP tools included.
Updated 2 months ago (2026-06-29 04:23 UTC)
332
12
AGPL 3.0
Multi-Scraper MCP
Web Scraping Browser Automation
Perufitlife
A
license
Not graded
quality
D
maintenance
14 web scrapers as MCP tools for AI agents: Reddit, Amazon, Google Maps, Yelp, YouTube, Indeed & more.
Updated 3 months ago (2026-06-18 11:40 UTC)
61
2
MIT

Appeared in Searches

Naver - Korean Search Engine and Web Portal

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/leadbrain/korean-data-mcp'

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

🇰🇷 Korean Data MCP

🛠 Available Tools

🚀 Quick Start

1. Get an Apify API Token

2. Install

3. Set Environment Variable

4. Run the MCP Server

⚙️ Claude Desktop Configuration

💬 Usage Examples

🔧 Cursor / VS Code Configuration

📊 Data Sources

💰 Pricing

🏗 Development

📄 License

🤝 Contributing

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

actors-mcp-serverofficial

webpeelofficial

Appeared in Searches

Latest Blog Posts

MCP directory API