Skip to main content
Glama

청약 경쟁률·당첨 가점 — 내 가점으로 되나

realty_subscription_odds
Read-onlyIdempotent

청약 경쟁률과 실제 당첨 가점 커트라인을 낸다 — "나 가점 52점인데 당첨될까?"의 정량 근거. 가점 자체를 모르는 사용자는 realty_subscription_score(무주택·부양가족·가입기간 선언 → 배점표 적용)로 먼저 점수를 만들어 my_score로 넘겨라.

**비어 있으면 왜 비었는지부터 읽어라(2026-08-20 축 신설).** 이 축의 원천은 주 1회 전량 수집
이라 "아직 공표가 안 됐다"와 "공표는 됐는데 우리가 아직 안 걷었다"가 똑같이 빈 배열로
보인다 — 실측(공고 2026000323)에서 청약홈엔 1순위 경쟁률 4.33·12.90·15.55가 이미
공표됐는데 우리 응답은 by_house_type=[]였다. `freshness_verdict.verdict`가 그 둘을
가른다(아래 큰따옴표는 **필드가 아니라 그 필드의 값**이다): "not_yet_published"(접수가
안 끝났다 — 없는 게 정상) · "not_yet_collected"(**우리 미수집이다. 절대 '경쟁률이 없다'고
답하지 말고 check_url로 안내하라**) · "unknown"(못 가른다) · "not_published" ·
"collected". 대조 재료인 접수 종료일은
announcement.rcept_endde·freshness_verdict.apply_end에 있다.
result_status의 뜻은 응답의 `result_status_legend`가 정본이다(`special_only`는 일반공급
결과가 아직인데 특별공급 신청현황만 온 상태 — '결과 없음'이 아니다).

**없는 공고는 '미발표'가 아니다(2026-09-08, T-2026W37-81).** house_manage_no가 경쟁률 원장에도
분양 공고 원장에도 없으면 `error` 응답(`result` 값 "not_found")으로 거절하고 벤치마크를
내지 않는다 — 종전엔 어떤 번호를 넣어도 "not_published"+"아직 발표되지 않았다"가 나가
오타·가상 번호가 '접수 전 공고'로 둔갑했다. 원장 조회 자체가 실패하면(404 아닌 오류·
시간 초과) 그것도 "not_published"가 아니라 거절 응답이다 — 거절에는 정상 응답에 **없는**
`error`·`result` 두 키가 붙고 그 값이 "lookup_failed"다.
**여기서 백틱은 필드 이름이고 큰따옴표는 값이다** — "lookup_failed"·"not_found"라는
이름의 키는 어느 응답에도 없다(찾지 마라). 지역 벤치마크만 필요하면 house_manage_no
없이 region·sigungu로 부르라.

**지역별 경쟁률의 분모는 추정하지 말고 `allocated_households_rank1_local`을 써라
(2026-08-21 신설).** 공표 경쟁률은 (그 지역구분 신청 ÷ 배정 세대수)라 분모를 되돌릴 수
있고, 해당지역 1순위 행의 98.3%에서 그 분모가 정수 하나로 특정된다(전수 실측). 되찾지
못한 행은 그 값이 null이고 `allocated_households_basis.range`에 구간만 있다 —
그때는 세대수로 단정하지 마라. 공고 원문 비율로 만든 `regional_priority.
estimated_allocation.est_*`는 **실측이 있는 행에서 쓰면 안 된다**(실측과 어긋나면
`estimate_superseded`가 붙는다 — 실측 2026000323 084.9165A: 추정 47 vs 실측 78세대).

두 가지 경로를 자동으로 고른다:
  1) 결과가 발표된 공고 → 그 단지의 주택형별 1순위 해당지역 경쟁률·당첨 최저/평균/최고 가점.
  2) 아직 접수 전이라 결과가 없는 단지 → 같은 지역 최근 공고들의 실제 커트라인 분포
     (regional_benchmark). **다른 단지의 실적이다** — 질의 단지의 예상 커트라인이
     아니라는 점을 반드시 함께 말하라. 분위수를 인용하기 전에
     distinct_complex_count·samples_by_complex를 먼저 보라 — 단지가 1~2곳이면
     그건 지역 분포가 아니라 한 단지 안의 주택형 편차다
     (warning_sample_concentration이 붙는다).

