Skip to main content
Glama
taylee9809

budongsan-tax

by taylee9809
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

Property tax (재산세)

calc_property_tax
Read-onlyIdempotent

Calculate Korean housing property tax (재산세) by year, applying fair-market ratio, taxable base cap, one-household relief, urban area levy, and local education tax.

Instructions

Korea property tax (재산세) on housing: fair-market ratio, base cap, one-household special rate, urban area levy, education tax.

재산세(주택분 중심)를 계산한다. 세율·비율은 year로 상수표에서 읽는다.

⚠️ 2026-08-30 변경 — year가 필수가 됐고, 세율표·공정시장가액비율·도시지역분·
지방교육세율은 data/tax_params.json(1층)에서 자동으로 읽는다. 그 연도가 검증되지
않았으면 ParamNotVerified로 계산을 거부한다. 종전에는 호출자가 전부 넘겨야 했고
빠뜨리면 조용히 틀렸다 — 실제로 과세표준상한제 누락으로 세액이 틀린 사고가 있었다.
명시 인자를 주면 그것이 우선하되, 결과의 "값 출처"에 표시된다.

산식 근거 (지방세법, 2026-08-16 원문 확인 — MST 282559):
  §110① 과세표준 = 시가표준액(주택은 공시가격) × 공정시장가액비율
         (비율은 시행령 §109 — 매년 5~6월경 개정되므로 하드코딩하지 않는다.
          참고로 2026년 기준 주택 60%, 1세대1주택은 공시가별 43~45%였음)
  §110③ 주택 과세표준상한제(2023 신설) — 직전연도 기반 상한액이 계산돼 있으면
         taxable_base_cap으로 넘기면 min()을 적용한다
  §111① 누진세율 — tax_brackets로 전달. 1세대1주택 9억 이하 특례세율(§111의2)은
         ⚠️ 2026-12-28까지 성립분만 유효한 일몰 조항이므로 적용 전 유효기간 확인
  §111③ 조례 ±50% 가감 — 호출자가 세율표에 반영해서 넘길 것
  §112  도시지역분 = 과세표준 × 0.14%(조례로 최대 0.23%) — urban_area_rate로 전달
  §122  세부담상한 150%는 주택에는 적용하지 않음(과표상한제로 대체) — 토지·건축물을
        이 함수로 계산하는 경우 상한 적용은 호출자 책임

지방교육세는 재산세 본세(도시지역분 제외)에 대한 비율로 계산한다 — 세율은
지방세법 §151 확인 후 전달(미확인 시 0).

Args:
    official_price: 시가표준액/공시가격 (원)
    year: 과세연도(납세의무 성립연도). 상수표 조회 키이며 필수다.
    prev_year_official_price: 직전연도 시가표준액 — 주면 §110③ 과세표준상한액을
        자동 계산한다. 안 주면 상한제가 적용되지 않으니 주택은 사실상 필수.
    one_home: 지방세법 영 §110의2 1세대1주택 여부. 세대(배우자 포함) 기준이며
        판정 결과를 넘길 것 — 인별 1주택과 다르다.
    fair_market_ratio: 공정시장가액비율. 0이면 상수표에서 읽는다.
    tax_brackets: 세율표. None이면 상수표에서 읽는다.
    urban_area_rate: 도시지역분 세율. 음수면 상수표, 0을 명시하면 미적용 지역.
    local_education_tax_rate: 지방교육세율. 음수면 상수표에서 읽는다.
    taxable_base_cap: 과세표준상한액(원). 0이고 prev_year_official_price가 있으면
        자동 계산한다.

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

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
yearYes
one_homeNo
tax_bracketsNo
official_priceYes
urban_area_rateNo
taxable_base_capNo
fair_market_ratioNo
local_education_tax_rateNo
prev_year_official_priceNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already establish a safe, deterministic, idempotent read operation, so the description's job is to add beyond that — and it does: calculation is refused with ParamNotVerified for unverified years, explicit arguments take precedence over the constant table, and the result records a '값 출처' (value provenance). The background anecdote about a prior calculation error is not strictly behavior, but the operational contract is well disclosed.

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?

The English summary is front-loaded and the Korean argument list is well organized, but the statutory-citation block and the historical incident anecdote add length beyond what an agent strictly needs to invoke the tool correctly. Given nine parameters and five statutory rules, the length is largely earned, so this is not a structural failure.

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?

No output schema exists, but the description states the return shape (per-step dict plus value provenance) and the failure mode (ParamNotVerified). For a nine-parameter tax calculator whose rates live in an external constant table, everything an agent needs to call it correctly — required year, upstream table lookup, precedence of explicit args, cap handling — is present.

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?

With 0% schema description coverage, the description carries the full burden and covers all nine parameters, including the non-obvious sentinel semantics (fair_market_ratio=0 and negative rates read from the constant table; urban_area_rate=0 explicitly means 'not applied'; taxable_base_cap=0 with prev_year_official_price triggers auto-computation). It also clarifies that one_home is judged at household level, not per individual.

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 line names a specific verb and resource (Korea property tax on housing) and enumerates the components computed: fair-market ratio, base cap, one-household special rate, urban area levy, education tax. The sibling list is a set of distinct tax calculators, and the mention of housing-specific rules (재산세 주택분) plus the §122 note about land/buildings makes the scope distinguishable.

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?

Usage context is clear: it is the housing property-tax calculation, and the parameter notes tell the agent that prev_year_official_price is '사실상 필수' for housing and that the cap rule does not apply to housing (§122). It also implicitly excludes land/buildings by pushing cap responsibility to the caller. No sibling is named as an explicit alternative, so this falls short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools