Skip to main content
Glama

경매 권리분석 — 낙찰받으면 뭘 떠안나(말소기준·인수/소멸·임차인·인수액)

realty_auction_rights_analysis
Read-onlyIdempotent

이 경매 물건 낙찰받으면 뭘 떠안나 — 말소기준·인수/소멸·임차인 대항력·인수액.

법원 원장(매각물건명세서의 최선순위 설정·인수되는 권리 문구)에 사용자가 준 등기부 권리·임차인을
더해 **규칙으로 정해지는 부분만** 판정한다(LLM 없음): 권리 타임라인과 말소기준권리, 권리별
인수/소멸, 임차인별 대항력(전입 다음 날 0시 경계)·우선변제(확정일자 순위)·최우선변제(금액표는
말소기준이 아니라 최선순위 담보물권 설정일 기준), 예상 낙찰가를 주면 인수액 범위.

사용법: 사용자가 등기부등본을 첨부했으면 **그 문서를 읽어** registry_entries에 갑구·을구 권리를
순서대로 넣어라(이름·주민번호 제외). 임차인 정보가 있으면 tenants에. 둘 다 없으면 법원 원장만으로
돌리고 `on_hold`에 못 본 것이 적힌다.

경계 — 그대로 전하라: ①**법원 문구가 엔진 판정보다 앞선다**(충돌은 `conflicts`). ②명세서 칸이
공란이면 '인수 없음'이 아니라 **못 봄**이다(`assumption.verdict='not_seen'`). ③유치권·법정지상권·
분묘기지권·가처분의 피보전권리는 사실판단이라 **판정하지 않고** `on_hold`에 점검표로 준다.
④등기부↔명세서 말소기준이 다르면 `cross_check` 경고. ⑤결과는 **정보 제공이지 법률 자문이
아니다** — 등기부·현황조사서·매각물건명세서 원문 대조를 권하라(`disclaimer`).
등기부 없이 원장만이면 realty_get_auction_case(rights_analysis=true)와 같은 결과다.

Input Schema

NameRequiredDescriptionDefault
case_noYes사건번호 — `2026타경3571` 꼴(realty_get_auction_case와 같은 규칙·정규화)
tenantsNo임차인 목록(현황조사서·전입세대열람·사용자 진술): {move_in_date:'YYYY-MM-DD'(전입일), fixed_date:확정일자, deposit_won:보증금(원), monthly_rent_won, dividend_requested:배당요구 여부(true/false/모르면 생략), has_lease_registration:임차권등기 여부}. 이름 칸은 없다. 법원 명세서에 적힌 임차인과 다르면 법원 값을 따르고 충돌을 공시한다
court_nameNo법원명 — 사건번호는 법원 간 중복이 흔하다. 모르면 비워 두면 후보 법원이 돌아온다
expected_bid_wonNo예상 낙찰가(원). 주면 배당을 흘려 대항력 임차인의 미변제 보증금(=낙찰자 인수액)을 **범위로** 낸다 — 집행비용·당해세·임금채권은 못 보므로 단일 숫자로 단정하지 않는다
registry_entriesNo**사용자가 첨부한 등기부등본(갑구·을구)을 읽어** 권리마다 한 항목씩 넣는다: {section:'갑'|'을', order:순위번호, receipt_date:'YYYY-MM-DD'(접수일), receipt_no:접수번호(같은 날 선후를 가른다), kind:'근저당권설정'·'가압류'·'전세권설정' 등 등기목적 그대로, amount_won:채권최고액·전세금(원), note:비고('배당요구함'·'건물 전부' 등)}. **권리자 이름·주민번호는 넣지 마라** — 받을 칸이 없고, 넣으면 버리고 버린 키 이름만 ignored_fields로 알린다. 없으면 비워 둔다(법원 명세서의 최선순위로만 판정)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.7/5.0
Behavior5/5

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

Annotations only say readOnly/idempotent/openWorld; the description adds everything an agent actually needs: the engine is deterministic (no LLM), court wording outranks engine verdicts with mismatches in `conflicts`, blank ledger cells mean 'not seen' rather than 'nothing assumed', and 유치권/법정지상권/분묘기지권/가처분 are deliberately not adjudicated but returned as an on_hold checklist. It also states the result is information, not legal advice, and recommends checking the source documents.

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?

Front-loaded with a one-line headline, then structured into usage and a numbered 경계 list, so it scans well. It is dense and long for a tool definition; some clauses (e.g. the parenthetical about 최우선변제 table basis) could be trimmed without losing decision value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/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 carries return semantics and does so well by naming the key output fields (conflicts, assumption.verdict, cross_check, on_hold, disclaimer). The overall shape of the rights timeline and per-tenant verdict output is only implied rather than described, which keeps it just under a 5.

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%, so the baseline is 3, but the description adds real meaning: registry_entries must exclude names and 주민번호 (rejected keys surface as ignored_fields), and expected_bid_won yields a range rather than a single figure because enforcement costs and tax claims are invisible. The tenants guidance mostly restates the schema, keeping this short of a 5.

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?

States a precise verb and resource in domain terms: judges, by rule, the rights a winning bidder takes on (말소기준권리, 인수/소멸, 임차인 대항력, 인수액). It explicitly distinguishes itself from the nearest sibling by noting that with only the court ledger it produces the same result as realty_get_auction_case(rights_analysis=true).

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 an explicit '사용법' block: if the user attached a registry document, read it into registry_entries in order; put tenants into tenants; if neither exists, run on the court ledger alone with the gap surfaced in on_hold. The fallback path and the sibling-equivalence case are both spelled out, leaving no ambiguity about when to use this versus realty_get_auction_case.

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.