Provides proxy support for scraping Daangn listings using the Zyte API to avoid IP blocking.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@danggn-mcp search for used iPhone 14 in Gangnam"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
이 프로젝트는당근마켓 공식 Open API가 아닌 공개 웹 페이지를 파싱합니다. 사이트 구조가 바뀌면 일부 기능이 깨질 수 있습니다. 개인·비상업적 용도를 권장합니다.
과도한 요청은 당근마켓에서 차단될 수 있습니다. 차단이 잦으면ZYTE_API_KEY 환경 변수로 Zyte 프록시를 켤 수 있습니다.
Related MCP server: @dealx/mcp-server
기능 | 설명 |
🔍 매물 검색 | 키워드·동네 슬러그 기반 당근마켓 검색 |
📦 상세 조회 | 게시글 상세 · 판매자 · 매너온도 조회 |
📉 시세 확인 | 검색 결과 기반 가격 범위 · 요약 |
📍 동네 슬러그 | 인근 동네 목록 · 슬러그 유효성 확인 |
🔌 stdio MCP | Cursor, Claude, Codex 등 로컬 클라이언트 지원 |
📦 Zero setup |
|
git clone https://github.com/iamkw0n/danggn-mcp.git
cd danggn-mcp
npm install
npm start공통 실행 명령:
node dist/index.jsTool | Description |
| 키워드 매물 검색 |
| 게시글 상세 · 판매 정보 |
| 검색 결과 기반 시세 요약 |
| 인근 동네 슬러그 목록 |
| 동네 슬러그 유효성 확인 |
| 프록시 상태 확인 |
Cursor / Claude Code / Codex에서 아래 프롬프트를 붙여넣으면 MCP 설치를 요청할 수 있습니다.
Github에서 iamkw0n/danggn-mcp 를 가져와서 MCP 서버 설치를 해줘.Client | Config file | stdio |
Cursor |
| ✅ |
Claude Code |
| ✅ |
Claude Desktop |
| ✅ |
Codex |
| ✅ |
ChatGPT | Connector URL | ❌ |
프로젝트 루트에 .cursor/mcp.json:
{
"mcpServers": {
"danggn-mcp": {
"command": "node",
"args": ["./dist/index.js"],
"cwd": "${workspaceFolder}"
}
}
}프로젝트 루트에 .mcp.json:
{
"mcpServers": {
"danggn-mcp": {
"type": "stdio",
"command": "node",
"args": ["./dist/index.js"]
}
}
}CLI:
claude mcp add danggn-mcp -s project -- node ./dist/index.jsmacOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"danggn-mcp": {
"command": "node",
"args": ["/absolute/path/to/danggn-mcp/dist/index.js"],
"cwd": "/absolute/path/to/danggn-mcp"
}
}
}Claude Desktop은${workspaceFolder}를 지원하지 않습니다. 절대 경로를 사용하세요.
프로젝트 .codex/config.toml 또는 ~/.codex/config.toml:
[mcp_servers.danggn-mcp]
command = "node"
args = ["./dist/index.js"]
cwd = "/absolute/path/to/danggn-mcp"
enabled = trueCLI:
codex mcp add danggn-mcp -- node ./dist/index.js연결 확인: Codex 세션에서 /mcp
ChatGPT 커넥터는HTTPS MCP 엔드포인트만 지원합니다. 이 레포는 로컬 stdio 서버이므로 ChatGPT에 직접 연결할 수 없습니다.
갤럭시북 당근마켓 검색해줘아이폰 15 강남구 근처 당근 매물 찾아줘iamkw0n 게시글 상세 보여줘맥북 당근 시세 요약해줘역삼동 동네 슬러그 찾아줘강남구-386 슬러그 유효한지 확인해줘프록시 상태 확인해줘flowchart LR
A[MCP Client] -->|stdio| B[danggn-mcp]
B --> C[www.daangn.com/kr/buy-sell]
B --> D[fleamarketArticles JSON]
B --> E[JSON-LD Product/ItemList]
B --> F[api.zyte.com/v1/extract]Endpoint | Usage |
| 매물 검색 |
| 게시글 상세 |
| 검색 결과 임베디드 JSON |
| 차단 대응용 프록시 |
검색 범위를 좁히려면 regionSlug에 동네이름-숫자ID 형식을 사용하세요.
예: 강남구-386, 역삼동-6035
list_nearby_regions로 기본 페이지에 노출되는 인근 동네를 확인할 수 있습니다.
MIT © iamkw0n
당근마켓 게시글 상세 정보를 조회합니다.
| Name | Required | Description | Default |
|---|---|---|---|
| articleRef | Yes | 게시글 ID, URL, 또는 slug (예: p7mskunj8ik8) |
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 that it retrieves info, without mentioning response format, error conditions, rate limits, or whether it is read-only. This is a minimal description that leaves the agent without insight into side effects or output expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, concise Korean sentence with no filler. It is front-loaded and easy to parse, exactly what a short tool description should be.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description should compensate by explaining what 'detailed info' includes (e.g., price, seller, location). It only states 'detailed info', leaving the agent uncertain about the return payload. The tool is simple, but the description is too sparse to be considered complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already has 100% coverage, describing articleRef as '게시글 ID, URL, 또는 slug (예: p7mskunj8ik8)'. The description does not add extra parameter semantics, but the schema is clear enough, 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.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action '조회합니다' (retrieves) and the resource '당근마켓 게시글 상세 정보' (Carrot Market post detailed info). It distinguishes from siblings by implying a single listing detail lookup versus search or summary operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 like search_listings or summarize_search_market. The description does not mention any prerequisites, such as needing a specific articleRef obtained from a search, nor does it contrast with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
당근마켓 기본 페이지에 노출되는 인근 동네 슬러그 목록을 조회합니다.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | 최대 결과 수 | |
| keyword | No | 동네명 필터 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It does state 'retrieves' implying a read-only operation, and adds context about the default page. However, it doesn't disclose any side effects, authentication requirements, or rate limits, leaving some uncertainty about behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the action and resource. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description gives essential context (default page, nearby slugs) and the schema covers both parameters. However, without an output schema, it could mention the return structure more explicitly, but the phrase 'list of slugs' already indicates the output. Overall it's adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters (limit, keyword) already have clear descriptions in the schema (max results, neighborhood name filter). The tool description adds no additional meaning about these parameters, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the list of nearby neighborhood slugs shown on the default page, using a specific verb (조회합니다) and resource. This distinguishes it from sibling tools like search_listings or validate_region_slug.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives, nor any mention of exclusions or prerequisites. The description only implies it is for the default page's nearby regions, but doesn't provide decision criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
당근마켓 요청의 차단 상태와 Zyte 프록시 사용 여부를 확인합니다.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 nothing about side effects, return format, or read-only nature. The verb '확인합니다' implies a check but gives the agent no concrete behavioral expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that directly states the tool's purpose. No filler or redundant information, ideal for a simple status-check tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description should explain what the tool returns (e.g., status fields or boolean). It only says 'checks', leaving the agent without information about the result shape or possible values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, so schema coverage is 100%. Baseline 4 applies; no parameter information is needed from the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states the function clearly: checking block status and Zyte proxy usage for Karrot Market requests. This distinguishes it from siblings which focus on listing search, market summary, and region validation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied as a diagnostic tool, but description provides no explicit when-to-use or exclusions compared to sibling tools. No alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
당근마켓에서 중고거래 매물을 검색합니다.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | 정렬 기준 | recommend |
| limit | No | 최대 결과 수 | |
| query | Yes | 검색 키워드 | |
| maxPrice | No | 최대 가격 | |
| minPrice | No | 최소 가격 | |
| regionSlug | No | 동네 슬러그 (예: 강남구-386, 역삼동-6035) | |
| onlyOngoing | No | 판매중 매물만 볼지 여부 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It only states the action of searching, but does not mention the return format, whether results are paginated, what kind of results come back, or any side effects. The description adds almost nothing beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, '당근마켓에서 중고거래 매물을 검색합니다.' It is concise and front-loaded, with no unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 7 parameters and no output schema, the description is insufficient. It does not explain what the tool returns (e.g., a list of listings), how results are sorted by default, or how to effectively combine filters. The description is too sparse to be complete for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for all 7 parameters, each with descriptions in Korean (e.g., 'query' = 검색 키워드, 'sort' = 정렬 기준). Thus the baseline is 3. The description itself adds minimal parameter context (used-goods listings) but does not need to compensate for schema gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches used goods listings on Karrot (당근마켓). It uses the specific verb '검색' (search) and resource '중고거래 매물' (used-goods listings), which distinguishes it from siblings like get_listing_detail and summarize_search_market.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives such as get_listing_detail or summarize_search_market. It simply says 'searches listings' without any exclusions or context about choosing this over other search-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
당근마켓 검색 결과를 바탕으로 간단한 시세 요약을 만듭니다.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | 분석할 최대 결과 수 | |
| query | Yes | 검색 키워드 | |
| maxPrice | No | 최대 가격 | |
| minPrice | No | 최소 가격 | |
| regionSlug | No | 동네 슬러그 | |
| onlyOngoing | No | 판매중 매물만 분석할지 여부 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosure. It only says 'creates a simple market price summary' without describing return format, side effects, or any internal behavior, leaving significant ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded Korean sentence conveying the core purpose with no wasted words. Highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given six parameters and no output schema or annotations, the description is too sparse. It fails to explain what the summary contains, how results are generated, or any constraints, leaving the agent without essential context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover 100% of parameters, and the tool description adds no additional parameter context. The baseline of 3 applies since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states it creates a simple market price summary based on Carrot Market search results, clearly identifying the tool's function and distinguishing it from siblings like search_listings and get_listing_detail.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use after search results are available but offers no explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives. Context is implied but not elaborated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
당근마켓 동네 슬러그가 유효한지 확인합니다.
| Name | Required | Description | Default |
|---|---|---|---|
| regionSlug | Yes | 동네 슬러그 (예: 강남구-386) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose side effects and return behavior. It only says 'checks validity' without specifying whether it returns a boolean, throws an error, or has any side effects. For a validation tool, knowing the response format is critical, and this is absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no filler. It efficiently conveys the core purpose in minimal words, which is ideal for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description should clarify what the caller receives. It does not. For a validation tool, an agent needs to understand the response type (e.g., true/false, error message) to use it correctly. The simplicity of the input schema doesn't compensate for this missing information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already comprehensively documents the only parameter, regionSlug, including an example. The tool description adds no extra semantic detail beyond what the schema provides. With 100% schema coverage, 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action: '확인합니다' (checks/validates) on a specific resource: '동네 슬러그' (neighborhood slug). This unambiguously defines the tool's purpose and naturally distinguishes it from sibling tools that handle listings or market searches.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., obtaining a slug first) or typical use cases like pre-validating before another operation. The description only restates what it does, not when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0get_listing_detaillist_nearby_regionsproxy_statussearch_listingssummarize_search_marketvalidate_region_slugScored across 6 tools
Each tool has a distinct purpose: searching, retrieving details, summarizing market data, and managing region slugs, with no overlap between them.
Most tools follow a verb_noun pattern (search, get, list, validate, summarize), but 'proxy_status' is a noun phrase, slightly breaking the convention.
Six tools is well-scoped for a marketplace search and analysis server, covering core operations without unnecessary bloat.
The server covers search, detail retrieval, market summarization, and region utilities, but lacks listing creation or advanced filtering options, which are minor gaps for a read-only market analysis tool.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Korean fact-verification tools for AI agents: business registration, address, DART, apt prices, laws
Web data tools for AI agents: pages as markdown, search, maps, commerce, jobs, AI answers.
Korean market data for AI agents: K-beauty/K-food products, Naver trends, stocks, real estate.
Market analyst tools + AI agent: crypto, US equities, options, Korea, fundamentals, macro, backtests
