Skip to main content
Glama
Sign In

korea-tax-law-mcp

by io.github.minsooparkk
OverviewDiscussionsAdmin

get_article

Read-onlyIdempotent

특정 조문의 원문 전체를 반환한다. as_of가 없으면 현행 판(시행일·검증된 위임 상·하위법령·별표·검증된 인용 포함), as_of를 주면 그날 시행 중이던 판(시행 구간·판 목록·부칙 요약)을 준다 — 지난 사업연도·과세기간·경정청구 대상 연도 판단에 쓴다. 그 날짜의 판이 수록 전·미검증이면 현행으로 대신하지 않고 '확인 불가'로 답한다. 세법 조문은 TaxDoctorAI 3단보기 링크를 제공한다. as_of 응답의 현행 3단보기는 당시 판이 아니다. 세율·한도·요건 등 정확한 수치는 반드시 이 도구로 원문을 확인할 것. 인용은 적용 확정이 아니다. 법령명이 비세법 참조 법령(민법·주택법 등)이면 '세법이 아님' 표시와 함께 그 조문을 준다.

Input Schema

NameRequiredDescriptionDefault
as_ofNo선택: 기준일 (예: '2025-12-31' — 사업연도 말일·거래일·증여일). 그날 시행 중이던 판을 준다. 없으면 현행
law_nameYes법령명 (예: '소득세법', '상속세 및 증여세법'). 약칭(조특법·상증법·국기법)·띄어쓰기 차이도 받는다
article_numberYes조번호 (예: '제97조의2', '97조의2', '55')
effective_dateNoas_of와 같다(다른 법령 도구와 맞춘 이름)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / as_of
      Added value: +{
+  "description": "선택: 기준일 (예: '2025-12-31' — 사업연도 말일·거래일·증여일). 그날 시행 중이던 판을 준다. 없으면 현행",
+  "type": "string"
+}
    • addedInput schema / properties / effective_date
      Added value: +{
+  "description": "as_of와 같다(다른 법령 도구와 맞춘 이름)",
+  "type": "string"
+}
  2. Changed1 schema field changed
    • changedInput schema / properties / law_name / description
      Previous value: -"법령명 (예: '소득세법', '상속세 및 증여세법')"New value: +"법령명 (예: '소득세법', '상속세 및 증여세법'). 약칭(조특법·상증법·국기법)·띄어쓰기 차이도 받는다"
  3. First observed

TDQS

A4.3/5.0
Behavior5/5

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

Beyond the read-only annotations, the description discloses important behavior: no substitution of current law when the requested dated version is unloaded or unverified, explicit 'unable to confirm' handling, and a caveat that the current three-column view is not the historical version. It also notes non-tax-law handling and that citations do not confirm application.

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 and every sentence appears to carry relevant legal-retrieval caveats. It is dense and somewhat run-on for the number of edge cases it covers, but it avoids redundant filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/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 still explains what is returned in both current and as_of modes, including effective dates, delegated statutes, annexes, citations, effective periods, version lists, and supplementary-provision summaries. It also covers the critical unverified-date and non-tax-law edge cases, making it complete enough for correct invocation.

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 the schema already documents the parameters in detail. The description adds meaningful parameter behavior beyond the schema, especially the unverified-date fallback for as_of and the warning that a current three-column view in an as_of response is not the historical version.

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 uses a specific verb and resource: it returns the full original text of a particular article, and it explains the current-version versus as_of-version distinction. It does not explicitly distinguish itself from sibling tools such as get_reference_article or search_articles, so it is clear but not fully sibling-differentiating.

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 concrete usage contexts, especially for as_of when determining past fiscal years, tax periods, or refund-claim years, and states that exact rates, limits, and requirements must be confirmed through this tool. It does not name alternatives or explicitly say when not to use it, so the guidance is strong but not complete.

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

All korea-tax-law-mcp toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources