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

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건이 아파트로 답해졌다
include_footnotesNotrue면 계산값 근거 전문(산식·모집단·기간·원천)을 footnotes에 싣는다. 기본은 행마다 한 줄 요지

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / include_footnotes
      Added value: +{
+  "default": false,
+  "description": "true면 계산값 근거 전문(산식·모집단·기간·원천)을 footnotes에 싣는다. 기본은 행마다 한 줄 요지",
+  "title": "Include Footnotes",
+  "type": "boolean"
+}
  2. 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도 '강남구 대치동'을 그대로 받는다. 동 단위로 좁히려고 이 도구를 고르지 마라"
  3. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -{
-  "additionalProperties": true,
-  "title": "realty_nonapt_pricesDictOutput",
-  "type": "object"
-}New value: +null
  4. Changed1 schema field changed
    • changedInput schema / properties / limit / description
      Previous value: -"최근 거래 행 수"New value: +"최근 거래 행 수 (허용 범위 1~30)"
  5. 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"
+}
  6. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only supply readOnly/idempotent/openWorld, but the description discloses far more: the response shape (recent rows + stats with sample count, price, composition), the silent-failure mode where a mistyped property_type still returns HTTP 200 with populated rows backed by a dated QA incident, the 도시형생활주택 gap with its urban_housing_notice signal, and that aggregation excludes 지분/해제 rows. These are exactly the traps an agent cannot infer from structured fields.

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 forceful — the exclusion and the routing alternatives come first, and bolding makes the decision points scannable. It is longer than needed: the '아파트는 이 도구가 아니다' exclusion is restated four times across description and schema, which is defensive reinforcement rather than new information.

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?

No output schema exists, and the description compensates by explaining what comes back (recent transactions plus stats, by_area_band distribution, footnotes toggled by include_footnotes, note/urban_housing_notice). With 7 parameters, one enum, and zero nested objects, nothing an agent needs to call and interpret this tool correctly 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% and the schema itself already repeats the apartment warning on property_type and the house/전용면적 caveat on area_band, so much of the parameter text is duplication. The description still adds cross-parameter meaning the schema lacks: the land 면적 기준 (계약면적·지목·용도지역), the rule that share_type='지분' rows must not be used for per-area price comparison, and the 'don't call this just to narrow by 동' guidance on region.

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 (빌라·오피스텔·단독주택·토지의 매매 실거래가 조회) and immediately scopes what it is NOT (아파트는 이 도구가 아니다). It names the sibling tools that own the apartment axis (realty_region_price_stats, realty_search_complexes, realty_complex_pyeong_price), so an agent can route 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?

Explicit when-to-use and when-not: '질문에 아파트가 있으면 여기서 멈추고 아파트 축으로 가라' with the three named alternatives and the specific question each answers. It also adds the reverse exclusion (동 단위로 좁히려고 이 도구로 오지 마라) and states the domain limit (매매 데이터만 있다 — 전월세를 물으면 데이터가 없다고 답하라).

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