Skip to main content
Glama

korea-realty

by app.sallim

경매 사건 상세 조회

realty_get_auction_case
Read-onlyIdempotent

사건번호로 경매 물건의 상세를 조회한다.

사건번호는 법원 간 유일하지 않다(전국 평균 2.8개 법원에서 중복). court_name을 생략하면
중복 시 오류와 함께 후보 법원 목록이 돌아오니, 그걸 보고 법원을 지정해 다시 호출하라.

`rights` = 매각물건명세서 핵심(최선순위 설정·인수되는 권리 원문·위험 플래그·배당요구종기).
이것은 법원 공시의 전달이지 권리분석 판단이 아니다 — 답할 때 rights.disclaimer를 함께
전하고, 등기부·임차인 현황 전체가 아님을 밝혀라. rights가 null이면 명세서 미수집
상태(rights_note에 사유)이므로 권리관계를 절대 지어내지 말 것.
⚠️ `rights.claim_amt_10k`는 **경매신청 채권자의 청구금액**(만원)이다 — 임차인
보증금이 아니다(claim_amt_note 참조). 보증금 액수는 이 데이터에 없다.
`min_bid_source`가 item_list면 최저가가 낡았을 수 있다 — 함께 오는 `min_bid_note`를
사용자에게 전하고 단정하지 마라(목록 도구와 같은 경고다).
유찰 이력·기일별 저감·사진은 realty_auction_history가 담당이다.

**이 축의 자리** — 사건번호·법원명을 **따로 받아 구조화 필드**로 돌려주는 상세가 이
도구다. `search` 결과의 id(`"법원명|사건번호"`)를 그대로 들고 있다면 `fetch`가 그 덩어리를
쪼개지 않고 받아 문서형 텍스트로 준다 — 둘은 대체재가 아니라 입력·응답 형태가 다른
짝이다. 조건으로 여러 건을 훑는 것은 `realty_search_auctions`다.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
case_noYes사건번호 — `2026타경3571` 꼴이다(연도 4자리 + '타경' + 일련번호 3~6자리). 원장 전수가 '타경' 접두이고 '2024타경101026'처럼 6자리도 있다. '2026-3571'처럼 하이픈으로 써도 서버가 '타경'으로 펴고 무엇을 폈는지 응답에 적는다. 다만 '3571'처럼 **연도가 없으면 못 편다**(연도를 지어내면 다른 사건이 된다) — 사용자에게 연도를 물어라
court_nameNo법원명 — '서울동부지방법원'·'인천지방법원'처럼 정식명으로 넣는다('진주지원'처럼 지원명만인 행도 있다). '의정부지법'처럼 줄여 넣어도 서버가 정식명으로 편다. 사건번호는 법원 간 유일하지 않아(전국 평균 2.8개 법원에서 중복) 생략하면 후보 목록이 돌아온다. **여기 넣은 법원에 그 사건이 없으면 서버가 법원 없이 한 번 더 찾아보고**, 그래도 없으면 원인 셋(표기·법원·수록범위)을 갈라 돌려준다

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already declare a safe read-only, idempotent, open-world operation, and the description substantially extends this without contradiction: case numbers are non-unique across courts (avg 2.8), duplicate errors return candidate court lists, rights=null means 미수집 and forbids fabrication, claim_amt_10k is the creditor's claim amount rather than the tenant deposit, min_bid_source=item_list signals staleness, and the server's fallback re-search when the named court lacks the case. This is rich disclosure far beyond the annotation fields.

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 purpose is front-loaded in the first sentence, followed by a logical ordering: duplicate-number caveat, rights handling rules, the ⚠️ claim_amt trap, stale min_bid warning, sibling exclusions, and a final positioning paragraph (이 축의 자리). It is long, but every sentence addresses a real failure mode or routing decision with zero filler, and the ⚠️ markers highlight the highest-risk misinterpretations.

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 bears the burden of explaining return-value semantics and does so thoroughly: the rights object and its disclaimer requirement, rights_note for null, claim_amt_10k/claim_amt_note, and min_bid_source/min_bid_note. It states clear boundaries (등기부·임차인 현황 전체 아님, 보증금 액수 없음, history/photos handled elsewhere) and documents error/retry flows. An agent has everything needed to call it safely and interpret its response correctly.

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% with already rich per-parameter descriptions (case_no format, hyphen expansion, missing-year trap; court_name formal-name/abbreviation handling and fallback behavior). The description adds the operational retry pattern — on duplicate error, specify the court and call again — and clarifies the tool's input contract as separate structured fields versus fetch's combined id, so it adds genuinely useful value above the schema-dominant baseline of 3, though the schema carries most of the semantic weight.

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 first sentence states a specific verb and resource: '사건번호로 경매 물건의 상세를 조회한다' (query auction property detail by case number). It actively distinguishes itself from siblings across the description — realty_search_auctions for condition-based sweeping, realty_auction_history for 유찰 이력·기일별 저감·사진, and fetch for document-form text from a combined id. An agent can select this tool unambiguously.

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?

Gives explicit when/when-not guidance: omitting court_name triggers a candidate-court list and the imperative retry instruction '그걸 보고 법원을 지정해 다시 호출하라'. It explicitly routes history/session-reduction/photo needs to realty_auction_history, condition sweeping to realty_search_auctions, and the combined-id document case to fetch, stating '둘은 대체재가 아니라 입력·응답 형태가 다른 짝이다'. Nothing is left to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All korea-realty toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

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.

Resources