Skip to main content
Glama

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

realty_presale_context
Read-onlyIdempotent

이 분양 공고를 같은 시군구·같은 평형의 다른 공고들과 5축으로 견준다.

이 분양 공고를 **같은 시군구·같은 평형 공고들과 견줘** 읽는다 — 청약홈 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.

  1. Added

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description goes well beyond them: minimum sample threshold of 3 with a '표본 부족' verdict, n_known/n_unknown split for 중도금, coverage disparity across years (meta.coverage.by_year), and percentile-in-distribution output. This is rich behavioral context an agent could not infer.

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 comparison, then a clearly delimited '읽는 법' rules block and a positioning paragraph — easy to scan. Minor redundancy: the title and the first two sentences restate the same 'compare to same sigungu/pyeong notices' framing.

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 and all six params are optional, yet the description explains return shape (five-axis values plus percentile, or distribution-only), edge-case verdicts, and interpretation caveats. Nothing needed to call or interpret the tool correctly 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 schema already documents all six parameters including the keyword/house_manage_no tradeoff and the exclusive_m2 filter scope. The description reinforces semantics (region is background only, exclusive area basis) but adds little parameter-level detail the schema lacks; baseline 3 applies.

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?

Names a specific verb (견준다/compare) and resource (분양 공고 vs 같은 시군구·평형 공고들), then enumerates the five exact axes compared. It explicitly positions itself against siblings (realty_notice_facts, realty_notice_text, realty_presale_vs_market, realty_presale_price_trend), so an agent can route without opening any 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?

States when to use it, what it returns with and without a notice specified, and several explicit 'do not' rules: don't fall back to 시도 background values when a cell has <3 samples, don't build year-spliced time series, use realty_presale_price_trend for yearly trend. Alternatives are named with the condition that selects them.

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.