Skip to main content
Glama

korea-realty

by app.sallim
OverviewDiscussionsAdmin

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

realty_move_in_supply
Read-onlyIdempotent

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

지역의 입주 예정 물량을 연월별로 집계한다 — "○○ 입주장 리스크 있어?", "내년에
입주 물량 얼마나 쏟아져?"류 질문용. 입주 몰림은 전세가 하락·역전세 압력 신호다.
**region·sigungu를 둘 다 비우면 전국 호출**이고 응답에 `by_sido`(시도별 세대·공고 수,
세대 내림차순, 시도 미상 공고는 sido=null로 따로)가 실린다 — 시도 비교에 시도마다
따로 부르지 마라.

**기본 창은 오늘부터 앞이다** — 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을 이어서 부르거나 include_pipeline=true로 함께 받아라** —
사업승인은 났지만 아직 공고 안 난 물량이 거기 있다(세종 실측: 이 도구 676세대 →
파이프라인 3,483세대). 단 **두 축의 세대수를 더하지 마라**(이중계상) — 공고가 난
단지는 승인 목록에도 남아 양쪽에 다 잡힌다. 파이프라인 쪽 값이 상위 집합에 가깝다.

Input 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시군구 정확한 이름 (예: 수원시, 강남구)
include_pipelineNotrue면 **아직 모집공고 전인** 예정 공급(사업계획승인 기준 — realty_supply_pipeline과 같은 값, 같은 지역·같은 창)을 `pipeline`에 함께 싣는다. 두 축은 더하지 마라(이중계상)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / include_pipeline
      Added value: +{
+  "default": false,
+  "description": "true면 **아직 모집공고 전인** 예정 공급(사업계획승인 기준 — realty_supply_pipeline과 같은 값, 같은 지역·같은 창)을 `pipeline`에 함께 싣는다. 두 축은 더하지 마라(이중계상)",
+  "title": "Include Pipeline",
+  "type": "boolean"
+}
  2. 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은 시군구·동도 받는다 — 두 도구의 계약이 다르다"
  3. 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와 같은 축이라 둘 중 하나만 준다"
  4. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -{
-  "additionalProperties": true,
-  "title": "realty_move_in_supplyDictOutput",
-  "type": "object"
-}New value: +null
  5. 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은 시군구·동도 받는다. 두 도구의 계약이 다르다)"
  6. Added

TDQS

A4.7/5.0
Behavior5/5

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

Annotations only declare read-only/idempotent safety; the description adds the substantive behavioral facts: the default window points forward from today, the dataset is a lower bound because notices precede move-in by ~30 months, and meta.window_direction / reading.interpretation must be honored in conclusions. The 세종 2028~2030 undercount incident concretely demonstrates the failure mode, and the no-double-counting rule between the notice and pipeline axes is stated.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The opening sentence '지역의 입주 예정 물량을 연월별로 집계한다' is duplicated verbatim as the first two lines, and the window-direction warning is restated in both the description body and the from_ym/months schema text. The content is valuable and the core routing is front-loaded, but a third of the text is redundant.

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, yet the description surfaces the response fields an agent actually needs — by_sido, reading.interpretation, coverage.region_recent_annual_rate, meta.window_direction — along with the interpretation rule and the cross-tool follow-up. Nothing needed to call it correctly or read 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% and the parameter descriptions already carry much of the window-direction and to_ym/months exclusivity detail, so the description largely reinforces rather than originates that. It does add genuine semantics beyond the schema — the region-vs-sigungu contract divergence from realty_supply_pipeline and the double-counting caveat on include_pipeline.

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 and resource — aggregating expected move-in supply (입주 예정 물량) by year-month for a region — and explicitly contrasts its contract with realty_supply_pipeline (region accepts 시군구/동 there but only 시도 here). An agent can route between the two without opening either 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?

Names the triggering question types ('입주장 리스크 있어?', '내년에 입주 물량 얼마나 쏟아져?'), forbids per-sido loops by pointing to the by_sido response field, and prescribes the fallback (call realty_supply_pipeline or set include_pipeline=true) when the lower-bound reading looks thin. Alternative routing is explicit in both directions.

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