Skip to main content
Glama

Home plus pre-sale right case

judge_156_3_special
Read-onlyIdempotent

Home plus pre-sale right (분양권) one-home special case (Income Tax Decree art. 156-3).

주택+분양권 1세대1주택 특례 판정 (영 §156의3, 규칙 §75·§75의2 — 24차 순회).

입주권은 judge_155_special·§156의2 계열이 맡고, 이 툴은 **분양권** 전용이다.
**판정범위는 ②③항(일시적 1주택+1분양권)뿐이다** — 상속분양권(④⑤)·동거봉양/혼인
조합(⑥)·문화재/이농주택 조합(⑦⑧)은 미구현이며 반환 '판정범위' 필드로 고지된다.
상속·합가·혼인이 얽힌 분양권 상담에는 이 결론을 그대로 쓰지 말 것.
2021-01-01 이후 취득한 분양권부터 주택수에 들어가므로 그 전 취득분은
"특례 불필요"로 돌려준다 — 탈락과 구분해서 읽을 것.

판정 순서: ②항(분양권 취득 후 3년 내 종전주택 양도) → 안 되면 규칙 §75① 부득이한
사유 → 그래도 안 되면 ③항(신축주택 완성 후 실입주).

함정 셋을 코드에 박아 뒀다.
- ②항 후단이 1년 요건을 면제하는 것은 §154① 제1호·제2호**가목**·제3호뿐이다.
  해외이주 출국(제2호나목)·국외 취학근무 출국(다목)은 면제 대상이 아니다.
- ③항의 "완성 후 2년"은 2023-02-28 개정으로 3년이 됐는데, 기준은 시행일이 아니라
  **2023-01-12 이후 양도분**이다(부칙 §8).
- ③항의 "종전주택 취득 1년 경과" 요건은 2022-02-15 이후 **취득한 분양권**부터다
  (부칙 §12). 양도일 기준이 아니다.

Args:
    prior_home_acquired: 종전주택 취득일 YYYY-MM-DD
    bunyang_acquired: 분양권 취득일 YYYY-MM-DD (계약일 아님)
    sale_date: 종전주택 양도일 YYYY-MM-DD
    new_home_completed: 분양권으로 취득하는 주택의 완성일 (③항 판정에 필요)
    moved_in_date: 신축주택으로 세대전원이 이사한 날
    continuous_residence_years: 신축주택 계속거주 기간(년) — 1년 이상이어야 한다
    holding_waiver_reason: ""|건설임대5년거주|수용|해외이주2년|취학근무국외|부득이1년거주
        (judge_exemption_requirements의 waiver_reason과 같은 어휘)
    sale_delay_reason: ""|캠코매각의뢰|법원경매신청|공매진행 (규칙 §75① 열거 3가지)
    delay_state_at_3y: 분양권 취득일부터 3년이 되는 날 현재 그 상태였는지
    sold_by_that_method: 실제로 그 방법(경매·공매 등)으로 양도됐는지
    partial_move_reason: ""|취학|근무|질병|학교폭력 — 세대원 일부가 못 옮긴 사유
    other_homes: 종전주택·분양권 외에 보유한 주택 수. §156의3②은 '1주택+1분양권'
        전제라 제외 특례를 거치지 못한 주택이 남으면 이 항으로는 비과세되지 않는다
    excluded_homes: 그중 주택수 제외 특례로 빠지는 수 — 농어촌주택(조특법 §99의4)·
        인구감소지역주택(§71의2)·준공후미분양(§98의9). 제외 후 1주택이면 적용된다
    bunyang_already_completed: 양도 당시 분양권이 이미 완공돼 주택이 된 경우

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sale_dateYes
other_homesNo
moved_in_dateNo
excluded_homesNo
bunyang_acquiredYes
delay_state_at_3yNo
sale_delay_reasonNo
new_home_completedNo
partial_move_reasonNo
prior_home_acquiredYes
sold_by_that_methodNo
holding_waiver_reasonNo
bunyang_already_completedNo
continuous_residence_yearsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already establish the safe read-only, idempotent, closed-world profile, and the description goes well beyond them: it discloses that pre-2021-01-01 분양권 returns '특례 불필요' (which must not be read as 탈락), that part of the statutory range is unimplemented and surfaced through a '판정범위' field, and it pins three amendment-date pitfalls (2023-01-12 양도분, 2022-02-15 취득분). This is behavioral context an agent could not get from annotations.

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 purpose, then scope, then judgment order, then the trap list, then args — a sensible hierarchy with no filler sentences. It is nonetheless long, and some trap detail (e.g. the specific 부칙 article numbers) is more implementation nuance than an agent needs to select and invoke the tool.

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?

For a 14-parameter, 0%-documented, mutation-free judgment tool with no output schema, the description supplies everything needed: scope, call order, per-parameter vocabularies, edge-case behavior, and a hint at the returned 판정범위 field. Nothing an agent needs to call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% (titles only, no enums declared), so the description carries the full load and does so: it documents every one of the 14 arguments with format (YYYY-MM-DD), semantics (분양권 취득일 = 계약일 아님), and enumerated vocabularies for holding_waiver_reason, sale_delay_reason, and partial_move_reason. It also explains how other_homes/excluded_homes interact with the 1주택+1분양권 premise.

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 specific verdict verb and resource (주택+분양권 1세대1주택 특례 판정) plus the governing provision (§156의3, 규칙 §75·§75의2). It explicitly differentiates itself from siblings: '입주권은 judge_155_special·§156의2 계열이 맡고, 이 툴은 분양권 전용이다'. An agent can route without opening the 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 explicit scope limits (②③항 only; ④⑤/⑥/⑦⑧ unimplemented and reported via 판정범위), a warning not to reuse the conclusion for 상속·합가·혼인 cases, and an ordered judgment sequence (②항 → 규칙 §75① → ③항). Alternatives and exclusions are named rather than inferred.

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.

Resources