Skip to main content
Glama

payroll.kr_education_deduction

Read-onlyIdempotent

Calculates South Korean education expense tax deductions by applying 15% rates and per-person limits to categorized expenses and dependent counts.

Instructions

교육비 세액공제(소득세법 제59조의4제3항)를 구한다. expenses 는 self, preschool, elementary, middle_high, university, disabled_special 별 지출액(원 문자열), counts 는 범주별 인원이다. 공제율 15%를 정책의 인당 한도(영유아·초중고 300만원, 대학 900만원, 본인·장애인 특수교육 무한도)에 인원을 곱한 한도까지 적용해 원 미만 버린다. 여러 자녀 지출을 한 범주에 합치고 counts 를 생략하면 1명분 한도만 적용된다.

Input Schema

NameRequiredDescriptionDefault
yearYes
as_ofNo
countsNo
expensesYes
include_proposedNo

Output Schema

NameRequiredDescriptionDefault
_metaNo서버가 붙이는 영수증(integrity), 엔진, 힌트
traceYes계산 근거(tool, formula, inputs, steps, output)
per_categoryYes
total_creditYes
policy_sha256Yes
policy_sourceYes
policy_statusYes
policy_versionYes적용된 정책 문서의 식별 정보
policy_audit_idYes
policy_citationsYes정책의 근거 조문
policy_effective_toYes
policy_effective_dateYes

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?

Annotations already establish readOnly/idempotent/closed-world, so the description correctly spends its space on computation behavior: 15% rate, per-person caps by category (3M/9M/unlimited), multiplication by counts, and truncation below 1 won. It omits how include_proposed and as_of affect the calculation, which keeps it from a 5.

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?

Four dense sentences, front-loaded with the purpose and statutory basis, then parameter shape, then formula/limits, then the counts pitfall. Every sentence earns its place; it is only slightly dense in the limits sentence.

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?

Output schema exists, so return values need not be explained, and the core computation is well covered. But for a policy-sensitive tool, the semantics of as_of and especially include_proposed (proposed law changes?) are critical and left unexplained, leaving a real gap.

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?

With 0% schema description coverage, the description does real work: it enumerates the allowed expense keys (self, preschool, elementary, middle_high, university, disabled_special), states amounts are KRW strings, and defines counts as per-category headcount. But year, as_of, and include_proposed remain completely opaque in both schema and description.

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?

States a specific verb and resource (교육비 세액공제를 구한다) with the governing statute (소득세법 제59조의4제3항), which clearly separates it from payroll.kr_medical_deduction and payroll.kr_donation_deduction. It does not name a sibling or scope boundary explicitly, so it stops just short of a 5.

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?

Explains how to populate expenses and counts and warns that omitting counts when merging children's expenses applies only one person's cap – useful invocation guidance. However, there is no explicit when-to-use/when-not guidance relative to alternatives such as payroll.kr_year_end_tax_settlement or tax.kr_education_tax_add.

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