Skip to main content
Glama

공매(온비드) 물건 검색

realty_search_onbid
Read-onlyIdempotent

한국자산관리공사 온비드 공매 물건을 지역·용도·재산구분·감정가로 조회한다.

법원경매가 아니다. 공매는 국세징수법(압류재산)·국유재산법·공유재산법에 따른 처분이고
주관은 캠코다 — 아래 '이 축의 자리'와 응답의 `not_court_auction`을 반드시 함께 전하라.

**이 축의 자리** — 공매 축은 도구가 둘뿐이다. 물건을 찾고 회차별 최저가 일정을 보는
것이 이 도구, "보통 감정가의 몇 %에 낙찰되나"는 realty_onbid_sale_rate다.
**법원경매를 물었다면 여기가 아니라 realty_search_auctions**이고, 사건번호에 '타경'이
들어 있으면 그쪽이다. 사용자가 그냥 "경매"라고만 했으면 **어느 쪽인지 되물어라** —
둘을 합쳐 세거나 섞어 평균내면 그 답은 틀린다.

**행이 물건이 아니다.** 원장의 한 행은 물건이 아니라 **공매조건(회차)**이다 — 한 물건이
1~10회차 입찰 일정을 미리 갖고 회차마다 최저입찰가가 내려간다(실측: 물건당 3.51행).
이 도구는 **물건 단위로 접어서** 돌려준다: `rounds_total`(전체 회차)·`rounds_remaining`
(마감 전 회차)·`next_round`(다음 입찰 회차의 기간과 최저입찰가)·`last_round`(마지막
예정 회차 = 더 안 팔리면 도달하는 바닥값). 응답의 `condition_rows`가 접기 전 행 수다 —
**행 수를 물건 수로 인용하지 마라**(71% 과대).

⚠️ **최저입찰가 '비공개'** — 원문이 숫자가 아니라 '비공개'인 회차가 있다(529행).
그 회차의 금액은 **null**이지 0이 아니다. `min_bid_undisclosed_rounds`가 그 수이고,
평균·최저값 계산에서 빠져 있다.

⚠️ **압류재산 주소는 번지가 가려진다** — 결과 원장 기준 압류재산의 61.7%가
'강원특별자치도 춘천시 ***********' 꼴이다. 물건 목록 쪽은 번지까지 나오지만
(실측 마스킹 0건), 같은 물건을 결과에서 다시 찾을 때는 시군구까지만 유효하다.

⚠️ **시도 표기를 우리가 손봤다** — 원천에 '전남광주통합특별시' 같은 통합 표기가 7,757행
있어 시군구로 분해해 `sido`에 넣었다. 손보기 전 원문은 `sido_source`, 분해 근거는
`sido_basis`('as_is' = 원문 그대로 / 'split_by_sgg' = 시군구로 갈랐다)에 있다.

권리분석·감정평가서·공고 원문은 이 원장에 없다. 공매의 권리 인수 규칙은 법원경매와
다르므로 realty_policy_rules(민사집행법 기준)의 답을 여기에 옮기지 마라.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sidoNo시도. '서울'처럼 줄여 써도 되고 '서울특별시'도 된다.
sortNodeadline=마감 임박순 · price_asc/desc=감정가순 · discount=감정가 대비 최저가가 낮은 순(저감 많이 된 순)deadline
limitNo반환 **물건** 수 (최대 50) (허용 범위 1~50)
offsetNo페이지 오프셋. has_more면 next_offset으로 다시 호출하라.
sigunguNo시군구 (예: 춘천시, 강남구). 부분일치다 — '고양시'는 '고양시 덕양구'도 잡는다.
open_onlyNo입찰 마감이 아직 안 지난 회차가 남은 물건만. 기본 True — 원장에는 이미 끝난 회차 행이 함께 들어 있어서(물건 25,669개 중 마감 전 회차가 남은 것은 10,327개), 끄면 지금 입찰할 수 없는 물건이 섞인다. cltr_mng_no로 특정 물건을 볼 때는 무시된다.
usage_nameNo용도 부분일치. 이 원장의 중분류는 토지·주거용건물·상가용및업무용건물·용도복합용건물·산업용및기타특수용건물 5종이고, 소분류에 아파트·다세대주택·대지 등이 들어 있다. **'아파트'는 소분류라서 중분류로는 안 걸린다** — 넓게 보려면 '주거용건물'.
cltr_mng_noNo물건관리번호(예 '2026-0600-031235')로 한 물건만. **이것이 상세 조회다** — 이 원장은 행이 물건이 아니라 회차라, 한 물건의 상세는 곧 그 물건의 회차 전부이고 그때 `rounds`에 회차별 최저입찰가 일정이 실린다. 법원 사건번호(2025타경…)는 여기 넣지 마라.
max_price_10kNo최대 감정가, **만원** 단위
min_price_10kNo최소 감정가, **만원** 단위 (5억이면 50000)
property_typeNo재산구분 — 공매에서 가장 중요한 축이다. 압류재산(체납처분·국세징수법)·국유재산·공유재산·기타일반재산·수탁재산·불용품. **성격이 완전히 다르다**: 압류재산은 체납자 재산의 강제매각이고 나머지는 공공이 가진 재산의 처분·임대다.

TDQS

A4.8/5.0
Behavior5/5

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

Annotations는 이미 readOnlyHint·openWorldHint·idempotentHint·destructiveHint를 제공하지만, 설명은 그 위에 비대칭적 행동 정보를 상당히 추가한다: 원장의 행이 '물건이 아닌 공매조건(회차)'이라는 점(물건당 3.51행), '비공개' 최저입찰가가 null로 반환되는 점, 압류재산 주소의 마스킹 규칙, sido 정규화, 그리고 응답에 포함될 필드(rounds_total, min_bid_undisclosed_rounds 등)가 실제 거동을 아주 구체적으로 드러낸다. 설명이 조회 방향과 readOnlyHint와 충돌하지 않으므로 부여하는 점수를 올린다.

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?

본문은 길지만 서두에 목적-범위를 밝히고, 경고는 ⚠️ 블록으로 시각적 구분해 구성이 일관적이다. 각 레이어(도구 축, 행/물건 모델, 비와이드, 마스킹, 정규화, 도메인 경계)가 모두 정보성 높은 문장으로 채워져 에이전트의 오류를 막아주며, '사실상 동일 제목'과의 중복을 제외하면 축소가 필요한 부분은 적다. 오히려 과해 보이는 구체 수치들도 판단 조건으로 쓰이므로 충분한 정당성이 있다.

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?

복잡도가 매우 높은 도구들(11개 비필수 파라미터, 행-물-회차 모델, 상위 3개 유사 도구, 출력 스키마 없음)인데 설명은 7개 경고와 도구 축을 통해 실질적으로 필요한 모든 문맥을 제공한다: 사용 시점, 법률적 근거, 데이터 결측 표현, 주소 마스킹, 결과 필드 의미, 그리고 '이 원장에 없는 것'(권리분석·감정평가서)까지 명시해 에이전트가 실수로 가져올 수 있는 오염 경로를 차단한다. 출가인이 유일하게 아쉬운 것은 응답의 구체적인 JSON 형태가 예시로 제공되지 않은 점이나, 필드명이 본문에 기술되어 있어 없이도 충분해 보인다.

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?

스키마 description coverage가 100%로 기본 3점이지만, 설명은 파라미터의 실질을 이해시키는 데이터 모델을 제공한다: cltr_mng_no가 '상세 조회'라는 뜻(한 물건=전체 회차)이고 open_only가 물건 단위 필터라는 점, property_type의 성격 차이(압류 vs 국공유), usage_name의 중분류/소분류 애매성이 정확히 파악된다. 다만 각 파라미터의 구체적 포맷(만원 단위, 부분 일치)은 이미 스키마에 다 들어있어 설명이 추가할 부분은 제한적이다.

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?

첫 문장이 동사+리소스+조회 기준을 명시한다: '한국자산관리공사 온비드 공매 물건을 지역·용도·재산구분·감정가로 조회한다.' 이어서 법원경매가 아님을 못박고, realty_search_auctions(법원경매) 및 realty_onbid_sale_rate(낙찰가 비율)와의 차이를 직접 언급해 스키마를 열지 않고도 구분이 가능하다. 다만 도구 제목이 '공매(온비드) 물건 검색'과 사실상 동일해, 처음 두 문장만 보면 동어반복에 가깝지만 세부 내용이 명확하게 범위를 규정한다.

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?

'이 축의 자리' 단락에서 사용 조건을 명시적으로 제시한다: 물건 조회·회차별 최저가 스케줄은 이 도구, 낙찰가 비율 질문은 realty_onbid_sale_rate, 법원경매나 '타경' 사건번호는 realty_search_auctions. 사용자가 그냥 '경매'라고만 하면 되물어야 한다는 규칙까지 명시되어 있어, 에이전트가 잘못된 도구를 선택할 가능성이 크게 줄어든다.

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.