Skip to main content
Glama

Reevl — Korean Real Estate

아파트 외 부동산 검색

search_properties
Read-onlyIdempotent

빌라(연립·다세대)·오피스텔·단독다가구·토지·상가/사무실·아파트 분양권의 실거래를 지역별로 준다. "송파구 빌라 시세", "제주 토지 평당가", "강남 상가 얼마"처럼 아파트가 아닌 질문에 쓴다. ★아파트는 이 도구가 아니라 search_apartments를 쓸 것 — 둘은 데이터가 완전히 분리돼 있다. ★지역(sido+gu)이 반드시 필요하다. 전국 단위 목록은 주지 않는다 — 빌라만 24만 곳이라 한 번에 줄 수 없고, 준다 해도 읽을 수 없다. ★집계 단위가 유형마다 다르다: 빌라·오피스텔·분양권은 단지, 단독·토지·상가는 법정동이다 (응답의 unit이 알려준다). 단독·토지·상가에서 name은 건물 이름이 아니라 동 이름이다. ★AI 예측(fc)은 없다. 빌라는 단지당 20년에 10건꼴이라 예측이 성립하지 않는다 — 있는 척하지 말고 "실거래 통계"로만 답할 것.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
guYes시군구. 예: 송파구, 제주시
kindYesvilla=연립다세대 · officetel=오피스텔 · detached=단독다가구 · land=토지 · commercial=상가/사무실/건물 · presale=아파트 분양권 · ★_rent가 붙으면 **전월세**다(villa_rent·officetel_rent·detached_rent) — rep_price 대신 jtot(전세 대표가)·wolse_med(중위 월세)를 본다 · subscription=청약(분양 공고, 실거래 없음) · rental=공공임대(LH·마이홈 공급정보, 실거래 없음) · auction=공매(온비드, 금액은 감정가이며 실거래가 아님)
sidoNo시도. 예: 서울, 제주. (광주는 전남광주로 정규화된다)
sortNo정렬 축. 기본 n_total(거래 많은 순). ★유형에 없는 축으로 정렬하면 순서가 무의미해진다 — 전월세는 jtot·wolse_med, 공매는 min_low, 청약은 sub_end를 쓴다
limitNo1~100, 기본 20

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
dealNo'매매' 또는 '전월세'. ★label은 둘 다 '빌라'라 이 축으로 갈라야 한다
kindYes
unitYes'단지' 또는 '법정동' — items의 name이 무엇인지 알려준다
itemsYes유형에 따라 담기는 축이 다르다. ★단위는 응답의 units를 그대로 읽을 것 — 지어내면 100배·1만배 틀린다
labelNo유형 이름(빌라·토지 등)
totalYes그 지역의 전체 단위 수(반환 건수가 아니다)
unitsYes축 이름 → 단위·뜻 설명. 숫자를 옮길 때 이 값을 그대로 읽는다
noticeNo참고용 통계라는 고지. 투자 자문·중개가 아니다
regionNo
sourceYes데이터 출처와 갱신일
returnedYes
no_tradesNo있으면 실거래가 아니다(청약=공고가·공매=감정가). 시세로 인용하지 말 것

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.9/5.0
Behavior5/5

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

Goes well beyond the readOnly/idempotent annotations: explains that nationwide queries are impossible due to scale, that aggregation units vary by type (complex vs legal dong), that 'name' means dong name for detached/land/commercial, and that no AI prediction field exists. This is rich behavioral context an agent genuinely needs.

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 dense but each sentence earns its place, with ★ markers front-loading critical constraints. It covers type-specific aggregation, naming, prediction absence, and sibling routing without redundancy.

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 large kind enum, 5 parameters, and output-schema presence, the description covers the essential constraints: required region, type-dependent aggregation, naming semantics, and the apartment/non-apartment split. Nothing an agent needs to safely and correctly invoke this tool is missing.

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%, so the baseline is 3, but the description adds meaning beyond the schema: it clarifies that region is mandatory, warns that sort axes are meaningless for the wrong types, and explains the semantics of 'name' by type. Minor deduction because the 'sido+gu mandatory' phrasing slightly conflicts with the schema, which only lists gu as required.

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?

States a specific verb and resource: '실거래를 지역별로 준다' for non-apartment property types, and explicitly contrasts with search_apartments. The examples ('송파구 빌라 시세', '제주 토지 평당가') make the intended queries unmistakable.

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?

Explicitly says to use this tool for non-apartment questions and names the alternative search_apartments, stating the two datasets are completely separate. It also gives a hard constraint: region is mandatory and nationwide lists are not provided, which prevents invalid calls.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources