Skip to main content
Glama

공매 낙찰가율·개찰 결과 통계

realty_onbid_sale_rate
Read-onlyIdempotent

공매가 "보통 감정가의 몇 %에 낙찰되나"와 "얼마나 유찰되나"를 실제 개찰 결과로 답한다.

**법원경매의 realty_auction_sale_rate와 같은 이름의 다른 지표다.** 분모가 둘 다
감정가지만 평가 주체·저감 규칙·매물 성격이 달라 **두 %를 한 문장에 섞으면 안 된다**.
"경매 낙찰가율"을 물었으면 어느 쪽인지 확인하라.

**이 축의 자리** — 공매 축 2종 중 통계 쪽이다. 개별 물건과 회차별 최저가는
realty_search_onbid다. 낙찰가율은 재산구분별로 갈라 읽어라(`by_property_type`).

⚠️ **표본은 최근 3개월 개찰분이고, 그중 '낙찰' 건만 낙찰가율에 든다.** 온비드 전체
입찰결과 688,264건 중 우리가 받은 것은 113,673건이고, 그 안에서 낙찰은 3,824건이다
(나머지는 유찰·취소·개찰중). `outcome_mix`가 그 분포이고 여기서 나온 낙찰 비율은
**성립률이지 낙찰가율이 아니다**.

⚠️ **낙찰가율은 원천이 준 값을 그대로 쓴다**(`apslPrcCtrsScfbPrcRto` = 감정가 대비
낙찰가율). 낙찰 3,824건 중 이 값이 있는 것은 2,896건이다 — 나머지는 감정가가 원장에
없는 건이라 **모르는 것이지 0이 아니다**(`ratio_missing`).

⚠️ **평균이 아니라 중앙값을 인용하라.** 지분·산지 물건이 감정가의 386%에 팔린 사례가
실제로 있어(공유자 경합) 평균이 위로 끌린다. `median_pct`가 정본이고 `p25_pct`·
`p75_pct`로 폭을 함께 전하라.

⚠️ **지역은 물건명에서 되찾은 것이다.** 입찰결과 원장에 지역 컬럼이 아예 없어서,
물건 목록과 붙여 보려 했으나 **낙찰 3,824건 중 물건 목록에서 찾아지는 것은 83건
(2.2%)뿐이다** — 물건 목록은 현재 진행분 스냅샷이라 이미 팔린 물건이 빠져 있다.
그래서 물건명 접두의 시도·시군구 표기를 파싱해 쓴다(전체 96.1%·낙찰 90.0%에서 잡힌다).
파싱이 안 된 건은 지역 필터에서 **조용히 빠지므로** 응답의 `region_basis`를 함께 전하라.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sidoNo시도. **주의: 결과 원장에는 지역 컬럼이 없다** — 물건명 접두에서 되찾은 값으로 거른다(커버리지는 응답의 region_basis에 실린다).
sigunguNo시군구. 물건명에서 시도 다음 한 토막을 뽑은 것이라 '고양시 덕양구'는 '고양시'로만 잡힌다 — 자치구까지 좁히려면 이 원장으로는 안 된다.
usage_nameNo용도 부분일치(중·소분류)
property_typeNo재산구분. **이 축을 빼고 하나의 낙찰가율을 말하면 거의 틀린다** — 실측 중앙값이 압류재산 31.6% vs 국유재산 106.3%로 3배 넘게 갈린다.

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/openWorld/non-destructive, and the description adds critical behavioral detail: sample is a recent 3-month snapshot with only 3,824 successful bids, rating is unknown-if-missing not zero, median is the canonical measure due to outlier skew, and region is a heuristic parse with 2.2% lookup rate. These caveats outline the response values themselves and set expectations for aggregate quality.

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 text is front-loaded with the core answer and each warning block is valuable and distinct. However, it is quite long, with some repeated numbers and context that could be tightened without losing crucial caveats. Still, the structure of a heading and bulleted warnings reasonably earns its place for this complex statistical reply.

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 tool with no output schema, the description covers sample scope, outcome mix, missing ratio, median summary, and regional-to-source parsing. It names the output fields it expects the agent to produce (`outcome_mix`, `median_pct`, `p25_pct`, `p75_pct`, `region_basis`) and leaves no obvious gap in what an agent needs to invoke it correctly or interpret the result.

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 covers all 4 parameters 100% with detailed comments, including property_type warning and sido coverage note, so the high coverage baseline applies. The description's mention of `by_property_type` reinforces but does not add new param semantics beyond the schema; no explanation of formats or additional constraints is given here.

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?

Description states a clear function: it answers what percentage of appraised value public-auction (공매) properties sell at and how often they fail, based on actual bid results. It also explicitly differentiates itself from the identically named court-auction tool realty_auction_sale_rate, so an agent can tell which statistical metric is meant.

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 gives explicit when-to-use and when-not-to-use guidance: '경매 낙찰가율'을 물었으면 어느 쪽인지 확인하라, and points to realty_search_onbid for individual properties and minimum prices. It also directs the user to disaggregate by property_type for correct answers, making the usage context unmistakable.

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.