Skip to main content
Glama

korea-realty

by app.sallim
OverviewDiscussionsAdmin

비아파트 시세 — 빌라·오피스텔·단독·토지 (아파트는 이 도구가 아니다)

realty_nonapt_prices
Read-onlyIdempotent

빌라·오피스텔·단독주택·토지의 매매 실거래가를 조회한다(아파트는 이 도구가 아니다).

**아파트는 이 도구가 아니다.** 빌라(다세대·연립)·오피스텔·단독주택·토지 **전용**
실거래 **매매가** 조회다 — 응답 = 최근 거래(recent) + 집계(stats: 표본 수·가격·상위 구성).

질문에 '아파트'가 있으면 여기서 멈추고 아파트 축으로 가라 — 지역·법정동 월별 추이는
realty_region_price_stats, 단지·평형별 시세는 realty_search_complexes, 단지 평형의
건별 내역(계약일·층·가격)은 realty_complex_pyeong_price다. **셋 다 region에
'강남구 대치동'처럼 법정동을 그대로 받는다** — 동 단위로 좁히려고 이 도구로 오지 마라.
property_type 네 값 중 아파트에 가까운 것은 없고, 아무거나 고르면 **응답은 200이고
행도 채워져 나오므로 틀린 줄 모른다**(2026-08-23 PlayMCP QA 실측: '강남구 대치동
아파트 최근 실거래가'에 villa 5건이 아파트로 답해졌다).

**매매 데이터만 있다** — 전월세를 물으면 이 축엔 데이터가 없다고 답하라(추정 금지).
**도시형생활주택은 property_type에 없고 가를 수도 없다** — 원천에 유형 코드가 없어
아파트·연립다세대·오피스텔 신고에 섞여 있다. villa/officetel 값을 도시형생활주택
시세로 부르지 말고 섞여 있다고 밝혀라(응답 urban_housing_notice).
면적 기준: villa/officetel은 전용면적(area_m2·area_pyeong), house는 대지(land_*)와
건물(building_*) 분리, land는 계약면적·지목(land_category)·용도지역(zoning)이 온다.
land의 share_type='지분' 행은 필지 일부 거래라 면적당 가격 비교에 쓰지 말 것(집계는
지분·해제 제외 — 응답 note 참조).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNo최근 거래 행 수 (허용 범위 1~30)
regionYes지역명 부분일치 (예: 관악구, 서울특별시 강남구, 강남구 역삼동). **법정동까지 되는 것은 이 도구만이 아니다** — 아파트 축의 realty_region_price_stats·realty_search_complexes도 '강남구 대치동'을 그대로 받는다. 동 단위로 좁히려고 이 도구를 고르지 마라
area_bandNo전용면적대로 좁힌다(빌라·오피스텔만 — 단독주택은 전용면적 개념이 없다). 비아파트는 같은 동네에서도 면적 편차가 커서 지역 평균 하나로는 답이 안 된다. 안 넣어도 stats.by_area_band로 밴드별 분포가 온다
price_maxNo최대 매매가(만원)
price_minNo최소 매매가(만원)
property_typeYesvilla=다세대·연립(빌라), officetel=오피스텔, house=단독·다가구, land=토지. **이 네 값에 아파트는 없다** — 사용자가 아파트를 물었으면 아무 값이나 고르지 말고 이 도구를 부르지 마라(realty_search_complexes·realty_region_price_stats가 그 자리다). 2026-08-23 실측: '강남구 대치동 아파트 최근 실거래가'가 villa로 와 빌라 5건이 아파트로 답해졌다

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / property_type / description
      Previous value: -"villa=다세대·연립(빌라), officetel=오피스텔, house=단독·다가구, land=토지"New value: +"villa=다세대·연립(빌라), officetel=오피스텔, house=단독·다가구, land=토지. **이 네 값에 아파트는 없다** — 사용자가 아파트를 물었으면 아무 값이나 고르지 말고 이 도구를 부르지 마라(realty_search_complexes·realty_region_price_stats가 그 자리다). 2026-08-23 실측: '강남구 대치동 아파트 최근 실거래가'가 villa로 와 빌라 5건이 아파트로 답해졌다"
    • changedInput schema / properties / region / description
      Previous value: -"지역명 부분일치 (예: 관악구, 서울특별시 강남구, 강남구 역삼동)"New value: +"지역명 부분일치 (예: 관악구, 서울특별시 강남구, 강남구 역삼동). **법정동까지 되는 것은 이 도구만이 아니다** — 아파트 축의 realty_region_price_stats·realty_search_complexes도 '강남구 대치동'을 그대로 받는다. 동 단위로 좁히려고 이 도구를 고르지 마라"
  2. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -{
-  "additionalProperties": true,
-  "title": "realty_nonapt_pricesDictOutput",
-  "type": "object"
-}New value: +null
  3. Changed1 schema field changed
    • changedInput schema / properties / limit / description
      Previous value: -"최근 거래 행 수"New value: +"최근 거래 행 수 (허용 범위 1~30)"
  4. Changed1 schema field changed
    • addedInput schema / properties / area_band
      Added value: +{
+  "anyOf": [
+    {
+      "enum": [
+        "40㎡미만",
+        "40~59㎡",
+        "60~84㎡",
+        "85㎡이상"
+      ],
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "전용면적대로 좁힌다(빌라·오피스텔만 — 단독주택은 전용면적 개념이 없다). 비아파트는 같은 동네에서도 면적 편차가 커서 지역 평균 하나로는 답이 안 된다. 안 넣어도 stats.by_area_band로 밴드별 분포가 온다",
+  "title": "Area Band"
+}
  5. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Goes well beyond the readOnly/idempotent annotations: sale-only data with no 전월세 (must refuse rather than estimate), 도시형생활주택 absent from the type enum and unsplittable from source codes, 지분 rows excluded from stats and unsuitable for per-area pricing, and the critical failure mode that a wrong property_type still returns HTTP 200 with populated rows so errors are silent.

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?

Front-loaded and reasonably organized, but the apartment-exclusion warning is repeated in the description, again in the region and property_type schema fields, and again in the title — some of that emphasis is redundant rather than load-bearing for an already long block.

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?

With no output schema, the description still defines the response shape (recent rows + stats with 표본 수·가격·상위 구성) and flags the urban_housing_notice and note fields. For a disambiguation-heavy, high-mis-invocation tool, nothing material 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; the description nonetheless adds real meaning — area basis differs by type (villa/officetel use 전용면적, house splits 대지/건물, land returns 계약면적·지목·용도지역), and share_type='지분' handling is documented nowhere in the schema.

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+resource+scope: 조회 of 매매 실거래가 for 빌라·오피스텔·단독주택·토지, and explicitly negates the sibling category ('아파트는 이 도구가 아니다'). An agent can distinguish it from realty_region_price_stats / realty_search_complexes without opening any schema.

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?

Gives explicit routing rules: if the query mentions 아파트, stop and go to realty_region_price_stats (region/동 monthly trend), realty_search_complexes (단지/평형 시세), or realty_complex_pyeong_price (건별 내역). It also warns that legal-dong narrowing is not a reason to pick this tool, pre-empting the most likely mis-selection.

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

All korea-realty toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources