Skip to main content
Glama

낙찰가율 통계

realty_auction_sale_rate
Read-onlyIdempotent

"이 지역 이 물건은 보통 감정가의 몇 %에 낙찰되나"를 실제 매각결과로 답한다.

입찰가를 정할 때 쓰는 핵심 지표다. `by_fail_count`에 유찰 횟수별 분포가 들어 있어
"2회 유찰된 물건은 보통 몇 %에 낙찰되는가"를 바로 읽을 수 있다.
낙찰가율 = 낙찰가 / 감정가 × 100. 100%를 넘으면 감정가보다 비싸게 팔린 것이다.

표본의 집계 기간은 응답의 `sample_period`(매각기일 min~max)에 있다 — "요즘"류
질문에는 이 범위를 함께 전하라. 기간을 좁히는 파라미터는 백엔드가 지원하지 않는다
(요청해도 조용히 무시됨을 실측했다 — 그래서 노출하지 않는다).

usage_name에 '빌라'를 넣으면 표준 분류인 '다세대'로 자동 매핑해 집계한다(원문
'빌라'는 소수 비표준 표기 행만 잡혀 표본이 조용히 왜곡된다 — 응답에 매핑 사실이
공시된다). 연립주택 통계는 usage_name='연립주택'으로 따로 물어라.

**평형을 섞지 마라(2026-08-16 축 신설)**: 응답의 `by_area_band`가 전용면적대별
낙찰가율이다. 실측(사건 중복 제거): 아파트 전국 전체 79.2%인데 전용 59㎡ 이하 75.7%,
60~84㎡ 82.2%, 서울은 88.9% vs 97.3%다. 대상 물건의 평형을 알면 `area_band`로 좁히고,
지역 요약 하나로 입찰가를 정하지 마라. '면적 미상' 밴드는 공고에 면적 표기가 없는
사건이지 0이 아니다.

