Skip to main content
Glama
syleedlabs

deal-locator-mcp

by syleedlabs

지역 스캔

area_scan
Read-onlyIdempotent

Scan commercial building sales in Seoul by district or neighborhood. Filter by price per pyeong and road name to view recent transactions and statistics.

Instructions

구·동 단위 상업업무용(통건물) 시세 — 동이면 후보 거래까지, 구면 통계·동별 순위.

area 에 구만 주면('강남구') 구 모드, 동을 주면('대치동') 동 모드다. 지번을 몰라도 '동 + 가격대'로 조회한다. 예: area='성수동1가', min_eok_per_pyeong=4.5, max_eok_per_pyeong=5.5 → 연면적 평당 4.5~5.5억 거래를 최신순으로. min/max 가 0 이면 해당 방향 제한 없음. 평당가 기준 = 연면적(거래금액÷연면적평). road_contains(예: '연무장길')를 주면 표제부 역매칭으로 도로명이 특정된 거래만 부분일치 필터 — 도로명 미상(마스킹 미복원) 거래는 제외되며 그 건수를 함께 고지한다. 서울 상업업무용 매매 한정(v1). 첫 조회는 표제부 API 로딩으로 수십 초 걸릴 수 있다. 표본 대표성을 판단할 때는 structuredContent 의 coverage(모수 분해)를 함께 읽을 것.

취급 범위는 통건물(유형='일반')뿐 — 집합(구분상가)은 제외한다(coverage.jiphap_excluded 에 건수). 그러므로 stats 는 전부 '통건물 시세'이며, 상가 한 칸 시세가 아니다.

area 에 구만 주면('강남구'·'강남') 구 모드로 동작한다 — 구 전체 시세와 분기 추이, 그리고 by_dong(동별 대지 평단가 내림차순)을 낸다. 구 모드는 표제부 역매칭을 돌리지 않아 deals 가 항상 비어 있다(scope='구' 로 구분). 개별 지번·거래가 필요하면 동으로 다시 부를 것.

동 평균 평단가는 stats(연면적·대지)에 담긴다 — 가격대·도로명 필터와 무관하게, 표제부 역매칭 이전의 국토부 원본 실거래(통건물, 해제·산출불가 제외)로 산출하므로 전수에 가깝다. '이 동 평단가 시세'를 물으면 deals 가 아니라 stats 를 근거로 답할 것 (deals 는 필터 통과분이라 평균 내면 편향된다). 평균이 필요할 뿐이면 min/max 를 주지 말고(밴드 없이) 호출하면 된다.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
areaYes
limitNo
monthsNo
road_containsNo
max_eok_per_pyeongNo
min_eok_per_pyeongNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
areaNo
dealsYes최신순. 평단가 기준은 연면적(거래금액 ÷ 연면적평).
queryYes
scopeNo'구' 면 구 전체 통계 모드 — deals 는 항상 비어 있고(역매칭 미실행) by_dong 에 동별 순위가 담긴다. 개별 지번이 필요하면 동으로 다시 조회할 것.
statsNo동 전체 평단가 시세 — 사용자 가격대·도로명 필터와 무관하게, 표제부 역매칭 이전의 국토부 원본 실거래(해제·산출불가 제외)로 산출. deals(필터 통과분)와 달리 표본이 줄지 않아 평균이 편향되지 않는다.
filterNo실제 적용된 필터(클램프·스왑 후 값).
sourceYes
statusYesOK 일 때만 deals 에 실측값이 있다. 그 외에는 수치를 추측·보간하지 말 것.
by_dongNo구 모드 전용 — 동별 평단가(대지 중앙값 내림차순). 동 모드에서는 빈 배열.
messageNo
coverageNo모수 분해 — matched 만 보지 말고 무엇이 왜 빠졌는지 함께 읽을 것.
lookup_statusNo도메인 원본 상태(거래있음/조건_불일치/거래없음 …)
period_monthsYes
Behavior4/5

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

Annotations already indicate read-only, idempotent behavior. The description adds context about initialization delay, empty deals in district mode, stats computation from raw data, and reliance on structuredContent for coverage. No contradiction 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.

Conciseness3/5

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

The description is well-organized with paragraphs and examples, but it is somewhat verbose. The core purpose is front-loaded, but some explanations (e.g., mode details) could be condensed without losing clarity.

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 complexity (two modes, multiple filters, output schema with coverage), the description covers all essential aspects: usage scenarios, edge cases, performance characteristics, and how to interpret results. It is sufficiently complete for proper usage.

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 coverage, the description must entirely explain parameters. It covers area, road_contains, min/max_eok_per_pyeong well with examples. However, limit and months are not explicitly described, leaving some ambiguity.

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 purpose: retrieving commercial building market prices by district or neighborhood in Seoul, with two distinct modes (구/동). It distinguishes itself from sibling tools like deal_card_search by focusing on area-based aggregation rather than individual deals.

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

Usage Guidelines4/5

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

The description explains when to use each mode (district vs. neighborhood) and when to rely on stats vs. deals for accurate averages. It warns about first-query slowness and limitations to '통건물' only. However, it lacks explicit comparison to sibling tools like deal_history or match_explain.

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

Install Server

Other Tools

Latest Blog Posts

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/syleedlabs/deal-locator-mcp'

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