Skip to main content
Glama

korea-realty

by app.sallim

공고 전 공급 파이프라인 — 사업승인 기준 예정 물량

realty_supply_pipeline
Read-onlyIdempotent

아직 분양 공고가 안 난 예정 공급을 사업계획승인 기준으로 본다 — "지금 넣을까, 다음 걸 기다릴까", "이 동네 앞으로 입주 폭탄 있나"류 질문의 자리.

청약홈(realty_presale·realty_move_in_supply)은 **모집공고일에야** 등록되므로 공고 전
물량이 구조적으로 안 보인다. 이 도구의 원천은 주택법 **사업계획승인**이라 공고 2~3년
전 단계가 잡힌다: 사업명·세대수·승인일·착공예정일·사용검사 예정일(=예상 입주).

재당첨 제한(분양가상한제 단지는 10년)·전매제한이 걸린 결정에서는 **대안 정보가 없으면
"지금 아니면 끝"이라는 잘못된 압박**이 생긴다 — 청약 상담이면 이 도구를 함께 불러라.

두 축을 **더하지 마라**(이중계상) — 이미 공고가 난 단지도 승인 목록에 남아 있다.
**이미 모집공고가 난 사업**은 블록 표기가 겹치면 행에 `announced_notice`가 붙는다 —
그 행은 '다음 분양'이 아니라 realty_presale·realty_subscription_odds의 영역이다.
표식이 없어도 기공고일 수 있다(meta.announced_cross_check 참조).
승인 전(지구계획·공모) 물량은 여기에도 없으니 이 값도 하한이다(`interpretation`).

**층수 축(2026-08-20 신설)**: `max_floor`·`min_floor`는 사업계획승인 시점의 **계획**
층수다(변경승인으로 움직인다 — 준공 확정층수가 아니고, 출처는 `max_floor_source`).
`min_floor`는 그 사업의 공동주택 주건축물 중 가장 낮은 동이라 **실제로 그 층수의 동이
있다**는 뜻이고, 저층 선호(고소공포)·고층 조망 상담의 근거가 된다. 값이 비면
**'저층'으로 읽지 말고** 행의 `max_floor_absent_reason`을 그대로 전하라(아직 동
등록 전이거나 3차 수집 전이다). `business_body`(사업주체·시공사)는 미준공 구간에서
**구조적으로 빈다** — 준공 후 등록되는 원장에만 있어 3차로도 안 메워진다.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNo사업 목록 상한 (기본 30) (허용 범위 1~100)
to_ymNoYYYYMM (기본 from_ym+60개월)
monthsNofrom_ym부터 **몇 개월**을 볼지 — to_ym 대신 쓰는 간편 인자(예: 24). to_ym과 함께 주면 오류다(realty_move_in_supply와 같은 계약) (허용 범위 1~120)
regionNo지역 — 시도·시군구·동 부분일치 (예: '세종', '세종특별자치시 합강동', '수원시'). ⚠️ 짝 도구 realty_move_in_supply의 region은 **시도 전용**이다 — 인자를 그대로 옮겨 부르지 마라
from_ymNoYYYYMM (기본 이번 달)

TDQS

A4.6/5.0
Behavior5/5

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

설명이 readOnlyHint·openWorldHint가 이미 주는 안전성뿐 아니라, 승인 목록에 기공고 단지가 남아 중복이 될 수 있다는 점, announced_notice 표식, 공고 전 but meta.announced_cross_check로 교차확인해야 한다는 점, 지구계획·공모 물량이 없어 하한값이라는 점, max_floor·business_body의 구조적 공백까지 설명한다. 데이터 해석의 함정을 넘겨주지 않는다.

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?

핵심 용도가 앞에 배치되고 각 문단이 용도·중복 경고·층수 축·빈값 처리라는 다른 임무를 맡아 과다하지 않다. 다만 ‘중복 계상’과 ‘이미 공고된 단지’ 부분이 인접해 다소 겹치고, 전체가 조금 밀도 있어 5보다는 4가 적절하다.

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?

복잡한 판단형 상담 도구이면서도 예상 공급의 시점, 데이터 원천, 주요 반환 항목(사업명·세대수·승인일·착공예정일·사용검사 예정일), 표식·행 패딩 처리, 층수·사업주체의 누락 의미까지 통합되어 있다. 파라미터가 없는 상태에서도 안전한 선택과 해석을 돕는 필수 맥락이 모두 들어갔다.

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?

스키마 설명 커버리지가 100%라 파라미터 의미는 스키마가 이미 충분히 문서화한다. 설명은 region이 realty_move_in_supply와 달라 그대로 못 옮긴다는 점 등은 스키마 안에 이미 있고, 본문은 파라미터 문법을 새로 더하지 않는다.

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?

‘아직 분양 공고가 안 난 예정 공급을 사업계획승인 기준으로 본다’처럼 특정 동사와 대상, 판단 기준이 모두 드러난다. realty_presale·realty_move_in_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?

‘지금 넣을까, 다음 걸 기다릴까’, ‘입주 폭탄이 있나’ 같은 구체적 상담 상황을 제시하고, 청약 상담이면 함께 부르라는 활용 지침이 있다. 또한 이미 공고된 단지는 realty_presale·realty_subscription_odds 영역이라고 못 박아 이 도구로 처리하면 안 되는 경우도 차단한다.

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