Skip to main content
Glama

Comprehensive holding tax (종부세)

calc_jongbu_tax
Read-onlyIdempotent

Korea comprehensive real estate holding tax (종합부동산세) on housing: deductions, progressive rates, property-tax credit, age/holding credits, burden cap.

종합부동산세(주택분)를 계산한다. 세율·공제·비율은 year로 상수표에서 읽는다.

⚠️ 2026-08-30 변경 — year 필수. prev_year_official_price를 주면 재산세액공제
(영 §4의3)·당해 재산세액·직전연도 총세액상당액(영 §5②)까지 전부 코드가 계산한다.
종전에는 이 셋을 호출자가 수기로 넘겨야 했고, 실제로 §4의3 분자에서 재산세
공정시장가액비율을 빠뜨리고 §5②1호의 과세표준상한 배제를 놓쳐 세액이 틀렸다.
조문이 코퍼스에 있어도 사람이 산식을 기억으로 재현하면 틀린다 — 그래서 코드로 내렸다.

산식 근거 (종합부동산세법, 2026-08-16 원문 확인 — MST 280417):
  §8①  과세표준 = (인별 공시가격 합산 − 공제금액) × 공정시장가액비율(시행령, 60~100%)
        공제금액은 호출자가 판정해 넘긴다: 1세대1주택자 12억 / 일반 9억 / 중과세율 법인 0
        ⚠️ 1세대1주택자 여부는 §8④ 간주 4유형(부속토지만·일시적2주택·상속주택·지방저가)
        포함 — 세대 판정 트리의 출력을 쓰고, 간주 유형은 9/16~9/30 신청 요건이 있다
  §9①  누진세율 — 2주택 이하 / 3주택 이상 표가 다르므로(12억 초과분부터 분기)
        주택수 판정 후 맞는 표를 tax_brackets로 전달. 법인은 §9② 비례세율(단일 구간으로 전달)
  §9③  재산세액 공제 — 동일 과세표준분 이중과세 조정. 안분 산식은 영 §4의3①이며,
        prev_year_official_price를 주면 코드가 계산한다(수기 전달도 되나 비권장).
        ⚠️ 분자는 (종부세 과세표준 × **재산세** 공정시장가액비율) × 재산세 표준세율이다 —
        공정비율을 빠뜨리고 종부세 과세표준에 재산세율을 바로 곱하면 공제가 2배 넘게 과대계산된다
  §9⑤~⑨ 1세대1주택자 세액공제 = 산출세액 × min(연령공제율 + 보유공제율, 80%)
        연령(§9⑥): 60세 20%·65세 30%·70세 40% / 보유(§9⑧): 5년 20%·10년 40%·15년 50%
        ⚠️ §9⑦⑨ 특례분(부속토지·대체취득·상속·지방저가) 안분 제외는 미지원 —
        해당 케이스는 공제가 과대계산되므로 결과에 플래그를 띄운다
  §10  세부담상한 — 해당연도 총세액상당액(재산세+종부세)이 직전연도 총세액상당액의
        150%를 초과하면 초과분은 없는 것으로 본다. 따라서 종부세 상한 =
        직전연도 총세액상당액 × 비율 − 해당연도 재산세액.
        prev_year_official_price를 주면 아래 둘을 코드가 산출한다(권장):
          · 해당연도 재산세액 — 영 §5① 1호. §110③ 과세표준상한을 **적용한 후**의 세액
          · 직전연도 총세액상당액 — 영 §5②. 직전연도에 소유하지 않았어도 소유한 것으로
            보아 직전연도 법령으로 재계산한 의제값이며(신규취득 첫해에도 상한이 작동하는
            이유), 재산세액상당액은 §110③·§111③·§112① 2호를 **배제하고** 산출한다.
            ⚠️ 종부세액상당액은 §5②2호 괄호에 따라 **직전연도 과세기준일 현재 연령·
            보유기간으로 §9⑤ 세액공제를 적용한 뒤**의 금액이다(2026-09-24 수정 —
            종전에는 이 공제를 빼먹어 직전 총세액이 과대했고, 상한이 느슨해져 당해
            종부세가 최대 34.7% 과대 산출됐다). 근거는 시행규칙 별지 제35호서식 부표
            ⑫ = 산출세액 − ⑩ 공제할 재산세액 − ⑪ 1세대1주택자 세액공제액.
            다만 같은 서식 작성방법 8 가목의 공시가격 안분비율(§8④ 간주 1주택)은 미지원.
        ⚠️ 당해연도는 과표상한 적용 후, 직전연도는 과표상한 배제 — 방향이 반대다.
        직접 넘기려면 previous_year_total_tax·burden_cap_ratio·current_year_property_tax를
        함께 주되, 위 배제 규정을 지켰는지 확인할 것(결과에 경고가 붙는다).
농어촌특별세는 종부세 납부세액의 비율(농특세법 확인, 통상 20%)로 계산 — 미확인 시 0.

Returns:
    계산 단계별 dict (검증 가능하도록)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
ageNo
yearYes
one_homeNo
credit_capNo
home_countNo
tax_bracketsNo
holding_yearsNo
age_credit_rateNo
basic_deductionNo
burden_cap_ratioNo
fair_market_ratioNo
holding_credit_rateNo
property_tax_creditNo
total_official_priceYes
rural_special_tax_rateNo
previous_year_total_taxNo
prev_year_official_priceNo
current_year_property_taxNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.1/5.0
Behavior5/5

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

Annotations (readOnly, idempotent, non-destructive, closed-world) are consistent with a pure calculator, and the description adds far more: unsupported §9⑦⑨ special-case apportionment raises a flag and overstates credit, the burden-cap direction differs between current year (cap applied) and prior year (cap excluded), rural special tax defaults to 0 when unverified, and manual passes produce warnings. This is unusually rich disclosure of failure modes and side conditions.

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

Conciseness2/5

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

The purpose and the critical input guidance are front-loaded, but the body is an unusually long statutory citation dump with inline formulas that belong in documentation. While many warnings are substantively useful, the block is dense, repetitive, and hard to scan, so an agent must wade through legal text to extract the operational instructions.

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 and 18 parameters, the description does explain the domain well: what triggers internal computation, what is flagged when unsupported, and roughly what is returned (a step-by-step dict for verification). It still does not map every parameter, but for a tool of this complexity it conveys enough to call it correctly and interpret results.

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

Parameters3/5

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

Schema description coverage is 0% across 18 parameters, so the description must carry the full burden. It explains year, prev_year_official_price, tax_brackets (per home-count table), and that the caller determines basic_deduction, but leaves several parameters unaddressed, notably the -1 sentinel defaults for age_credit_rate, holding_credit_rate, property_tax_credit, and rural_special_tax_rate, plus credit_cap, fair_market_ratio, and burden_cap_ratio. It compensates meaningfully but not completely.

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 two sentences give a specific verb+resource (compute Korea comprehensive real estate holding tax on housing) plus the exact scope it covers (deductions, progressive rates, property-tax credit, age/holding credits, burden cap). It is clearly distinguishable from siblings like calc_property_tax, calc_acquisition_tax, and calc_transfer_tax, which target other tax types.

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?

It states when specific inputs matter: year is mandatory (rates/deductions read from constant tables), prev_year_official_price is recommended because it makes the code compute §4의3 credit, current-year property tax, and prior-year total tax, and it warns when manual passing is acceptable but error-prone. It also says the §8④ deemed-one-home determination comes from the household-determination tree output. However, no sibling tools are named as alternatives, so routing is implied rather than explicit.

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