Skip to main content
Glama
UpstageAI

korean-tax-calc-mcp

donation_limit

Read-onlyIdempotent

Compute Korean corporate tax donation deduction limits, including special 50% and general 10% caps, excess amounts, and carryforwards for a given year.

Instructions

기부금 손금산입 한도(특례기부금 50%, 일반기부금 10%)와 한도초과·이월. 언제: 기부금을 손금산입할 때 한도와 한도초과액을 구한다. 입력: 기준소득(과세표준 계산 전 소득금액, 원) → base_income, 특례기부금 지출액(원) → special, 일반기부금 지출액(원) → general, 결손금(원) → carried_loss, 특례 이월액(원) → special_carry, 일반 이월액(원) → general_carry, 중소기업 여부 → sme, 사회적기업 여부 → social_enterprise, 사업연도(2016~2026) → year. 결과: 한도·한도초과·이월 손금산입, 근거(법인세법 제24조).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
smeNo중소기업 여부
yearYes사업연도·귀속연도(2016~2026)
generalNo금액(원)
specialNo금액(원)
base_incomeYes금액(원)
carried_lossNo금액(원)
general_carryNo금액(원)
special_carryNo금액(원)
social_enterpriseNo사회적기업 여부(일반한도 20% 적용)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.9.1

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive/no-open-world, so the safety profile is covered. The description adds substantive domain behavior beyond that: the applied rates (특례 50%, 일반 10%), the carryforward handling, and the year range. It does not contradict any annotation.

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?

Front-loaded with purpose, then cleanly organized into 언제/입력/결과 blocks. The parameter list is somewhat long but each mapping earns its place given the generic schema labels; no filler sentences.

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, the description carries the return-value burden and does state the results (한도·한도초과·이월 손금산입) plus the legal citation. Inputs are fully mapped. Minor gap: no note on output units or the interaction between carried_loss and the limits.

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

Parameters4/5

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

Schema coverage is 100%, so baseline is 3, but the schema's own descriptions are mostly generic ('금액(원)'). The description supplies the real semantics for each name (base_income=과세표준 계산 전 소득금액, special=특례기부금 지출액, carried_loss=결손금, etc.), adding genuine meaning over the schema.

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 description names a specific verb+resource (기부금 손금산입 한도 = donation deduction limit) and enumerates the exact outputs (한도·한도초과·이월 손금산입). It also anchors the tool to a legal basis (법인세법 제24조), which clearly separates it from sibling limit tools like entertainment_limit and loss_carryforward_limit.

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?

An explicit '언제' clause states when to use it: 'compute the limit and excess when deducting donations.' This is clear contextual guidance, but no when-not conditions or named alternatives (e.g. when to prefer loss_carryforward_limit) are given.

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