Skip to main content
Glama
UpstageAI

korean-tax-mcp

by UpstageAI
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

research_issue

Read-onlyIdempotent

Bundle everything that applied to an issue at a past date. 그 해 기준 묶음 조회 — 사실 발생 시점의 조문(3단)·기본통칙·집행기준·그 조문을 인용한 해석·판례를 한 번에. 언제: 세무조사·불복처럼 특정 사업연도에 적용되는 근거를 정리할 때.

Instructions

Bundle everything that applied to an issue at a past date. 그 해 기준 묶음 조회 — 사실 발생 시점의 조문(3단)·기본통칙·집행기준·그 조문을 인용한 해석·판례를 한 번에. 언제: 세무조사·불복처럼 특정 사업연도에 적용되는 근거를 정리할 때. 시점 판단을 코드로 고정한다 — 기준일(법인·소득·부가는 사업연도·과세기간 종료일, 양도는 양도일, 상속은 상속개시일, 증여는 증여일, 원천은 지급일), 기준일 조문과 현행 조문의 변경 여부, 해석·판례마다 등록일 당시 조문이 기준일 조문과 같은지. 반환: {기준일, 기준일 근거, 그 해 조문(3단), 현행과 비교, 기본통칙[], 집행기준[], 해석·판례[{…, 기준일 조문과}], 시기 규칙[]?, 주의}. 읽기 전용. 조문 부분은 LAW_OC 필요(없으면 해석·통칙만 반환). 10~30초.

Input Schema

NameRequiredDescriptionDefault
nNo해석·판례 종류별 최대 건수 1~20
taxNo세목. 부가세 과세기간 판단과 해석 필터에 사용 (선택)
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
eventNo사건 기준 세목. 양도=양도일(잔금일), 상속=상속개시일, 증여=증여일(등기 대상은 등기접수일), 원천=지급일. 주면 period는 날짜여야 함
periodYes사실이 속한 시점: '2023'(사업연도·과세기간), '2023-1'(부가 1기), '2023-12-31'(날짜)
articleYes조문 번호. '제52조' 또는 '제28조의2' 형식
law_nameYes세법 이름(정식 명칭). 예: '법인세법', '부가가치세법', '소득세법', '상속세 및 증여세법', '국세기본법'
registeredNo양도: 소유권이전등기 접수일 YYYY-MM-DD (잔금일보다 빠르면 이 날이 양도일, 선택)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.9.1
    • addedInput schema / properties / event
      Added value: +{
+  "anyOf": [
+    {
+      "enum": [
+        "양도",
+        "상속",
+        "증여",
+        "원천"
+      ],
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "사건 기준 세목. 양도=양도일(잔금일), 상속=상속개시일, 증여=증여일(등기 대상은 등기접수일), 원천=지급일. 주면 period는 날짜여야 함",
+  "title": "Event"
+}
    • changedInput schema / properties / lang / description
      Previous value: -"Output language. 'en': English keys and labels, official English texts where available (tax treaties, statutes), titles/summaries machine-translated by Upstage Solar when UPSTAGE_API_KEY is set. 기본 'ko'"New value: +"Output 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'"
    • addedInput schema / properties / registered
      Added value: +{
+  "default": "",
+  "description": "양도: 소유권이전등기 접수일 YYYY-MM-DD (잔금일보다 빠르면 이 날이 양도일, 선택)",
+  "title": "Registered",
+  "type": "string"
+}
  2. Addedv0.4.0

TDQS

A4/5.0
Behavior4/5

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

Annotations already declare readOnly, openWorld, idempotent, non-destructive. The description adds valuable behavioral details beyond annotations: it requires LAW_OC for the article portion (otherwise only interpretations/rulings are returned), notes a 10–30 second latency, and describes the return structure including timing rules and caveats. This is meaningful supplementary transparency.

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 front-loaded with the core purpose, then provides when-to-use, return structure, dependency, and latency. It is dense but every sentence conveys information necessary for a complex, multi-output tool. The bilingual repetition adds slight length but no wasted content.

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?

Given the tool's complexity (8 params, composite output, no output schema), the description is largely complete: it covers purpose, usage context, return format, external dependency, and latency. It does not detail error handling or the '주의' field's semantics, but these are minor gaps for an experienced agent.

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 description coverage is 100%, so baseline is 3. The description adds semantic meaning by explaining how period is interpreted for different tax types and events (e.g., corporate/income/VAT use fiscal period end; transfer uses transfer date, inheritance uses death date, etc.) and ties event to date requirement. This exceeds the schema's individual param descriptions.

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: 'Bundle everything that applied to an issue at a past date.' It then enumerates the bundled components (article at past date, basic rules, execution standards, interpretations, cases), making the composite nature clear. It does not explicitly contrast with siblings like law_article or basic_rules, but the bundle concept distinguishes it.

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?

It gives a clear usage context: '언제: 세무조사·불복처럼 특정 사업연도에 적용되는 근거를 정리할 때' (when organizing the basis applicable to a specific fiscal year for tax audits/appeals). No when-not or explicit alternatives are provided, so it falls short of a 5, but the context is clear.

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