Skip to main content
Glama

경매 물건 조건 검색

realty_search_auctions
Read-onlyIdempotent

법원경매 물건을 지역·종류·감정가·유찰횟수로 필터링해 조회한다.

**이 축의 자리** — 조건을 **값으로 아는** 검색이 이 도구다. 사용자의 자연어 한 줄밖에
없으면 `search`가 먼저다(질의에서 조건을 뽑아 준다). 개별 사건의 상세는 여기가 아니라
`realty_get_auction_case`(사건번호+법원명)·`fetch`(search가 준 id)다.

**이 도구는 법원경매(민사집행법·각급 법원)만 조회한다 — 공매는 여기가 아니다.**
공매(국세징수법·국유재산법 등, 한국자산관리공사 온비드)는 **이 서버에 따로 있다**:
물건은 `realty_search_onbid`, 낙찰가율은 `realty_onbid_sale_rate`
(2026-08-22 적재 — 물건 25,669개 · 최근 3개월 개찰 결과 113,673행).
여기서 안 나온다고 "그런 물건 없다"고 답하지 말고 **공매 도구로 다시 걸어라.**
구분 신호는 번호 형식이다 — 법원 사건번호는 `2025타경1234`, 공매 물건관리번호는
`2026-0600-031235`(하이픈 세 토막·'타경' 없음)다.
**두 원장을 합쳐 세거나 낙찰가율을 섞어 평균내지 마라** — 근거법·주관기관·권리 인수
규칙·저감 방식이 다르다.

감정가(min_price_10k/max_price_10k)는 **만원** 단위다 — 5억은 50000.
유찰이 많을수록 최저입찰가가 감정가 대비 낮아진다(`min_bid_rate`가 그 비율).

⚠️ **이 목록에는 매각기일이 이미 지난 행이 섞여 있다**(백엔드가 기일로 걸러주지
않는다 — 인천 아파트 3억 이하 실측 48건 중 43건이 지난 기일). 지난 기일 행에는
`past_auction_note`가 붙고 응답의 `past_auction_count`가 그 페이지의 건수다.
"지금 살 수 있어?"류 질문이면 `exclude_past=true`로 걸러라 — 지난 기일 물건은
매각·취하됐거나 다음 기일이 아직 반영되지 않은 것이라 현재 매물로 인용하면 오답이다.

⚠️ **`sort=date_asc`(기일 임박 순)는 지난 기일이 목록 앞쪽을 통째로 차지한다**
(2026-08-21 실측 94,279건 중 앞 57,241건=60.7%). `exclude_past=true`면 서버가 그
접두를 건너뛰고 읽으므로 첫 호출부터 실물이 온다 — 건너뛴 행 수는
`meta.past_prefix_skipped`, 실제로 읽은 자리는 응답의 `offset`(요청값은
`requested_offset`)이다. **items가 비어도 `has_more`가 true면 '조건에 맞는 물건이
없다'는 뜻이 아니다** — 그 창이 전부 지난 기일이었을 뿐이니 `next_offset`으로
이어서 호출하라. note가 둘 중 어느 쪽인지 매번 말한다.

⚠️ **최저입찰가는 출처를 반드시 확인해라** — 건별 `min_bid_source`가 붙는다.
  · `court_schedule` — 법원 기일표 정본이다. 그대로 믿어도 된다(활성의 28.8%).
  · `item_list` — 물건목록값이다. 유찰이 있으면 **저감 한 단계만큼 낡아 실제보다
    높을 수 있다**(2026-08-04 실측: 유찰 1회 이상에서 정본과 3%만 일치, 25~43% 과대).
    이 경우 `min_bid_note`가 함께 온다. 사용자에게 단정적으로 말하지 말고 그 한계를
    전해라. 저감률로 역산해 추정하지 마라 — 재감정으로 최저가가 **오르는** 사건도 있다.
응답의 `min_bid_stale_risk_count`가 그 페이지에서 낡았을 수 있는 건수다.
회차별 정확한 가격은 realty_auction_history의 court_schedule에 있다.

