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

TDQS

A5/5.0
Behavior5/5

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

Annotations already mark the tool as readOnly, idempotent, and non-destructive, and the description goes beyond by disclosing subtle behavioral traits: date-range narrowing parameters are silently ignored (a deliberately omitted parameter), '빌라' is auto-mapped to '다세대' with the mapping disclosed in the response to prevent sample distortion, and the meaning of '면적 미상' band is clarified as not zero. It also discloses actual measured sample data and a 2026-08-16 update, giving the agent a clearer sense of what the response might look like.

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

Conciseness5/5

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

The description seems lengthy but every sentence earns its place; it is structured as a clear user-question, formula, then key operational subgroup, and the critical '평형을 섞지 마라' and '이 축의 자리' blocks are given prominence. It is front-loaded with the most important answer (what the statistic means and where it appears), and it avoids padding. Although it is long, its density and organization are appropriate for the complexity of the tool.

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 complex auction-statistics tool with no output schema, the description is unusually complete: it covers the formula, the aggregate period (sample_period), the use of by_fail_count, by_area_band, the mapping of '빌라', the distinction from realty_compare_auction_vs_market, and important caveats about the silent ignoring of date range. It even includes specific example numbers to illustrate how area bands can change results. This gives a strong mental model for selecting and invoking the tool 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 schema already documents all five parameters. The description nevertheless adds critical nuance: it explains the semantics of by_fail_count and how to use the upper-bounded bid_count_max; it clarifies that area_band is mandatory if the target pyeong is known; it warns that '빌라' is non-standard and will be mapped; and it explains why the omitted date parameter is not exposed. This meaningfully exceeds the schema's baseline.

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 states the tool's core purpose in a concrete, user-question-oriented way ('이 지역 이 물건은 보통 감정가의 몇 %에 낙찰되나') and immediately explains the key formula (낙찰가율 = 낙찰가 / 감정가 × 100). It clearly distinguishes itself from the sibling realty_compare_auction_vs_market by emphasizing the 감정가 denominator. The description also names additional behavioral specifics such as the by_fail_count distribution, sample_period, usage_name mapping, and area_band guidance, which make the tool's function unmistakable.

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 guidance: it's the key indicator for setting bid prices, and it explicitly tells the agent when to use a sibling tool (realty_compare_auction_vs_market for 시세 대비 comparisons) while warning not to mix the two different denominators in one sentence. It also warns against mixing 평형 and instructs the agent to narrow with area_band when the target's area is known, and notes that 연립주택 statistics should be queried separately with usage_name='연립주택'. It even tells the agent to include sample_period in replies to '요즘' questions, and explains the no-date-filtering limitation.

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.

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.