Skip to main content
Glama

korea-realty

by app.sallim
OverviewAdmin

분양 공고 견주기 — 같은 시군구·평형 공고들과의 5축 비교(공고 원문 축)

realty_presale_context
Read-onlyIdempotent

이 분양 공고를 같은 시군구·같은 평형 공고들과 견줘 읽는다 — 청약홈 API에 없고 공고문 원문에만 있는 5축으로: ①대지비 비중(분양가에서 땅값이 얼마인가) ②유상옵션 (사실상 필수인 발코니확장 절대금액) ③중도금 무이자 여부와 회차 ④층 프리미엄(최저 층구간 대비 최상 층구간) ⑤㎡당 분양가(전용면적 기준).

"이 분양가가 비싼가"는 실거래 대조만으로는 반쪽이다 — 같은 값이라도 대지비 비중이
70%인 공고와 25%인 공고는 다른 물건이고, 발코니확장 3천만원은 광고 분양가에 안 잡힌다.
공고를 지정하면 그 공고의 5축 값과 **분포에서의 위치(percentile)**를 주고, 지정하지
않으면 시군구·평형 슬라이스의 분포만 준다.

읽는 법(그대로 지켜야 값이 거짓이 되지 않는다):
· **셀 표본이 3건 미만이면 분위를 안 낸다** — 그때 `verdict`가 '표본 부족'이고,
  그것이 답이다. **시도 값(background)으로 갈아타지 마라**(D-2026W33-40).
· **연도를 자르지 않은 시계열을 그리지 마라** — 팩트시트 커버율이 연도마다 20배 이상
  갈린다(meta.coverage.by_year). 연도 간 분양가 추이는 realty_presale_price_trend다.
· 중도금 `unknown`은 '이자 있음'이 아니라 '판정 못 했다'다(n_known/n_unknown이 갈려 있다).
· ㎡당 분양가는 **전용면적** 기준이라 공급면적 평당가와 같은 축에 놓으면 안 된다.

이 축의 자리: 개별 공고의 값 자체(전매제한·자격·층별 표 전문)는 realty_notice_facts,
원문 조항은 realty_notice_text, 분양가 대 실거래 적정성은 realty_presale_vs_market,
연도별 분양가 추이는 realty_presale_price_trend — 이 도구는 **공고끼리의 횡단면**이다.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
regionNo시도 (예: 경기, 서울, 경남). **시도 분포는 배경일 뿐 결론 근거가 아니다**(D-2026W33-40) — 결론은 시군구·평형대 셀에서 읽어라
keywordNo단지명 일부 (예: '우미린' — 공백 무관 매칭). house_manage_no와 택일이며 여럿이면 후보 목록을 돌려준다
sigunguNo시군구를 원장 어휘 그대로 (예: '천안시 서북구', '평택시', '서울 동작구' — 특별·광역시는 '서울 동작구'처럼 시도 접두가 붙는다). 공고를 지정하지 않고 그 지역 분포만 볼 때 쓴다
house_manage_noNo공고 관리번호 (realty_presale·realty_notice_facts 응답의 house_manage_no, 예 '2026000383')
exclusive_m2_maxNo전용면적 상한(㎡) — 국평만 보려면 85
exclusive_m2_minNo전용면적 하한(㎡) — 국평만 보려면 80. 지정하면 모든 셀에 같은 필터가 걸린다

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Added

TDQS

A4/5.0
Behavior3/5

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

Annotations mark it read-only, idempotent, non-destructive, and open-world. The description adds behavioral context such as '표본 부족' verdicts and how missing data is reported, but it doesn't explicitly describe what happens in edge cases like multiple keyword matches (beyond saying candidates list is returned) or zero matches. Overall it provides some added transparency consistent with the open-world and read-only hints.

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 fairly long but every sentence earns its place: it explains the five axes, the danger of misreading the data, the exact reading rules, and positions the tool among its siblings. The only minor dent is its length and the slight repetition of the five-axis list toward the end.

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?

For a no-output-schema tool with 6 parameters and no required parameters, the description is remarkably complete. It explains what output to expect (five-axis values and percentiles, or distribution only if no notice is given), what the verdict means, and where to find alternative tools for neighboring questions. Nothing essential is missing.

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%, so the baseline is 3. Every parameter has a functional description. The tool's description text reinforces how parameters interact (e.g., '지정하면 모든 셀에 같은 필터가 걸린다' for exclusive_m2_min/max), but description-level semantics mostly mirror the schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the tool as a comparative analysis of presale notices across five axes (land cost ratio, optional balcony expansion, mid-term loan interest, floor premium, and per-㎡ price). However, unlike the high-water mark of sibling tools like get_calls, it doesn't explicitly name which sibling it is NOT; instead it lists sibling alternatives only at the end, leaving some differentiation implicit.

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 goes beyond merely stating when to use it and provides explicit 'how to read' rules — including when NOT to substitute background data (D-2026W33-40), when not to plot yearly time series (meta.coverage.by_year), how to interpret 'unknown' mid-term loan values, and a caution about per-㎡ price being based on exclusive area. This is outstanding guidance compared to most definitions.

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.

Resources