**시도 하나로 답하지 마라(2026-08-16 축 신설).** 아파트는 시군구·평형·시기·가격대로 갈린다 —
실측(서울 최근 2년): 은평 전용 59㎡ 커트라인 중앙 45점 vs 강남 59㎡ 74점(29점 차),
연도별 중앙값 2022년 50점 → 2025년 69점, 2025년 분기별 69/66.5/56/70.
그래서 "내 가점으로 어디까지 되나"류에는 breakdown='sigungu'(+ area_band, 예산이 있으면
budget_max_10k)를, "언제가 쌌나"류에는 breakdown='quarter'|'year'를 써라.
사용자가 예산을 말했는데 budget_max_10k를 안 넣으면 **살 수 없는 단지가 섞인 답**이 나간다.

지어내지 말 것: 이 도구는 당첨 확률을 계산하지 않는다(가점 동점자 처리·특별공급 비율·
추첨제 물량은 데이터에 없다). 낼 수 있는 건 "과거 커트라인 대비 내 점수의 위치"까지다.
커트라인이 null인 칸은 0점이 아니라 당첨자 없음/가점제 미적용이다(score_status 참조).
분양가가 적정한지까지 물으면 realty_presale_vs_market을 이어서 쓰라.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
regionNo시도 (예: 서울, 경기, 세종)
keywordNo단지명·주소 부분일치 (예: '월계 중흥')
sigunguNo시군구 정확한 이름 (예: 노원구, 수원시). 벤치마크를 좁힐 때 쓴다 — 표본이 0이면 시도 단위로 넓혀라
my_scoreNo내 청약 가점(0~84점). 주면 실제 커트라인과 점수 차를 계산해 준다 (허용 범위 0~84)
area_bandNo전용면적대로 좁힌다. 같은 구 안에서도 평형이 바뀌면 커트라인이 움직인다(실측: 노원 59㎡ 58.5점 vs 60~84㎡ 59점, 동작은 반대로 84㎡ 62점·59㎡ 64점)
breakdownNo분포를 쪼갤 축. **시도 하나로 답하지 마라** — 서울 은평 전용 59㎡ 커트라인 중앙 45점, 강남 59㎡ 74점으로 같은 시도 안에서 29점이 갈린다. '어디까지 되나'류 질문에는 sigungu, '언제가 쌌나'는 quarter·year를 쓴다
since_yearsNo지역 벤치마크에 쓸 최근 기간(년). 커트라인은 시장 사이클을 타므로 기본 3년 (허용 범위 1~6)
budget_max_10kNo예산 상한 — 분양 최고가(만원) 기준. 사용자가 '9억까지'라고 하면 90000. 가점만으로 답하면 살 수 없는 단지가 섞인다
budget_min_10kNo예산 하한(만원)
house_manage_noNorealty_presale 응답의 공고 관리번호 — 알면 이걸로 특정하는 게 정확

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -{
      -  "additionalProperties": true,
      -  "title": "realty_subscription_oddsDictOutput",
      -  "type": "object"
      -}New value: +null
  2. Changed2 schema fields changed
    • changedInput schema / properties / my_score / description
      Previous value: -"내 청약 가점(0~84점). 주면 실제 커트라인과 점수 차를 계산해 준다"New value: +"내 청약 가점(0~84점). 주면 실제 커트라인과 점수 차를 계산해 준다 (허용 범위 0~84)"
    • changedInput schema / properties / since_years / description
      Previous value: -"지역 벤치마크에 쓸 최근 기간(년). 커트라인은 시장 사이클을 타므로 기본 3년"New value: +"지역 벤치마크에 쓸 최근 기간(년). 커트라인은 시장 사이클을 타므로 기본 3년 (허용 범위 1~6)"
  3. Changed4 schema fields changed
    • addedInput schema / properties / area_band
      Added value: +{
      +  "anyOf": [
      +    {
      +      "enum": [
      +        "59㎡이하",
      +        "60~84㎡",
      +        "85㎡초과"
      +      ],
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "전용면적대로 좁힌다. 같은 구 안에서도 평형이 바뀌면 커트라인이 움직인다(실측: 노원 59㎡ 58.5점 vs 60~84㎡ 59점, 동작은 반대로 84㎡ 62점·59㎡ 64점)",
      +  "title": "Area Band"
      +}
    • addedInput schema / properties / breakdown
      Added value: +{
      +  "anyOf": [
      +    {
      +      "enum": [
      +        "sigungu",
      +        "area_band",
      +        "quarter",
      +        "year"
      +      ],
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "분포를 쪼갤 축. **시도 하나로 답하지 마라** — 서울 은평 전용 59㎡ 커트라인 중앙 45점, 강남 59㎡ 74점으로 같은 시도 안에서 29점이 갈린다. '어디까지 되나'류 질문에는 sigungu, '언제가 쌌나'는 quarter·year를 쓴다",
      +  "title": "Breakdown"
      +}
    • addedInput schema / properties / budget_max_10k
      Added value: +{
      +  "anyOf": [
      +    {
      +      "minimum": 0,
      +      "type": "integer"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "예산 상한 — 분양 최고가(만원) 기준. 사용자가 '9억까지'라고 하면 90000. 가점만으로 답하면 살 수 없는 단지가 섞인다",
      +  "title": "Budget Max 10K"
      +}
    • addedInput schema / properties / budget_min_10k
      Added value: +{
      +  "anyOf": [
      +    {
      +      "minimum": 0,
      +      "type": "integer"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "예산 하한(만원)",
      +  "title": "Budget Min 10K"
      +}
  4. Added

TDQS

A4.9/5.0
Behavior5/5

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

Even though annotations already mark this as read-only/idempotent, the description discloses important runtime behavior: empty arrays can mean either not_yet_published or not_yet_collected, disambiguated by freshness_verdict.verdict; not-found and lookup-failed produce error responses with distinct error/result values; estimate_superseded is attached when estimates conflict with actuals; and null cutoffs mean no winners/no point system, not zero points. It also explicitly states the tool does not calculate win probability, preventing a common LLM hallucination.

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 text is long, but it is front-loaded with the core purpose and organized into bolded warning blocks, numbered pathways, and a 'don't fabricate' section, so an agent can locate the relevant guidance quickly. It earns most of its length given the tool's complexity and missing output schema, though a few dated changelog asides could be trimmed for tightness.

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?

With no output schema, the description carries the full burden of explaining response semantics, and it does: freshness_verdict verdict values, result_status_legend as canon, error/result keys on rejection, allocated_households_rank1_local as denominator source, sample-concentration warnings, and estimate_superseded behavior. The two operational paths and their data caveats are fully covered, so an agent has what it needs to interpret results correctly.

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

Parameters5/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, but the description adds substantial parameter-level guidance beyond the schema: my_score should come from realty_subscription_score if unknown, breakdown must be sigungu/quarter/year depending on question type, omitting budget_max_10k when a budget was stated can mix in unaffordable complexes, and house_manage_no absent from both ledgers must produce a not_found rejection rather than 'not published'. This transforms raw parameter names into decision rules.

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 opens with a specific verb and resource: it computes 청약 경쟁률 and 실제 당첨 가점 커트라인, and frames them as the quantitative basis for 'will my 52-point score win?'. It also names the sibling realty_subscription_score for users who need to compute their score first, so an agent can distinguish this tool from related subscription tools.

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 gives explicit routing conditions: if the user doesn't know their score, use realty_subscription_score and pass my_score; if only a regional benchmark is needed, call without house_manage_no using region/sigungu; and for price reasonableness, continue to realty_presale_vs_market. It also explains when the tool falls back from published results to regional benchmarks, and warns against treating missing data as 'not published', which is exactly when/not-to-use guidance.

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.