**이 축의 자리(경매 가격판단 3종 중)**: 이 %는 **감정가 대비** 통계다. 특정 물건이
실거래 **시세** 대비 싼지는 realty_compare_auction_vs_market이 자동 계산한다 —
분모가 다르니 두 %를 한 문장에 섞지 마라(감정가는 시세와 다른 시점·기준의 값이다).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sidoNo시도 — '서울'처럼 줄여 써도 되고 '서울특별시'도 된다(서버가 정식명으로 편다). 원장 표기는 서울특별시·경기도·부산광역시·세종특별자치시·강원특별자치도 같은 정식명이다. ⚠️ '광주'는 광주광역시와 경기도 광주시 둘 다라 **한쪽으로 읽지 않고 거절한다**(error='sido_ambiguous') — 광역시면 '광주광역시', 경기도 광주시면 sido='경기도'·sigungu='광주시'로 갈라 넣어라.
sigunguNo시군구 — 원장 표기 그대로 넣는다(예: '강남구', '평택시', '기장군'). 특례시·일반구는 '수원시 권선구'처럼 두 토막이다. 시도 이름을 여기 붙이지 마라('서울 강남구'는 안 맞는다) — 시도는 sido로 준다 ⚠️ 시도 없이 시군구만 주면 **합치지 않고 거절한다**(error='region_ambiguous') — '중구'처럼 여러 시도에 같은 이름이 있으면 합친 값은 어느 지역의 것도 아니다. sido와 갈라 넣어라(예: sido='서울특별시'·sigungu='중구'). 거절 응답이 후보를 준다.
area_bandNo전용면적대로 좁힌다. 낙찰가율은 평형에 따라 갈린다 — 대상 물건의 평형을 알면 반드시 넣어라(응답의 by_area_band로도 확인된다)
usage_nameNo물건 종류 — 원장 값 예: 아파트·오피스텔·다세대·연립주택·단독주택·다가구주택·근린시설·상가·대지·임야·전답. '빌라'는 표준 분류가 아니라 서버가 '다세대'로 매핑하고 그 사실을 응답에 공시한다. 비우면 전 종류아파트
bid_count_maxNo유찰 횟수 **상한**(이하). 예: 2를 주면 유찰 0·1·2회 물건의 매각결과만 집계한다. 유찰이 쌓일수록 낙찰가율이 내려가므로 대상 물건의 유찰 횟수에 맞춰 좁혀라. 비우면 유찰 횟수 무관 전체(응답의 by_fail_count에 횟수별 분포가 그대로 온다) (허용 범위 0~100)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / sigungu / description
      Previous value: -"시군구 — 원장 표기 그대로 넣는다(예: '강남구', '평택시', '기장군'). 특례시·일반구는 '수원시 권선구'처럼 두 토막이다. 시도 이름을 여기 붙이지 마라('서울 강남구'는 안 맞는다) — 시도는 sido로 준다"New value: +"시군구 — 원장 표기 그대로 넣는다(예: '강남구', '평택시', '기장군'). 특례시·일반구는 '수원시 권선구'처럼 두 토막이다. 시도 이름을 여기 붙이지 마라('서울 강남구'는 안 맞는다) — 시도는 sido로 준다 ⚠️ 시도 없이 시군구만 주면 **합치지 않고 거절한다**(error='region_ambiguous') — '중구'처럼 여러 시도에 같은 이름이 있으면 합친 값은 어느 지역의 것도 아니다. sido와 갈라 넣어라(예: sido='서울특별시'·sigungu='중구'). 거절 응답이 후보를 준다."
  2. Changed1 schema field changed
    • changedInput schema / properties / sido / description
      Previous value: -"시도 — '서울'처럼 줄여 써도 되고 '서울특별시'도 된다(서버가 정식명으로 편다). 원장 표기는 서울특별시·경기도·부산광역시·세종특별자치시·강원특별자치도 같은 정식명이다. '광주'는 광주광역시와 경기도 광주시 둘 다라 한쪽으로 읽지 않는다 — 정식명으로 넣어라"New value: +"시도 — '서울'처럼 줄여 써도 되고 '서울특별시'도 된다(서버가 정식명으로 편다). 원장 표기는 서울특별시·경기도·부산광역시·세종특별자치시·강원특별자치도 같은 정식명이다. ⚠️ '광주'는 광주광역시와 경기도 광주시 둘 다라 **한쪽으로 읽지 않고 거절한다**(error='sido_ambiguous') — 광역시면 '광주광역시', 경기도 광주시면 sido='경기도'·sigungu='광주시'로 갈라 넣어라."
  3. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -{
      -  "additionalProperties": true,
      -  "title": "realty_auction_sale_rateDictOutput",
      -  "type": "object"
      -}New value: +null
  4. Changed5 schema fields changed
    • changedInput schema / properties / bid_count_max / anyOf
      Previous value: -[
      -  {
      -    "type": "integer"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]New value: +[
      +  {
      +    "maximum": 100,
      +    "minimum": 0,
      +    "type": "integer"
      +  },
      +  {
      +    "type": "null"
      +  }
      +]
    • addedInput schema / properties / bid_count_max / description
      Added value: +"유찰 횟수 **상한**(이하). 예: 2를 주면 유찰 0·1·2회 물건의 매각결과만 집계한다. 유찰이 쌓일수록 낙찰가율이 내려가므로 대상 물건의 유찰 횟수에 맞춰 좁혀라. 비우면 유찰 횟수 무관 전체(응답의 by_fail_count에 횟수별 분포가 그대로 온다) (허용 범위 0~100)"
    • addedInput schema / properties / sido / description
      Added value: +"시도 — '서울'처럼 줄여 써도 되고 '서울특별시'도 된다(서버가 정식명으로 편다). 원장 표기는 서울특별시·경기도·부산광역시·세종특별자치시·강원특별자치도 같은 정식명이다. '광주'는 광주광역시와 경기도 광주시 둘 다라 한쪽으로 읽지 않는다 — 정식명으로 넣어라"
    • addedInput schema / properties / sigungu / description
      Added value: +"시군구 — 원장 표기 그대로 넣는다(예: '강남구', '평택시', '기장군'). 특례시·일반구는 '수원시 권선구'처럼 두 토막이다. 시도 이름을 여기 붙이지 마라('서울 강남구'는 안 맞는다) — 시도는 sido로 준다"
    • addedInput schema / properties / usage_name / description
      Added value: +"물건 종류 — 원장 값 예: 아파트·오피스텔·다세대·연립주택·단독주택·다가구주택·근린시설·상가·대지·임야·전답. '빌라'는 표준 분류가 아니라 서버가 '다세대'로 매핑하고 그 사실을 응답에 공시한다. 비우면 전 종류"
  5. Changed1 schema field changed
    • addedInput schema / properties / area_band
      Added value: +{
      +  "anyOf": [
      +    {
      +      "enum": [
      +        "59㎡이하",
      +        "60~84㎡",
      +        "85㎡초과"
      +      ],
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "전용면적대로 좁힌다. 낙찰가율은 평형에 따라 갈린다 — 대상 물건의 평형을 알면 반드시 넣어라(응답의 by_area_band로도 확인된다)",
      +  "title": "Area Band"
      +}
  6. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already mark the tool read-only and idempotent, so the description does not need to restate safety. It adds rich non-obvious behaviors: unsupported period parameters are silently ignored, '빌라' is auto-mapped to '다세대' with disclosure, '면적 미상' means missing area labels rather than zero, and the sample_period field must be reported. 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.

Conciseness4/5

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

The description is long but every paragraph carries a distinct operational warning or instruction: formula, period handling, usage_name mapping, area_band bias, and denominator distinction. The bold headers ('평형을 섞지 마라', '이 축의 자리') front-load the highest-risk guidance, making the length justified.

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 adequately explains the key response fields (sample_period, by_fail_count, by_area_band) and their interpretation. It covers the main traps an agent would need: area-band bias with empirical evidence, known data-quality issues like '빌라', and the correct relationship to a sibling tool. Nothing essential is missing for correct invocation.

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. The description adds real value beyond the schema: bid_count_max is clarified as an upper bound with the trend that more failures lower the ratio, area_band is strongly recommended when the property size is known, and usage_name's '빌라' mapping behavior and pitfalls are explained.

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 the exact user question the tool answers — '이 지역 이 물건은 보통 감정가의 몇 %에 낙찰되나' — and defines the metric formula (낙찰가율 = 낙찰가 / 감정가 × 100). It clearly distinguishes itself from realty_compare_auction_vs_market by emphasizing the appraisal-based denominator, which prevents confusion with the market-comparison sibling.

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 explicitly states when to use the tool ('입찰가를 정할 때 쓰는 핵심 지표'), tells the agent to include sample_period in '요즘'-type answers, warns that period-narrowing parameters are unsupported, and directs 연립주택 queries to usage_name='연립주택'. It also names the alternative tool for market-price comparisons and instructs not to mix the two percentages.

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.