Skip to main content
Glama

tax.kr_gift

Read-onlyIdempotent

Calculates Korean gift tax from gift amount, relationship, and year, applying deductions, progressive rates, generation-skip surcharge, and timely filing credit.

Instructions

한국 증여세를 계산한다(상속세및증여세법 제53조·제53조의2·제56조·제57조·제69조). 금액은 원 단위 Decimal 문자열이다. 관계별 증여재산공제에서 10년 내 기공제액을 빼고, marriage_birth_gift=true 이면 직계존속 증여에 혼인·출산 공제 1억을 더하며, 10~50% 누진세율에 generation_skip=true 일 때 세대생략 할증(30%, 미성년 20억 초과 40%)과 기한 내 신고세액공제 3%를 반영한다. tax 는 신고세액공제 전 금액이고 공제 후는 tax_after_filing_credit 이다. 10년 내 기공제액은 prior_deduction_used_10y 로 직접 넣는다.

Input Schema

NameRequiredDescriptionDefault
yearYes
as_ofNo
decimalsNo
roundingNoHALF_UP
gift_amountYes
relationshipYes
timely_filingNo
generation_skipNo
include_proposedNo
marriage_birth_giftNo
prior_deduction_used_10yNo0
prior_marriage_birth_deductionNo0

Output Schema

NameRequiredDescriptionDefault
taxYes
_metaNo서버가 붙이는 영수증(integrity), 엔진, 힌트
traceYes계산 근거(tool, formula, inputs, steps, output)
breakdownYes
deductionYes
gift_amountYes
computed_taxYes
taxable_baseYes
filing_creditYes
marginal_rateYes
policy_sha256Yes
policy_sourceYes
policy_statusYes
effective_rateYes
policy_versionYes적용된 정책 문서의 식별 정보
policy_audit_idYes
total_deductionYes
policy_citationsYes정책의 근거 조문
policy_effective_toYes
policy_effective_dateYes
tax_after_filing_creditYes
marriage_birth_deductionYes
generation_skip_surchargeYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.0

TDQS

A3.6/5.0
Behavior4/5

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

The annotations already establish read-only, idempotent, and closed-world behavior. The description adds useful behavioral context: amounts are Decimal strings in KRW, prior deductions are entered directly via prior_deduction_used_10y, and tax versus tax_after_filing_credit is distinguished.

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 description is dense but front-loads the purpose and then proceeds to calculation rules and output semantics. The legal citations and detailed calculation notes are relevant to a tax calculator, though the paragraph is packed and could be structured more cleanly.

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?

This is a complex 12-parameter calculator with an output schema, and the description covers the overall method and several critical flags. Still, important parameter semantics remain missing, especially allowed relationship values and the meaning of as_of and include_proposed, so it is only minimally complete for correct invocation.

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%, so the description must carry parameter meaning. It explains key domain-specific parameters such as marriage_birth_gift, generation_skip, prior_deduction_used_10y, and the Decimal-string amount convention, but leaves relationship values, year, as_of, include_proposed, rounding, decimals, and prior_marriage_birth_deduction undocumented.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: '한국 증여세를 계산한다' (calculates Korean gift tax), and cites the governing tax law articles. It is clearly distinct in domain from the inheritance-tax sibling, but it does not explicitly name alternatives or route the agent between related tax tools.

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

Usage Guidelines3/5

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

The description explains internal calculation conditions such as marriage_birth_gift and generation_skip, which implies when those options apply. However, it gives no explicit guidance on when to choose this tool versus tax.kr_inheritance or other tax calculators, so usage must be inferred from the purpose.

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