Skip to main content
Glama

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

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에 넣어라 — 넣어도 오류가 나지 않고 0건이 온다(realty_supply_pipeline의 region은 시군구·동도 받는다. 두 도구의 계약이 다르다)
from_ymNo조회 창의 **시작** 월, YYYYMM 6자리(예: 202508). 생략하면 **이번 달**이라 창이 전부 미래가 된다 — 이 도구의 기본 방향은 '입주 **예정**'이라서다. **'최근 N개월'·'지난해'처럼 지나간 물량을 물었으면 여기를 과거로 줘라**: 최근 12개월 = from_ym='202508' + months=12, 작년 한 해 = from_ym='202501' + months=12. 과거 조회도 그대로 된다(원장은 2020-02 공고분부터)
sigunguNo시군구 정확한 이름 (예: 수원시, 강남구)

TDQS

A4.6/5.0
Behavior5/5

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

The description reveals behavior that annotations do not cover: the result is a lower-bound settlement based on Cheongahon announcements since 2020-02; announcements typically appear ~30 months before occupancy; and far-future slices are systematically understated. It additionally exposes output semantics such as meta.window_direction, interpretation, and coverage.region_recent_annual_rate, so an agent knows how to interpret the response.

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 long but well structured: each bolded segment carries a distinct and genuinely useful point, such as future-window semantics, lower-bound counting, and follow-up to the pipeline. There is little filler, and the concrete example helps the agent understand the practical stakes, though some steps are dense and could have been tightened further.

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 5 loose parameters, no output schema, and a data caveat, the description remarkably covers the required output interpretation, delusion-prone pitfall, and follow-up path. An agent can correctly select and use the tool, interpret reading.lower_bound, and decide when to call the pipeline.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and the parameter descriptions already explain from_ym, months, to_ym, region, and sigungu well, including forward/backward timing and mutual exclusivity of months and to_ym. The tool description mainly restates those semantics in prose rather than adding new parameter detail 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 explicitly states the tool's function: it aggregates regional move-in supply by year-month. It answers concrete questions like '입주장 리스크 있어?' and '물량이 얼마나 쏟아져?', and it differentiates itself from realty_supply_pipeline by clarifying that this tool covers announced supply while the pipeline covers approved-but-not-yet-announced supply.

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 clearly identifies when to use the tool, when to switch to realty_supply_pipeline, and when to avoid double-counting: if coverage.region_recent_annual_rate is low relative to the result, the shortage is likely due to announcement timing, not supply cessation. The description also tells the agent not to state 'no risk' when the tool only reports the lower bound.

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

Try in Browser

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.