Skip to main content
Glama

청약 분양 공고

realty_presale
Read-onlyIdempotent

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

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

price_min/price_max는 주택형별 분양 최고가의 최소·최대(만원)다 — 한 공고에 여러
주택형(house_type_count)이 있다. 청약 자격·순위 요건은 이 데이터에 없다(지어내지 말 것).
경쟁률·당첨 가점 커트라인은 realty_subscription_odds 도구에 있다. 행마다 `rank1_result`(1순위
해당지역 결과 요약 — status·undersubscribed_types/total_types·shortfall_households·verdict_text)가
붙는다: status가 published가 아니면 **미달 여부를 모른다**는 뜻이지 경쟁이 있었다는 뜻이 아니다.

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

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

Input Schema

NameRequiredDescriptionDefault
limitNo공고 수 — 주택형별 분양가·순위별 일정이 붙어 행이 무겁다. 요청분을 다 실으면 응답이 크기 상한을 넘는 경우 **실제 반환 수를 줄이고 meta.size_capped**에 총계·좁혀 부르는 법을 값으로 싣는다 — 조용히 자르지 않는다 (허용 범위 1~50)
sinceNo이 날짜(YYYY-MM-DD, 31일 전까지) 이후 바뀐 것만 — 예약 실행에서 '어제 이후'면 since=어제. 기준·지연은 응답에
regionNo시도 (예: 서울, 경기, 세종, 부산)
statusNo오늘(KST) 기준 접수 상태로 거른다. **'오늘/지금 접수 가능한', '지금 넣을 수 있는' 질문은 '접수중'이다** — '접수예정'은 아직 못 넣는 것들이다. '다음 달 청약'처럼 앞으로를 묻는 질문만 '접수예정'. 기본 '전체'.전체
keywordNo단지명·공급 주소 부분일치 (예: '우미린', '5-2생활권', '다솜동') — 생활권·동 단위 질의는 이걸로
sigunguNo시군구 정확한 이름 (예: 수원시, 강남구). ⚠️세종은 이 필드가 동·생활권·도로명으로 오염돼 있으니 쓰지 말고 keyword를 쓰라
questionNo(선택) 이 조회를 하게 된 사용자 질문 한 문장 — 맞는 다른 축·도구를 question_routing으로 돌려준다. 이름·연락처는 빼라
upcomingNo⚠️True면 접수 **시작 전**(시작일이 오늘 이후, 오늘 시작 포함) 공고만 — 어제 이전에 시작해 **접수 중인 공고는 여기 없다**. 오늘 넣을 수 있는 것을 찾는다면 status='접수중'을 써라. status와 함께 쓰지 말 것(status가 이것을 대체한다).
notice_kindNo공고 종류. 기본 '본공고'. 무순위(줍줍)·재공급을 물으면 그 값 — status 기본은 접수중+접수예정이고, '접수마감'이면 목록 대신 단지별 회차 이력 집계(몇 번 나왔나).본공고

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / upcoming / description
      Previous value: -"⚠️True면 접수 **시작 전**(시작일이 오늘 이후) 공고만 — **오늘 접수 가능한 공고는 여기 없다**. 오늘 넣을 수 있는 것을 찾는다면 status='접수중'을 써라. status와 함께 쓰지 말 것(status가 이것을 대체한다)."New value: +"⚠️True면 접수 **시작 전**(시작일이 오늘 이후, 오늘 시작 포함) 공고만 — 어제 이전에 시작해 **접수 중인 공고는 여기 없다**. 오늘 넣을 수 있는 것을 찾는다면 status='접수중'을 써라. status와 함께 쓰지 말 것(status가 이것을 대체한다)."
  2. Changed1 schema field changed
    • addedInput schema / properties / question
      Added value: +{
      +  "default": "",
      +  "description": "(선택) 이 조회를 하게 된 사용자 질문 한 문장 — 맞는 다른 축·도구를 question_routing으로 돌려준다. 이름·연락처는 빼라",
      +  "title": "Question",
      +  "type": "string"
      +}
  3. Changed1 schema field changed
    • addedInput schema / properties / since
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "이 날짜(YYYY-MM-DD, 31일 전까지) 이후 바뀐 것만 — 예약 실행에서 '어제 이후'면 since=어제. 기준·지연은 응답에",
      +  "title": "Since"
      +}
  4. Changed1 schema field changed
    • addedInput schema / properties / notice_kind
      Added value: +{
      +  "default": "본공고",
      +  "description": "공고 종류. 기본 '본공고'. 무순위(줍줍)·재공급을 물으면 그 값 — status 기본은 접수중+접수예정이고, '접수마감'이면 목록 대신 단지별 회차 이력 집계(몇 번 나왔나).",
      +  "enum": [
      +    "본공고",
      +    "무순위",
      +    "불법행위 재공급",
      +    "무순위·재공급"
      +  ],
      +  "title": "Notice Kind",
      +  "type": "string"
      +}
  5. Changed1 schema field changed
    • changedInput schema / properties / limit / description
      Previous value: -"(허용 범위 1~50)"New value: +"공고 수 — 주택형별 분양가·순위별 일정이 붙어 행이 무겁다. 요청분을 다 실으면 응답이 크기 상한을 넘는 경우 **실제 반환 수를 줄이고 meta.size_capped**에 총계·좁혀 부르는 법을 값으로 싣는다 — 조용히 자르지 않는다 (허용 범위 1~50)"
  6. Changed2 schema fields changed
    • addedInput schema / properties / status
      Added value: +{
      +  "default": "전체",
      +  "description": "오늘(KST) 기준 접수 상태로 거른다. **'오늘/지금 접수 가능한', '지금 넣을 수 있는' 질문은 '접수중'이다** — '접수예정'은 아직 못 넣는 것들이다. '다음 달 청약'처럼 앞으로를 묻는 질문만 '접수예정'. 기본 '전체'.",
      +  "enum": [
      +    "전체",
      +    "접수중",
      +    "접수예정",
      +    "접수마감"
      +  ],
      +  "title": "Status",
      +  "type": "string"
      +}
    • changedInput schema / properties / upcoming / description
      Previous value: -"True면 청약 접수 시작일이 오늘 이후인 공고만"New value: +"⚠️True면 접수 **시작 전**(시작일이 오늘 이후) 공고만 — **오늘 접수 가능한 공고는 여기 없다**. 오늘 넣을 수 있는 것을 찾는다면 status='접수중'을 써라. status와 함께 쓰지 말 것(status가 이것을 대체한다)."
  7. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -{
      -  "additionalProperties": true,
      -  "title": "realty_presaleDictOutput",
      -  "type": "object"
      -}New value: +null
  8. Changed1 schema field changed
    • addedInput schema / properties / limit / description
      Added value: +"(허용 범위 1~50)"
  9. Changed3 schema fields changed
    • addedInput schema / properties / keyword
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "단지명·공급 주소 부분일치 (예: '우미린', '5-2생활권', '다솜동') — 생활권·동 단위 질의는 이걸로",
      +  "title": "Keyword"
      +}
    • changedInput schema / properties / region / description
      Previous value: -"시도 (예: 서울, 경기, 부산)"New value: +"시도 (예: 서울, 경기, 세종, 부산)"
    • changedInput schema / properties / sigungu / description
      Previous value: -"시군구 정확한 이름 (예: 수원시, 강남구)"New value: +"시군구 정확한 이름 (예: 수원시, 강남구). ⚠️세종은 이 필드가 동·생활권·도로명으로 오염돼 있으니 쓰지 말고 keyword를 쓰라"
  10. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already cover safety (readOnly/idempotent/non-destructive), and the description goes far beyond them: apply_status/apply_status_text are pre-judged against meta.today and must not be re-derived, rank1_result=published-false means unknown (not 'no competition'), unsold_history absence is not proof of no history, and regulation flags are announcement-date snapshots that must not be asserted as current. This is unusually rich disclosure.

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-loads the purpose and the answer-shaping rule (status='접수중') before the caveats, and every paragraph maps to a real failure mode. It is dense and long, with some redundancy against the schema's own parameter descriptions, but no sentence is filler.

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 the tool has 9 params with layered output fields, yet the description explains the returned status fields, the rank1_result semantics, the unsold_history caveats and the routing fields (meta.today, house_manage_no, question_routing). Nothing an agent needs to call or interpret it is missing.

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 100%, so the baseline is 3, but the description adds interpretation beyond the schema: status and upcoming are mutually exclusive and status supersedes upcoming, notice_kind='접수마감' switches the response from a list to per-complex 회차 집계, and price_min/price_max are per-house-type extremes. Much of this is mirrored in the schema, so it is not fully additive, but the aggregation behavior adds real meaning.

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?

Opens with a specific verb+resource (아파트 청약(분양) 공고를 조회한다) and enumerates the returned fields (분양가·접수 일정·당첨자 발표일·입주 예정·위치). It also names the siblings it is NOT — realty_presale_vs_market, realty_subscription_odds, realty_presale_price_trend, realty_notice_facts — so an agent can separate it 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?

Explicitly routes questions: '오늘/지금 접수 가능한' → status='접수중', upcoming=true only covers pre-start notices, '넣을 만해?' → hand off to realty_presale_vs_market, 경쟁률 → realty_subscription_odds, 추이 → realty_presale_price_trend, 원문 규제 → realty_notice_facts. When-to-use and when-to-use-something-else are both stated.

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.