Skip to main content
Glama

korea-realty

by app.sallim

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

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`는 일반공급
결과가 아직인데 특별공급 신청현황만 온 상태 — '결과 없음'이 아니다).

**지역별 경쟁률의 분모는 추정하지 말고 `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 응답의 공고 관리번호 — 알면 이걸로 특정하는 게 정확

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the readOnly/openWorld/idempotent annotations, the description discloses high-cost nuances: empty arrays are not uniformly 'results exist' — urgency between not_yet_published vs not_yet_collected; the regional_benchmark path is another complex's history (not an estimate for the asked complex); '경쟁률이 없다' must not be said on stale data (route to check_url); the tool does not compute winprob; null cutoff ≠ 0. This is behavior transparency that equals or exceeds expected for a data-query tool, and mentions every identifiable pitfall in advance. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The text is front-loaded (purpose comes first) but is long and heavily redundant: the 29-p이 강남 은평 59㎡ vs 74점 example appears twice (in the 본문 and in the breakdown parameter description), dated change-metadata headers (2026-08-20 축 신설, 2026-08-21 신설, 2026-08-16 축 신설) add noise without agent value, and the same advice about not misinterpreting missing data is repeated in several paragraphs. Each paragraph's content is substantive, but with paragraphs could be halved if duplicate examples and date stamps were removed.

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 a non-zero output schema (none provided), the description carries the responsibility of naming response fields, and it does: freshness_verdict.verdict, announcement.rcept_endde, result_status_legend, allocated_households_basis.range, regional_priority.estimated_allocation.est_was, sample concentration tokens, check_url guidance, and null values via score_status. Every risk situation (empty result, no denominator, superseded estimate, 1–2 complex samples, budget missing) has a rule and fallback. An agent's invocation flow is fully specified from routing to interpretation.

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

Parameters4/5

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

Schema coverage is already 100% and each parameter has a meaningful description (значен: 신규 exactly '9월 → 90000'; my_score 'calculate deficit to actual cutoff; budget '가점만으로 답하면 살 수 없는 단지가 섞인다'). The global description adds further semantic value by connecting parameters (if user gives budget → set budget_max_10k; if score unknown → route to realty_subscription_score then fill my_score; if zero sample in sigungu → widen to 시도). Baseline 3 + full coverage and these bonuses → 4. Not 5 because the schema already carries most per-parameter meaning, global descriptions mainly reinforce a few.

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 opening line states a specific deliverable with a concrete verb and resource: '청약 경쟁률과 실제 당첨 가점 커트라인을 낸다' — computes competition rate and actual winning score cutoffs, anchored by the user's exact question ('나 가점 52점인데 당첨될까?'). It also distinguishes itself from realty_subscription_score (score generation, via an explicit routing instruction) and from realty_presale_vs_market (price-appropriateness chain). No ambiguity remains about what this tool computes.

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 gives explicit when-to-use and when-not-to-use instructions: routes users (without score) to realty_subscription_score first; tells how to choose breakdown='sigungu' vs 'quarter'/'year'; requires budget_max_10k when the user mentioned a budget; specifies the pair path selection (results-announced vs pre-application); and commands '지어내지 말 것' for what the tool cannot do (won-pronidity), transitioning to realty_presale_vs_market. Each guidance is coupled to a named alternative or condition.

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