Skip to main content
Glama

korea-realty

by app.sallim
OverviewDiscussionsAdmin

소액임차인 최우선변제 — 담보물권 설정일로 적용 시행령 판을 고른다

realty_small_deposit_check
Read-onlyIdempotent

소액임차인 최우선변제의 금액표를 고르는 도구다 — 판정기가 아니다.

"전입은 근저당보다 빠르고 확정일자는 늦으면?"처럼 **임차인 한 사람의 날짜들**(전입·
확정일자·근저당)로 대항력·우선변제·최우선변제를 묻는 질문은 여기서 시작하라 — 근저당
날짜로 금액표를 고르고 `not_a_conclusion`이 남은 요건을 적는다. 두 권리의 요건 원문은
realty_policy_rules(topic=auction_rights)가 함께 준다.

"최우선변제금 얼마까지 나와요?"에 현행표를 읊으면 틀린다. 적용되는 표는 **최선순위
담보물권을 취득한 날이 속한 시행령 판**이고(부칙 경과조치), 2008-08-21 이후 7개 판이
서로 다르다. 2015년 근저당이 붙은 서울 주택이면 지금 경매라도 2014-01-01 판
(9,500만원 이하 / 3,200만원)으로 잰다 — 현행표(1억6,500 / 5,500)를 쓰면 소액임차인이
아닌 사람을 소액임차인이라 답하게 된다.

경계를 지켜라: ① **범위에 든다 ≠ 받는다.** 경매개시결정등기 전 대항요건·배당요구종기까지
배당요구·주택가액 1/2 한도·다수 임차인 안분·임차권등기 후 임차인 제외가 전부 남아 있다
(응답 `not_a_conclusion`). ② `security_right_date`가 없으면 **표를 고르지 않는다** —
현행표를 기본값으로 주는 순간 이 도구가 막으려던 오답이 된다. **그렇다고 날짜를
지어내지도 마라**(2026-08-22 제보: 사용자가 연도만 줬는데 클라이언트가 `2019-01-01`을
생성했다). 연도만 안다면 `security_right_year`에 그 연도만 넣어라 — 그 해 전체가 한
판 안이면 서버가 날짜 없이 답하며 **"연도로 판을 골랐다"를 응답에 명시**하고, 판이
갈리는 해면 표를 고르지 않고 등기 접수일을 되묻는다. ③ 시 안에서 동에 따라
과밀억제권역이 갈리는 곳(인천·남양주·시흥)은 구간을 **안 고르고** 별표 원문을 낸다.
④ **주택만**이다 — 상가는 상가건물임대차보호법으로 금액표가 다르다. ⑤ 이 도구는 표 조회만
한다 — 말소기준권리·인수 여부·인수액 범위는 realty_auction_rights_analysis(같은 표를 쓴다). 규칙 전체와 갈림길은
realty_policy_rules(topic=auction_rights)가 진실원이다.

Input Schema

