Skip to main content
Glama

Capital gains reliefs

judge_transfer_reliefs
Read-onlyIdempotent

Decide capital gains exemptions, heavy-rate exclusions, long-term deduction table and high-value apportionment, producing calc_transfer_tax inputs.

양도세 비과세·중과·장특공·고가주택 안분 판정 → calc_transfer_tax 인자 생성.

소득세법 §89·§95(표1/표2·중과 시 장특공 배제)·§104⑦·영 §159의4·§160·한시배제(영
§167의3①12호의2)를 한 번에 판정한다. 세대·주택수(트리①②)와 비과세 요건 충족 여부는
입력으로 받는다 — 이 함수는 그 출력을 세율·공제로 변환하는 판정 레이어.

sale_date를 반드시 넣을 것 — 중과 가산세율이 양도일로 갈린다. 2021-06-01 이후 양도분은
2주택 +20%p / 3주택 +30%p이고 **그 전은 +10%p / +20%p**다(법 17477호 부칙 §3).
중과 한시배제(영 §167의3①12호의2)는 **창(窓)이다** — 2022-05-10 이후 ~ 2026-05-09까지
양도분이고, **보유기간 2년 이상**이 대전제다. 그 기간을 넘겨 양도하더라도 2026-05-09까지
매매계약을 체결하고 계약금을 받았다면 계약일부터 4개월(일부 지역 6개월) 내 양도까지
배제된다 — contract_date·deposit_received·contract_months_limit로 판정한다(나·다목).
반환의 surcharge_rate·long_term_deduction_rate를 calc_transfer_tax에 그대로 넘기고,
과세대상_양도차익_비율(<1이면 고가주택)은 양도차익에 곱해 안분한다.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sale_dateNo
sale_priceYes
contract_dateNo
holding_yearsYes
residing_yearsYes
adjusted_at_saleNo
deposit_receivedNo
heavy_home_countNo
contract_months_limitNo
is_one_household_one_homeYes
meets_exemption_requirementsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so the bar is lower, yet the description adds substantial context: date-dependent surcharge rates (2021-06-01 split), the limited-window exclusion rule, the 4-month (or 6-month) contract-date carve-out, and the 2-year holding prerequisite. It also documents return fields (surcharge_rate, long_term_deduction_rate, 과세대상_양도차익_비율), which matters since no output schema exists.

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?

Content is front-loaded with the purpose before the legal detail, which is good, but the opening English and Korean sentences restate the same purpose verbatim, and the body is dense with statute citations. Duplication and volume dilute an otherwise well-ordered description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an 11-parameter tool with no output schema and no schema descriptions, the description covers the temporal rules and return values well but omits behavior for several parameters (adjusted_at_sale, sale_price, residing_years). An agent can call it correctly on the date path but not fully on the others.

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 11 params, so the description must carry the load and only partially does: it explains sale_date (mandatory), contract_date, deposit_received, contract_months_limit, holding_years implicitly, and the exemption/home-count inputs. Parameters such as adjusted_at_sale, sale_price, and residing_years are never given meaning, leaving real gaps.

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 verb (decide) and named resources (exemptions, heavy-rate exclusions, long-term deduction, high-value apportionment) and defines its role as a 판정 레이어 that converts household/home-count output into rates and deductions. This boundary statement distinguishes it from siblings like calc_transfer_tax (which consumes its output) and the count/judge prerequisite 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?

Explicitly states that household/home count and exemption-requirement satisfaction are received as inputs rather than computed here, implying the correct call order relative to count_heavy_homes / judge_exemption_requirements. It also mandates sale_date, but does not name alternative sibling tools to prefer in edge cases.

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