Skip to main content
Glama

korea-realty

by app.sallim

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

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건이 아파트로 답해졌다).

**매매 데이터만 있다** — 전월세를 물으면 이 축엔 데이터가 없다고 답하라(추정 금지).
면적 기준: 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건이 아파트로 답해졌다

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already signal read-only, idempotent, and non-destructive behavior, but the description adds serious non-obvious facts: an apartment query can return HTTP 200 with plausible rows when a wrong property_type is selected, land share transactions must not be used for price-per-area comparisons, and different property types have different area and field conventions. This goes well beyond the safety hints.

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?

The description is front-loaded with the single most important warning and organized into clear thematic blocks: core purpose, routing instructions, data limitations, and type-specific area semantics. It is dense, but nearly every sentence carries decision-relevant information; the small amount of redundancy with the schema keeps it from a top score.

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 lack of an output schema and the high conceptual complexity, the description fully explains what the response contains, how each property type handles area, and the notable exclusion rules for share-type land rows. It also gives the agent an explicit script for handling requests outside the data scope, making it complete for safe, correct invocation.

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 does add value: it explains that no property_type value corresponds to apartments, that area_band only makes sense for villa/officetel, and that land-specific fields like land_category or zoning are part of the data. Still, much of this is already duplicated inside the schema's parameter descriptions, so it doesn't fully break away from 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?

The description states the exact scope: '빌라(다세대·연립)·오피스텔·단독주택·토지 전용 실거래 매매가 조회' and the response shape '최근 거래 + 집계'. The emphatic '아파트는 이 도구가 아니다' and the explicit naming of sibling tools distinguish it sharply from other realty tools.

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?

It gives precise routing conditions: if the request contains '아파트', stop and use realty_region_price_stats, realty_search_complexes, or realty_complex_pyeong_price; do not use this tool for dong-level narrowing because sibling tools already accept legal-dong input. It also instructs the agent to answer that no jeonse/wolsae data exists rather than guessing.

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
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.9/5.0
Disambiguation3/5

The set has very explicit cross-tool guidance and each tool is often given a specific 'role', but there are still many overlapping clusters: auction search vs auction list vs auction detail, regional price bands vs price stats vs rankings, and court auction rate vs public auction rate. The descriptions reduce misselection, but with 51 tools including pairs like `fetch` and `realty_get_auction_case`, confusion is still likely for an agent.

Naming Consistency4/5

Most tools follow a clean `realty_` prefix and use consistent snake_case noun-phrases or verb-noun patterns, e.g. `realty_search_auctions`, `realty_get_auction_case`, `realty_presale_cost`. The exceptions are the generic `fetch`, `search`, and `report_issue`, which break the uniform prefixed convention but are only a small minor deviation from an otherwise consistent naming system.

Tool Count1/5

51 tools far exceeds the recommended threshold, even for a deliberately broad real-estate area; it is effectively an extreme number for a single MCP server. The tool count becomes the hardest usability problem, since agents must handle many tightly related micro-tools instead of interacting with a smaller, more manageable surface.

Completeness5/5

The tool set covers an impressively complete range: auction and public-auction workflows, apartment and non-apartment market, presale/cheongyak processes, tax and loan rules, subscription scoring, redevelopment, demographics, supply, POI, and even a reporting and routing tool. Boundaries and unsupported cases are explicitly documented, so there are no major obvious dead ends.

Resources