NameRequiredDescriptionDefault
regionNo물건 소재지. '서울', '경기도 부천시', '부산광역시 기장군'처럼 시도를 붙이면 확실하다. 비우면 그 판의 **전 구간 표**를 그대로 준다
deposit_10kNo임차보증금(**만원**). 주면 그 판의 '소액임차인 범위' 상한과 대조해 **범위에 드는지의 산수**만 한다 — 최우선변제를 받는다는 판정이 아니다
security_right_dateNo**최선순위 담보물권(근저당 등)의 설정일** YYYY-MM-DD. 금액표를 고르는 기준일이다 — '오늘'도 '임대차계약일'도 아니다(각 개정 시행령 부칙 경과조치: '이 영 시행 전에 임차주택에 대하여 담보물권을 취득한 자에 대해서는 종전의 규정에 따른다'). 등기부 을구에서 확인한다. **모르면 비워 두라 — 서버가 현행표를 답인 척 주지 않는다**. ⚠️ **연도만 아는 경우 날짜를 지어내지 마라** — '2019년'만 들었으면 '2019-01-01'을 만들지 말고 security_right_year=2019를 쓰라. 그 해 전체가 한 시행령 판 안이면 서버가 날짜 없이 답하고, 판이 갈리는 해면 월·일을 되묻는다
security_right_yearNo**최선순위 담보물권 설정 '연도'만** 알 때 쓴다(예: 2019). 사용자가 연도만 말했을 때 security_right_date에 임의의 날짜를 지어 넣는 대신 여기에 연도를 그대로 넣어라 — 그 해 전체가 한 시행령 판 안에 있으면 월·일 없이도 표가 정해지고(응답이 그 근거를 밝힌다), 판이 갈리는 해면 표를 고르지 않고 등기 접수일을 되묻는다 (허용 범위 1900~2200)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -{
-  "additionalProperties": true,
-  "title": "realty_small_deposit_checkDictOutput",
-  "type": "object"
-}New value: +null
  2. Changed2 schema fields changed
    • changedInput schema / properties / security_right_date / description
      Previous value: -"**최선순위 담보물권(근저당 등)의 설정일** YYYY-MM-DD. 금액표를 고르는 기준일이다 — '오늘'도 '임대차계약일'도 아니다(각 개정 시행령 부칙 경과조치: '이 영 시행 전에 임차주택에 대하여 담보물권을 취득한 자에 대해서는 종전의 규정에 따른다'). 등기부 을구에서 확인한다. **모르면 비워 두라 — 서버가 현행표를 답인 척 주지 않는다**"New value: +"**최선순위 담보물권(근저당 등)의 설정일** YYYY-MM-DD. 금액표를 고르는 기준일이다 — '오늘'도 '임대차계약일'도 아니다(각 개정 시행령 부칙 경과조치: '이 영 시행 전에 임차주택에 대하여 담보물권을 취득한 자에 대해서는 종전의 규정에 따른다'). 등기부 을구에서 확인한다. **모르면 비워 두라 — 서버가 현행표를 답인 척 주지 않는다**. ⚠️ **연도만 아는 경우 날짜를 지어내지 마라** — '2019년'만 들었으면 '2019-01-01'을 만들지 말고 security_right_year=2019를 쓰라. 그 해 전체가 한 시행령 판 안이면 서버가 날짜 없이 답하고, 판이 갈리는 해면 월·일을 되묻는다"
    • addedInput schema / properties / security_right_year
      Added value: +{
+  "anyOf": [
+    {
+      "maximum": 2200,
+      "minimum": 1900,
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "**최선순위 담보물권 설정 '연도'만** 알 때 쓴다(예: 2019). 사용자가 연도만 말했을 때 security_right_date에 임의의 날짜를 지어 넣는 대신 여기에 연도를 그대로 넣어라 — 그 해 전체가 한 시행령 판 안에 있으면 월·일 없이도 표가 정해지고(응답이 그 근거를 밝힌다), 판이 갈리는 해면 표를 고르지 않고 등기 접수일을 되묻는다 (허용 범위 1900~2200)",
+  "title": "Security Right Year"
+}
  3. Added

TDQS

A4.6/5.0
Behavior5/5

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

Annotations cover read-only/idempotent, but the description adds substantial behavior beyond them: it refuses to pick a table without security_right_date rather than defaulting to the current table, it will not fabricate dates for year-only inputs, and it discloses the not_a_conclusion payload and the ambiguity fallbacks (year-only, split-city dong). This is exactly the failure-mode disclosure annotations cannot carry.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The core distinction and the 'table is picked by security right date, not today' warning are front-loaded, which is good. But the numbered boundary list plus the 2015-seoul worked example is dense and repeats the don't-fabricate-dates rule already stated in two parameter descriptions, so some sentences do not earn their place in the description itself.

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?

No output schema exists, and the description compensates by naming the not_a_conclusion field and describing the fallback responses (full table, year-based selection with stated basis, re-ask for the registration date). A short note on the overall response shape would close the last gap, but an agent has enough to call it 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%, so the baseline is 3, but the description adds the legal rationale for why security_right_date is the pivot (부칙 경과조치) and why security_right_year exists as a distinct non-fabricating path, plus the region-blank behavior. It reinforces rather than merely restates the schema, though it duplicates the year-fabrication warning already in both parameter descriptions.

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?

Opens with a specific verb+resource: it selects the small-tenant priority-repayment amount table by the senior security right's acquisition date, and explicitly negates the misread ('판정기가 아니다'). It names its two siblings (realty_policy_rules, realty_auction_rights_analysis) and states what each does instead, so an agent can separate them without opening any schema.

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 a concrete trigger question ('전입은 근저당보다 빠르고 확정일자는 늦으면?'), explicit exclusions (말소기준권리·인수 여부 → realty_auction_rights_analysis; full rules → realty_policy_rules), and the housing-only restriction with the commercial-building alternative law. The 'when not to use' cases are as explicit as the 'when to use' case.

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
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources