Skip to main content
Glama

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

realty_small_deposit_check
Read-onlyIdempotent

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

"최우선변제금 얼마까지 나와요?"에 현행표를 읊으면 틀린다. 적용되는 표는 **최선순위
담보물권을 취득한 날이 속한 시행령 판**이고(부칙 경과조치), 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_policy_rules(topic=auction_rights)가 진실원이다.

Input Schema

TableJSON 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)

TDQS

A4.5/5.0
Behavior5/5

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

annotations가 이미 안전한 읽기 동작을 알려주지만, 설명은 그 이상으로 '날짜가 없으면 표를 고르지 않는다', '연도만 알면 서버가 연도 기준임을 응답에 명시한다', '판이 갈리는 해에는 등기 접수일을 되묻는다', '범위 내 포함이 곧 최우선변이 수령 판정은 아니다(not_a_conclusion)'는 실제 동작을 드러낸다. 날짜를 조작하지 타야 한다는 제보 사례까지 있어 오남용을 막는다.

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?

첫 문장에 목적과 비목적을 넣고 1~5번으로 나뉜 경계 목록과 실제 선례를 구조화해 복잡한 툴인에도 실용적으로 읽힌다. 다만 제보 일자와 장황한 경고 문구를 스키마와 본문에서 반복하는 부분이 있어 일부 낭비가 있다.

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?

금액표 선택이라는 핵심 경로, 날짜/연도 입력 방식, 결론 비판정, 정책 원천 도구 이름까지 잘 갖추어져 있다. 그러나 '2008-08-21 이전 날짜를 받으면 어떻게 처리되는가' 또는 'security_right_date와 security_right_year가 동시에 들어온 경우 우선순위' 같은 경계 조건이 명시되지 않았다.

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?

입력 스키마 100% cover에 상세 설명이 있어 기본값을 높애 잡을 수 있다. 본문은 security_right_date와 security_right_year의 상호 관계, deposit_10k는 단순 산수일 뿐이라는 해석 한계를 다시 강조한다. 그러나 핵심 파라미터 의미의 상당 부분은 이미 스키마 필드 설명에 있어 '새로 추가하는 설명'만 보면 5점보다는 4점이다.

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?

첫 문장에서 '금액표를 고르는 도구'라는 구체적 목적과 대상을 명시하고, '판정기가 아니다'라고 범위를 못박는다. 두 번째 문단은 '적용되는 표는 최선순위 담보물권을 취득한 날이 속한 시행령 판'이라고 기준을 밝혀 형제 도구들과의 구분을 분명하게 한다.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

realty_policy_rules(topic=auction_rights)를 규칙 전체와 갈림길의 진실 원천으로 지목해 상세 규정이 필요할 때의 라우팅을 제시한다. '판정기가 아니라'와 '상가는 별도 법률이 적용된다'는 비사용 조건도 명확하다. 다만 상가·비주택 등 대체 대상에서 어떤 도구를 대신 쓸지는 명시되지 않아 5점에는 조금 못 미친다.

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.