Skip to main content
Glama

korea-realty

by app.sallim
OverviewDiscussionsAdmin

입주 예정 물량 — 입주장 리스크

realty_move_in_supply
Read-onlyIdempotent

지역의 입주 예정 물량을 연월별로 집계한다.

지역의 입주 예정 물량을 연월별로 집계한다 — "○○ 입주장 리스크 있어?", "내년에
입주 물량 얼마나 쏟아져?"류 질문용. 입주 몰림은 전세가 하락·역전세 압력 신호다.

**기본 창은 오늘부터 앞이다** — from_ym을 안 주면 이번 달에서 시작하므로 months=12는
"앞으로 12개월"이지 "최근 12개월"이 아니다. **과거를 물었으면 from_ym을 과거로 줘라**
(최근 12개월 = from_ym='YYYYMM'(12개월 전) + months=12). 응답 meta.window_direction이
그 회차의 창이 과거인지 미래인지를 라벨로 실토하니 결론에 기간을 그대로 밝혀라.

**하한 집계다** — 청약홈 공고(2020-02 이후) 기반이라 공고 없는 공급(민간임대·후분양
일부)이 빠지고, 무엇보다 **공고는 입주 평균 30개월 전에 난다**(전국 실측). 그래서
조회 구간이 오늘+30개월을 넘어가면 그 구간 입주분은 아직 공고조차 안 된 것이 대부분이다.
실사고: 세종 2028~2030 조회에 676세대가 나오자 "입주장 리스크 없음"으로 답했으나
실제 계획은 그 6배였다.

응답의 **`reading` 문장을 결론에 그대로 반영하라** — `interpretation`이 `lower_bound`면
"물량 없음/적음"이라 말하지 말고 "공고된 것만 N세대(하한)"라고 답해야 한다.
`coverage.region_recent_annual_rate`(그 지역 최근 공고 실적)와 비교해 값이 크게 낮으면
공급이 끊긴 게 아니라 공고 시차다. **그때는 realty_supply_pipeline을 이어서 불러라** —
사업승인은 났지만 아직 공고 안 난 물량이 거기 있다(세종 실측: 이 도구 676세대 →
파이프라인 3,483세대). 단 **두 축의 세대수를 더하지 마라**(이중계상) — 공고가 난
단지는 승인 목록에도 남아 양쪽에 다 잡힌다. 파이프라인 쪽 값이 상위 집합에 가깝다.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
to_ymNo조회 창의 **끝** 월, YYYYMM 6자리(기본 from_ym+36개월). months와 같은 축이라 둘 중 하나만 준다
monthsNofrom_ym부터 **앞으로 몇 개월**을 볼지 — to_ym 대신 쓰는 간편 인자(예: 24). **뒤로 세지 않는다** — months=12만 주면 from_ym이 이번 달이라 '앞으로 12개월'이 되고, '최근 12개월'을 원했다면 from_ym을 12개월 전으로 함께 줘야 한다. to_ym과 함께 주면 오류다(둘 중 하나만) (허용 범위 1~120)
regionNo**시도만** (예: 서울, 경기, 세종, 부산). 시군구('강남구')는 sigungu에 넣어라 — region에 넣으면 서버가 sigungu로 옮겨 조회하고 그 사실을 meta.unapplied_conditions에 적는다(시군구 어휘에 없는 이름은 옮기지 못하고 역시 거기 적는다). realty_supply_pipeline의 region은 시군구·동도 받는다 — 두 도구의 계약이 다르다
from_ymNo조회 창의 **시작** 월, YYYYMM 6자리(예: 202508). 생략하면 **이번 달**이라 창이 전부 미래가 된다 — 이 도구의 기본 방향은 '입주 **예정**'이라서다. **'최근 N개월'·'지난해'처럼 지나간 물량을 물었으면 여기를 과거로 줘라**: 최근 12개월 = from_ym='202508' + months=12, 작년 한 해 = from_ym='202501' + months=12. 과거 조회도 그대로 된다(원장은 2020-02 공고분부터)
sigunguNo시군구 정확한 이름 (예: 수원시, 강남구)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / region / description
      Previous value: -"**시도만** (예: 서울, 경기, 세종, 부산). ⚠️ 시군구('강남구')는 여기가 아니라 sigungu에 넣어라 — 넣어도 오류가 나지 않고 0건이 온다(realty_supply_pipeline의 region은 시군구·동도 받는다. 두 도구의 계약이 다르다)"New value: +"**시도만** (예: 서울, 경기, 세종, 부산). 시군구('강남구')는 sigungu에 넣어라 — region에 넣으면 서버가 sigungu로 옮겨 조회하고 그 사실을 meta.unapplied_conditions에 적는다(시군구 어휘에 없는 이름은 옮기지 못하고 역시 거기 적는다). realty_supply_pipeline의 region은 시군구·동도 받는다 — 두 도구의 계약이 다르다"
  2. Changed3 schema fields changed
    • changedInput schema / properties / from_ym / description
      Previous value: -"YYYYMM (기본 이번 달)"New value: +"조회 창의 **시작** 월, YYYYMM 6자리(예: 202508). 생략하면 **이번 달**이라 창이 전부 미래가 된다 — 이 도구의 기본 방향은 '입주 **예정**'이라서다. **'최근 N개월'·'지난해'처럼 지나간 물량을 물었으면 여기를 과거로 줘라**: 최근 12개월 = from_ym='202508' + months=12, 작년 한 해 = from_ym='202501' + months=12. 과거 조회도 그대로 된다(원장은 2020-02 공고분부터)"
    • changedInput schema / properties / months / description
      Previous value: -"from_ym부터 **몇 개월**을 볼지 — to_ym 대신 쓰는 간편 인자(예: 24). to_ym과 함께 주면 오류다(둘 중 하나만) (허용 범위 1~120)"New value: +"from_ym부터 **앞으로 몇 개월**을 볼지 — to_ym 대신 쓰는 간편 인자(예: 24). **뒤로 세지 않는다** — months=12만 주면 from_ym이 이번 달이라 '앞으로 12개월'이 되고, '최근 12개월'을 원했다면 from_ym을 12개월 전으로 함께 줘야 한다. to_ym과 함께 주면 오류다(둘 중 하나만) (허용 범위 1~120)"
    • changedInput schema / properties / to_ym / description
      Previous value: -"YYYYMM (기본 from_ym+36개월)"New value: +"조회 창의 **끝** 월, YYYYMM 6자리(기본 from_ym+36개월). months와 같은 축이라 둘 중 하나만 준다"
  3. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -{
-  "additionalProperties": true,
-  "title": "realty_move_in_supplyDictOutput",
-  "type": "object"
-}New value: +null
  4. Changed2 schema fields changed
    • addedInput schema / properties / months
      Added value: +{
+  "anyOf": [
+    {
+      "maximum": 120,
+      "minimum": 1,
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "from_ym부터 **몇 개월**을 볼지 — to_ym 대신 쓰는 간편 인자(예: 24). to_ym과 함께 주면 오류다(둘 중 하나만) (허용 범위 1~120)",
+  "title": "Months"
+}
    • changedInput schema / properties / region / description
      Previous value: -"시도 (예: 서울, 경기, 세종, 부산)"New value: +"**시도만** (예: 서울, 경기, 세종, 부산). ⚠️ 시군구('강남구')는 여기가 아니라 sigungu에 넣어라 — 넣어도 오류가 나지 않고 0건이 온다(realty_supply_pipeline의 region은 시군구·동도 받는다. 두 도구의 계약이 다르다)"
  5. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations cover the safety profile, and the description adds substantial behavior beyond them: the default window points forward, results are a lower bound with a ~30-month notice lag, meta.window_direction self-labels the window, and the reading/interpretation fields must be honored in the conclusion. The 세종 실사고 example concretely shows the failure mode.

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 with the core purpose and the default-window trap, and dense with actionable detail rather than filler. It is long, but nearly every sentence prevents a specific misreading, so the length is justified rather than padded.

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 proactively explains the return-shape fields that matter (meta.window_direction, reading/interpretation, coverage.region_recent_annual_rate) and how to phrase conclusions from them. Nothing an agent needs to call and interpret it 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%, so the baseline is 3, but the description adds cross-tool contract context (region takes 시도 only here vs. 시군구/동 in realty_supply_pipeline) and reinforces the months/from_ym mutual exclusivity and the past-vs-future framing that trips agents up.

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: aggregating a region's scheduled move-in volume by year-month, and frames it against the sibling it is not (realty_supply_pipeline). An agent can distinguish it from realty_supply_pipeline and realty_supply_demand_balance without opening a 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?

Explicitly names the question types it answers ('○○ 입주장 리스크 있어?', '내년에 입주 물량 얼마나 쏟아져?'), states when to switch to realty_supply_pipeline (when coverage.region_recent_annual_rate is far below), and warns not to sum the two axes due to double counting.

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