Reevl — Korean Real Estate

아파트 검색

search_apartments

Read-onlyIdempotent

전국 아파트 45,000여 개를 조건으로 거른다. "강남구 20억 이하 대단지", "전세가율 높은 곳", "AI 1년 예측이 높은 단지"처럼 조건이 있는 질문에 쓴다. 지역·브랜드·시공사는 완전일치이고, 수치 축은 <축>_min·<축>_max로 범위를 준다. 응답에 units(단위 설명)와 total이 함께 온다 — 단위를 지어내지 말고 units를 그대로 읽을 것. 기본 20건이며 total로 전체 규모를 알 수 있다. ★비교·순위·집계처럼 여러 건을 봐야 하는 질문이면 한 번에 limit=100으로 받아 직접 추려라. 20건씩 나눠 여러 번 부르는 것보다 그쪽이 훨씬 싸다(호출 비용은 건수와 거의 무관하다). 수천 건을 훑어야 하면 offset으로 넘기지 말고 describe_fields의 분포를 먼저 보고 조건을 좁혀라.

Input Schema

TableJSON Schema

Name	Required	Description
`q`	No	단지명 부분 일치 검색어
`gu`	No	시군구. 예: 강남구, 수원시 장안구. ★구를 둔 시는 '수원시'처럼 시 단위로도 받는다(하위 구 전체가 잡히고 normalized에 그 사실이 온다)
`dong`	No	읍면동. 예: 대치동
`sido`	No	시도. 예: 서울, 경기, 부산. (광주는 전남광주로 정규화된다)
`sort`	No	정렬 축(수치 축 이름). 예: price, fc12, hh, jr
`brand`	No	브랜드. 예: 자이, 래미안, 힐스테이트
`limit`	No	1~100, 기본 20
`order`	No	기본 desc
`fields`	No	쉼표로 구분한 축 목록, 또는 'all'. 기본은 14축(토큰 절약)
`hh_min`	No	세대수 하한
`jr_min`	No	전세가율 하한(%). 값 그대로 — 60이면 60%
`offset`	No	건너뛸 건수(페이지네이션)
`status`	No	단지 상태로 좁힌다. existing=기존 단지 · upcoming=분양 예정(price가 분양가) · unranked=무순위 청약. ★예측(fc*)으로 정렬·필터하면 자동으로 existing만 남는다 — 분양 예정을 보려면 여기서 명시할 것
`age_max`	No	준공 후 경과 연수 상한
`builder`	No	시공사. 예: 현대건설
`fc12_min`	No	리블 AI 1년 예측 하한(%). 값 그대로
`price_max`	No	매매 대표가 상한(만원)
`price_min`	No	매매 대표가 하한(만원)

Output Schema

TableJSON Schema

Name	Required	Description
`items`	Yes	단지 목록. 담기는 축은 fields를 따른다. status 축이 기본으로 포함된다 — upcoming이면 아직 안 지어진 단지이고 price는 분양가다
`limit`	No
`total`	Yes	조건에 맞는 전체 건수(반환 건수가 아니다)
`units`	Yes	축 이름 → 단위·뜻 설명. 숫자를 옮길 때 이 값을 그대로 읽는다
`fields`	No	items에 담긴 축 목록
`notice`	No	참고용 통계라는 고지. 투자 자문·중개가 아니다
`offset`	No
`source`	Yes	데이터 출처와 갱신일
`hasMore`	No
`returned`	Yes	이번에 실제로 담긴 건수
`nextOffset`	No	다음 쪽을 받을 때 offset에 넣을 값
`normalized`	No	고쳐 쓴 인자(예: '광주' → '전남광주'). 있으면 다음엔 고쳐 부를 것

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedAug 25, 2026

changedInput schema / properties / gu / description

Previous value: -"시군구. 예: 강남구, 수원시 장안구"New value: +"시군구. 예: 강남구, 수원시 장안구. ★구를 둔 시는 '수원시'처럼 **시 단위로도** 받는다(하위 구 전체가 잡히고 normalized에 그 사실이 온다)"

addedInput schema / properties / status

Added value: +{
+  "description": "단지 상태로 좁힌다. existing=기존 단지 · upcoming=분양 예정(price가 분양가) · unranked=무순위 청약. ★예측(fc*)으로 정렬·필터하면 자동으로 existing만 남는다 — 분양 예정을 보려면 여기서 명시할 것",
+  "enum": [
+    "existing",
+    "upcoming",
+    "unranked"
+  ],
+  "type": "string"
+}

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "fields": {
+      "description": "items에 담긴 축 목록",
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "hasMore": {
+      "type": "boolean"
+    },
+    "items": {
+      "description": "단지 목록. 담기는 축은 fields를 따른다. status 축이 기본으로 포함된다 — upcoming이면 아직 안 지어진 단지이고 price는 분양가다",
+      "items": {
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "limit": {
+      "type": "number"
+    },
+    "nextOffset": {
+      "description": "다음 쪽을 받을 때 offset에 넣을 값",
+      "type": "number"
+    },
+    "normalized": {
+      "description": "고쳐 쓴 인자(예: '광주' → '전남광주'). 있으면 다음엔 고쳐 부를 것",
+      "type": "object"
+    },
+    "notice": {
+      "description": "참고용 통계라는 고지. 투자 자문·중개가 아니다",
+      "type": "string"
+    },
+    "offset": {
+      "type": "number"
+    },
+    "returned": {
+      "description": "이번에 실제로 담긴 건수",
+      "type": "number"
+    },
+    "source": {
+      "description": "데이터 출처와 갱신일",
+      "type": "string"
+    },
+    "total": {
+      "description": "조건에 맞는 **전체** 건수(반환 건수가 아니다)",
+      "type": "number"
+    },
+    "units": {
+      "description": "축 이름 → 단위·뜻 설명. 숫자를 옮길 때 이 값을 그대로 읽는다",
+      "type": "object"
+    }
+  },
+  "required": [
+    "total",
+    "returned",
+    "items",
+    "units",
+    "source"
+  ],
+  "type": "object"
+}

First observedAug 23, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations already mark it read-only and idempotent, and the description goes further by explaining exact-match semantics for region/brand/builder, numeric _min/_max range behavior, automatic existing-only filtering when using fc* predictions, response shape signals (units and total), and pagination/cost behavior. This adds substantial behavioral context beyond the annotations.

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 long but every sentence carries operational value: use cases, matching rules, units handling, limit strategy, cost insight, and offset avoidance. It is front-loaded with the core purpose and then adds tactical guidance, so the length is justified.

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 18 optional parameters, full schema descriptions, an output schema, and annotations that establish read-only behavior, the description adds what an agent most needs beyond the schema: filtering semantics, response-shape conventions, cost-efficient limits, and guidance to consult describe_fields for huge result sets. Nothing critical for correct invocation 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?

The input schema already covers all 18 parameters with 100% description coverage, so the baseline is 3. The description adds meaningful value by explaining the general <axis>_min/<axis>_max convention, exact-match meaning, price units, and how status interacts with prediction filters, but it does not deeply re-explain each parameter beyond 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 leads with a specific action—filter nationwide apartments by conditions—and gives concrete example queries. It clearly positions itself as the condition-based search tool versus the focused get_apartment and describe_fields siblings, so an agent can tell them apart even before inspecting schemas.

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?

The description explicitly says when to use the tool ('조건이 있는 질문'), when to increase limit to 100 for comparison/ranking/aggregation, why that is cheaper, and when to consult describe_fields instead of paginating with offset. It gives actionable routing advice and even names a sibling tool.

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

All Reevl — Korean Real Estate tools Inspect

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

Need Help?