목록에는 요약 필드만 담긴다. 특정 물건의 전체 정보(면적·법원 계·주소 상세 등)는
돌아온 id로 realty_get_auction_case를 호출해 받아라.
"유찰 많이 돼 싸진 물건 찾아줘"류 발굴 질문은 realty_auction_alerts가 지름길이다
(min_fail_count로 여기서 걸러도 같은 축 — 결과를 합쳐 세지 마라).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sidoNo시도. '서울'처럼 줄여 써도 되고 '서울특별시'도 된다.
sortNo정렬 기준date_desc
limitNo반환 개수 (최대 50) (허용 범위 1~50)
offsetNo페이지 오프셋. has_more가 true면 next_offset으로 다시 호출하라.
sigunguNo시군구 (예: 강남구, 성남시)
usage_nameNo물건 종류 (아파트, 오피스텔, 다세대, 단독주택, 상가, 토지 등)
exclude_pastNo매각기일이 이미 지난 행 제외 여부. 기본 False(전체 반환 — 지난 기일 행에는 past_auction_note 플래그가 붙는다). '지금 입찰 가능한 물건' 질문이면 True로 호출하라 — 오늘 이후 기일(기일 미정 포함)만 남는다.
max_price_10kNo최대 감정가, **만원** 단위
min_bid_countNo최소 유찰 횟수. 유찰이 쌓일수록 최저입찰가가 내려간다. (허용 범위 0~100)
min_price_10kNo최소 감정가, **만원** 단위 (5억이면 50000)

TDQS

A4.7/5.0
Behavior5/5

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

annotations는 readOnly/openWorld/idempotent만 제공하지만, description은 실제 행동 특성을 정서로 드러낸다: 매각기일 지난 행이 섞임(인천 48건 중 43건), sort=date_asc의 앞 57,241건(60.7%)이 지난 기일, min일_bid_source의 court_schedule과 item_mise 정책 차이, has_more=true가 '없다'를 뜻하지 않는 페이지네이션 특성까지. annotation과 모순도 없다.

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?

분량은 길지만 모든 문장이 측정값과 사례(예: 94,279건 중 앞 57,241건=60.7%, 3%만 일치, 25~43% 과대)를 들어 행동 지침을 입증한다. 목적 → 형제 구분 → 경고 → 응답 필드 설명 순으로 구조화되어 있고 각 경고에 볼드 리드가 있어 에이전트가 함정 패턴을 빠르게 스캔할 수 있다.

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?

출력 schema가 없는 상황에서도 지난 기일 처리, date_asc 경성, 최저거래가 출처와 stale 위험, offset meta 필드, has_more/next_offset 페이지네이션, 후속 도구(realty_get_auction_case 등) 안내가 빠짐없이 담겨 있다. annotations의 안전 프로파일이 보강되어 에이전트가 안전하고 정확하게 호출하기에 부족함이 없다.

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 커버리지가 100%로 10개 파라미터의 단위·범위·enum·기본값이 이미 문서화되어 있다. description은 만원 단위(5억=50000)와 유찰 횟수의 의미를 다시 강조하나 schema가 이미 담은 내용을 벗어나는 파라미터 차원의 새 정보는 거의 없다 — schema가 무거운 역할을 하는 경우이므로 baseline 3이 적합하다.

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?

첫 문장이 '법원경매 물건을 지역·종류·감정가·유찰횟수로 필터링해 조회한다'라는 구체적인 동작·대상·필터를 제시한다. 이어서 search(자연어 조건 추출), realty_get_auction_case(개별 사건 상세), realty_search_onbid(공매) 등 형제 도구와의 역할 경계를 명시하여 어느 도구인지 혼동할 여지가 없다.

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?

자연어 한 줄이면 search, 개별 사건 상세는 realty_get_auction_case, 공매는 realty_search_onbid와 realty_onbid_sale_rate라는 명시적 대안을 제시한다. 여기서 안 나오면 '그런 물건 없다'고 답하지 말고 공매 도구로 다시 걸으라고 하는 when-not 지침과, '지금 살 수 있냐'류 질문에는 exclude_past=true라는 조건별 사용 규칙까지 포함한다.

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.