Skip to main content
Glama
Sign In
korean-tax-mcp

korean-tax-mcp

by UpstageAI
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

article_addenda

Read-onlyIdempotent

Read Korean tax law addenda to determine when an amendment applies, including effective dates, applicability periods, and transitional measures for a specific article or promulgation.

Instructions

Addenda (부칙): from when does an amendment apply? 개정 조문의 시행일·적용례·경과조치. 언제: 연중 개정된 규정을 어느 과세기간·어느 지급/양도분부터 적용하는지 판단할 때. article_history로 바뀐 시점(공포일)을 찾고 이 도구로 그 부칙을 읽는다. 입력: 법령명 → law_name, 조 → article(그 조를 언급한 부칙 줄), 공포일 → promulgated(그 개정 부칙 전문), 이후만 → since, 개수 → n. 반환: {법령, 조, 부칙: [{부칙, 공포일, 이 조 관련 / 시행일·일반 적용례 | 전문}], 읽는 법, 주의}. 읽기 전용. 법제처 공식 API — LAW_OC 필요.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "law_name": "<law_name>"
    },
    "name": "article_addenda"
  }
}

Input Schema

NameRequiredDescriptionDefault
nNo반환 부칙 수(1~20)
langNoOutput language. 'en': English keys and labels, official English texts where available (tax treaties, statutes), other Korean texts returned with a host_ai_translate instruction (your AI translates); Solar machine translation only when UPSTAGE_API_KEY or on-prem Solar is configured. 기본 'ko'ko
sinceNo이 날짜(YYYYMMDD) 이후 공포된 부칙만
articleNo이 조를 언급한 부칙만(예 '제87조'). promulgated를 주면 생략 가능
law_nameYes법령 정식 명칭. 예: '소득세법', '소득세법 시행령'
promulgatedNo특정 개정의 공포일 YYYYMMDD — 그 부칙 전문(시행일·일반 적용례·경과조치). article_history의 공포일을 그대로

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.12.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/destructive/openWorld, but the description adds non-obvious context: it is read-only, backed by the official 법제처 API, and requires the LAW_OC credential, which an agent must know before calling. It also sketches the return payload and notes a '읽는 법 / 주의' section, though no rate limits or failure behavior are mentioned.

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 purpose is front-loaded in the first line, followed by labeled 언제/입력/반환 blocks that make scanning easy. The 입력 block is somewhat redundant against the schema and the bilingual glossing adds density, but nothing is genuinely off-topic.

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 usefully previews the response shape (법령, 조, 부칙 list with 시행일/적용례/전문, 읽는 법, 주의) and discloses the auth prerequisite. The one unaddressed area is the lang/translation behavior, which is left entirely to the schema.

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 coverage is 100% and every parameter already carries a descriptive string, so the '입력' mapping (법령명→law_name, 조→article, 공포일→promulgated, 이후만→since, 개수→n) largely restates the schema. It adds mild workflow framing around article/promulgated dependency, but nothing the schema does not already convey, so baseline 3 applies.

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 opening states a specific resource (부칙/addenda) and the exact question it answers: from when an amendment applies (시행일·적용례·경과조치). It also differentiates from the sibling article_history by assigning that tool the promulgation-date lookup and this one the reading of the addenda text.

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

Usage Guidelines5/5

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

The '언제' block gives an explicit usage condition (judging which tax period or which payment/transfer an amended rule applies from) and prescribes the alternative workflow: find the promulgation date with article_history, then read the addenda here. The article vs. promulgated choice is also routed (promulgated → article may be omitted).

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