Skip to main content
Glama

korea-realty

by app.sallim

청약 분양 공고

realty_presale
Read-onlyIdempotent

아파트 청약(분양) 공고를 조회한다 — 분양가·청약 접수 일정·당첨자 발표일·입주 예정·위치. "다음 달 청약 넣을 만한 데 있어?", "○○에 분양하는 아파트 있어?"류 질문용.

**"오늘/지금 접수 가능한 청약"은 status='접수중'이다.** upcoming=true는 접수 **시작 전**만
주므로 그 질문에 쓰면 정확히 **오늘 못 넣는 공고들**을 받는다(2026-08-22 실사고: 접수가
이틀 뒤 시작하는 공고를 "현재 접수 가능"으로 답했다). 행마다 오늘 기준 판정
`apply_status`(접수중/접수예정/접수마감/일정미상)와 `apply_status_text`가 붙고, 그 기준일은
meta.today다 — **날짜를 직접 비교해 상태를 다시 판정하지 말고 이 값을 그대로 전하라.**
"넣을 만해?/적정가야?"까지 물으면 이어서 realty_presale_vs_market으로 분양가를
실거래 시세와 대조하라(응답의 house_manage_no가 그 도구의 입력이다).

price_min/price_max는 주택형별 분양 최고가의 최소·최대(만원)다 — 한 공고에 여러
주택형(house_type_count)이 있다. 청약 자격·순위 요건은 이 데이터에 없다(지어내지 말 것).
경쟁률·당첨 가점 커트라인은 realty_subscription_odds 도구에 있다.

무순위(줍줍)·취소재공급이 돈 공고에는 `unsold_history`(회차·세대)가 붙는다 — 접수
경쟁률이 높아도 무순위가 돌았다면 "당첨 후 계약이 안 된" 시장이다. 없다고 이력이
없던 건 아니다(meta.unsold_note의 연결 한계 참조). 같은 지역 공고들의 분양가가
올라온 추이("기다림의 비용")는 realty_presale_price_trend.

규제지역 플래그: speculation_zone(투기과열지구)·adjustment_area(조정대상지역)·
price_cap_applied(분양가상한제), Y/N — **모집공고일(announced_on) 기준 스냅샷**이라
이후 지정·해제가 바뀔 수 있다. "현재 규제지역"으로 단정하지 말고 공고일과 함께 전하라.
전매제한·거주의무 기간은 이 데이터에 없다(플래그에서 유추 금지) —
realty_notice_facts가 공고 원문 값을 쪽 번호와 함께 준다.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNo공고 수 — 주택형별 분양가·순위별 일정이 붙어 행이 무겁다. 요청분을 다 실으면 응답이 크기 상한을 넘는 경우 **실제 반환 수를 줄이고 meta.size_capped**에 총계·좁혀 부르는 법을 값으로 싣는다 — 조용히 자르지 않는다 (허용 범위 1~50)
regionNo시도 (예: 서울, 경기, 세종, 부산)
statusNo오늘(KST) 기준 접수 상태로 거른다. **'오늘/지금 접수 가능한', '지금 넣을 수 있는' 질문은 '접수중'이다** — '접수예정'은 아직 못 넣는 것들이다. '다음 달 청약'처럼 앞으로를 묻는 질문만 '접수예정'. 기본 '전체'.전체
keywordNo단지명·공급 주소 부분일치 (예: '우미린', '5-2생활권', '다솜동') — 생활권·동 단위 질의는 이걸로
sigunguNo시군구 정확한 이름 (예: 수원시, 강남구). ⚠️세종은 이 필드가 동·생활권·도로명으로 오염돼 있으니 쓰지 말고 keyword를 쓰라
upcomingNo⚠️True면 접수 **시작 전**(시작일이 오늘 이후) 공고만 — **오늘 접수 가능한 공고는 여기 없다**. 오늘 넣을 수 있는 것을 찾는다면 status='접수중'을 써라. status와 함께 쓰지 말 것(status가 이것을 대체한다).

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already mark it read-only/idempotent/non-destrictive, and the description adds substantial caveats beyond that: apply_status is pre-computed against meta.today and must be passed through rather than re-derived from dates; regulation flags are a snapshot as of announced_on and must not be presented as current; qualification/priority and resale-restriction data are intentionally absent and must not be invented or inferred; unsold_history absence is not evidence that no unsold occurred. No statement contradicts the annotations.

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 long but front-loads the most danerous usage error (upcoming vs status='접수중') and each paragraph covers a distinct pitfall or sibling distinction, with no filler sentences. It loses a point because some status/upcoming caveats are repeated from the parameter schema and output-field explanations add length that would normally live in an output schema.

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 read-only tool with no output schema, the description covers what the tool returns (apply_status, meta.today, unsold_history, regulation flags), what it deliberately lacks (qualifications, resale restrictions), and how to route each follow-up intent to the correct sibling tool. The only minor omission is a concrete call example, which is not critical given the already-rich parameter schema.

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; all six input params are already thoroughly documented in the schema, including the status/upcoming pitfall. The description mostly reinforces those warnings (e.g., '오늘/지금 접수가능한 청약'은 status='접수중') rather than adding genuinely new parameter-level meaning. It does add useful non-parameter context like price_min/max being across housing types and the size_capped behavior, but those relate more to output interpretation than to input semantics.

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?

States the exact resource '아파트 청약(분양) 공고' and the specific verb '조회한다' (retrieves), and enumerates key fields (분양가·청약 접수 일정·당첨자 발표일·입주 예정·위치). It also distinguishes itself from siblings by explicitly naming realty_presale_vs_market, realty_subscription_odds, realty_presale_price_trend, and realty_notice_facts for different facets of presale data.

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?

Gives explicit question patterns that should trigger this tool ('다음 달 청약 넣을 만한 데 있어?', '○○에 분양하는 아파트 있어?') and explicit exclusions: '오늘/지금 접수 가능' 질문은 status='접수중'이지 upcoming=true가 아니며, real incident 2026-08-22를 근거로 든다. It also routes follow-up intents to specific siblings — realty_presale_vs_market for price comparison, realty_subscription_odds for competition rate/qualification, realty_notice_facts for resale restrictions, realty_presale_price_trend for regional price trends.

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