Skip to main content
Glama
ctahoon55

taxlaw-mcp

by ctahoon55
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

taxlaw-mcp — 국세청 예규 본문 보완 MCP

법제처 OPEN API(korean-law MCP)는 국세청 예규(법령해석)를 목록만 주고 본문은 주지 않습니다. 이 작은 MCP 서버는 그 빈칸을 메웁니다. 목록은 법제처에서, 본문은 국세법령정보시스템(taxlaw.nts.go.kr) 공개 페이지에서 가져옵니다.

원칙: korean-law MCP 를 그대로 쓰고, 국세청 예규 본문이 필요할 때만 이 서버의 도구를 부릅니다.

도구 2개

도구

하는 일

search_tax_interpretation

검색어로 국세청 예규 목록 조회. 결과마다 안건명·안건번호·해석일자·ntstDcmId

get_tax_interpretation

ntstDcmId(숫자 18자리)로 본문을 받아 HTML 을 지운 평문으로 반환. 표는 줄바꿈·탭으로 유지

본문 끝에는 항상 두 줄이 붙습니다.

출처: https://taxlaw.nts.go.kr/qt/USEQTA002P.do?ntstDcmId=<18자리>
⚠️ 법제처 OPEN API 가 아닌 국세법령정보시스템 공개 페이지에서 가져온 본문입니다. 인용 전 원문으로 대조하세요.

Related MCP server: Korean Law MCP Server

설치 (Node.js 20 이상)

방법 A — 설치 없이 바로 (다른 PC 에 권장)

Claude Code:

claude mcp add -s user taxlaw -e LAW_OC=<법제처_인증키> -- npx -y github:ctahoon55/taxlaw-mcp

Claude Desktop 설정 파일의 mcpServers 에:

"taxlaw": { "command": "npx", "args": ["-y", "github:ctahoon55/taxlaw-mcp"], "env": { "LAW_OC": "<법제처_인증키>" } }

첫 실행 때만 내려받느라 몇 초 걸리고, 이후엔 캐시를 씁니다.

윈도우(PowerShell)는 두 가지가 다릅니다.

  1. npx 앞에 cmd /c 를 붙여야 Claude Code 가 서버를 띄울 수 있습니다.

  2. github: 주소는 Git 이 설치돼 있어야 받아지므로, Git 이 없는 PC 는 아래처럼 압축 파일 주소를 씁니다.

claude mcp add -s user taxlaw -e LAW_OC=<법제처_인증키> -- cmd /c npx -y https://github.com/ctahoon55/taxlaw-mcp/tarball/main

<법제처_인증키> 는 꺾쇠 없이 본인 키만 넣습니다 (PowerShell 은 < 를 그대로 두면 오류).

제대로 됐는지 확인

claude mcp get taxlaw

Status: ✔ Connected 가 보이면 됩니다. 그 다음 Claude Code 안에서 /mcp 를 치면 taxlaw 에 도구 2개가 잡혀 있고, "국세청 예규에서 '접대비 한도' 검색해서 첫 번째 본문 보여줘" 라고 물으면 끝에 출처: https://taxlaw.nts.go.kr/... 줄이 붙은 답이 옵니다. Failed to connect 면 ① Node.js 설치 여부(node -v) ② 윈도우는 cmd /c 누락 ③ 인증키 꺾쇠 순으로 확인하세요.

방법 B — 코드를 받아서 (수정하며 쓸 때)

git clone https://github.com/ctahoon55/taxlaw-mcp.git && cd taxlaw-mcp && npm install --omit=dev

Claude Code 에 등록 (인증키는 법제처 OPEN API 신청 시 받은 ID):

claude mcp add -s user taxlaw -e LAW_OC=<법제처_인증키> -- node /절대경로/taxlaw-mcp/src/server.js

Claude Desktop 은 설정 파일의 mcpServers 에 같은 내용을 넣으면 됩니다:

"taxlaw": { "command": "node", "args": ["/절대경로/taxlaw-mcp/src/server.js"], "env": { "LAW_OC": "<법제처_인증키>" } }

점검

npm test                      # 단위 테스트 (네트워크 불필요)
LAW_OC=<키> npm run check:live  # 실제 서버 띄워 검색→본문→없는 번호 순서로 호출

예의 규칙 (공식 API 가 아니므로 코드로 강제)

  • 국세청 서버 연속 호출 사이 0.4초 이상 간격, 재시도 1회까지

  • 응답 읽기 상한 5MB (실측 2MB 중 99%는 무관한 목록이고 본문은 그 뒤에 있어 2MB 로 두면 잘림)

  • GET 이나 잘못된 Referer 는 404 가 아니라 200 + 홈페이지 HTML 로 옴 → "JSON 이 아니면 실패"로 판정

  • 요지·회신·본문을 공백 빼고 이어 20자 미만이면 문서 없음

구조 — 자료원 하나 = 파일 하나

src/server.js                    도구 등록 (여기에 registerTool 추가)
src/sources/nts-interpretation.js 국세청 예규 (검색 + 본문)
src/lib/http.js                  간격 제한·상한·재시도
src/lib/html-to-text.js          HTML → 평문 (표 유지)
test/                            단위 테스트

법제처가 못 주는 다른 자료를 발견하면 src/sources/ 에 파일을 하나 추가하고 server.js 에 도구를 등록하면 됩니다.

실측 기록 (2026-09-02)

  • 검색 XML 의 법령해석상세링크 안에 ntstDcmId 가 그대로 들어 있음 (변환 불필요)

  • 본문: POST https://taxlaw.nts.go.kr/action.do · actionId=ASIQTB002PR01 · paramData={"dcmDVO":{"ntstDcmId":"…"}}

  • 본문 위치: data.ASIQTB002PR01.dcmHwpEditorDVOList[].dcmFleByte (HTML), 메타는 dcmDVO (ntstDcmTtl·ntstDcmDscmCntn·ntstDcmRgtDt·ntstDcmGistCntn·ntstDcmCntn)

  • 오래된 예규는 HTML 본문이 비어 있고 요지·회신만 있는 경우가 있음 (정상)

Available Tools

2 tools
get_tax_interpretation국세청 예규 본문A
Read-only

[국세청 예규 본문 조회] ntstDcmId(숫자 18자리, 또는 taxlaw.nts.go.kr 링크)로 예규 전문을 받아 HTML 을 지운 평문으로 돌려준다(표는 줄바꿈·탭 유지). 제목·문서번호·생산일자·요지·회신·본문 순. 법제처 OPEN API 는 국세청 예규 본문을 제공하지 않으므로 국세법령정보시스템 공개 페이지에서 가져온다. 끝에 출처 링크와 '원문 대조' 경고가 붙는다 — 인용 시 그대로 전달할 것.

ParametersJSON Schema
NameRequiredDescriptionDefault
ntstDcmIdYes숫자 18자리 (search_tax_interpretation 결과의 ntstDcmId) 또는 상세 링크 URL

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the readOnlyHint/openWorldHint annotations, the description discloses the HTML-stripping behavior, table whitespace retention, fixed section order, source acquisition rationale, and the appended source link with the '원문 대조' warning. This is substantial behavioral context that annotations alone do not provide.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core action and input, then compactly states output formatting, ordering, source rationale, and citation warning. Every clause earns its place; no 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?

For a single-parameter, read-only tool with no output schema, this description covers input forms, output type/structure, source, and a critical usage warning (keep the '원문 대조' warning when citing). Nothing needed to call it correctly is missing.

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?

The schema already documents ntstDcmId at 100% coverage, giving the baseline of 3. The description adds the exact accepted domain (taxlaw.nts.go.kr link) and reinforces the relationship to search_tax_interpretation outputs, providing a bit more meaning than the generic '상세 링크 URL' in 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?

States a specific operation ('예규 전문을 받아 ... 평문으로 돌려준다'), an exact input resource (ntstDcmId or taxlaw.nts.go.kr link), and the output format/order. It also implies differentiation from the sibling search_tax_interpretation by referencing that tool's ntstDcmId as the input source.

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?

The description and schema make clear this tool consumes an ntstDcmId produced by search_tax_interpretation, so the intended workflow is find-then-fetch. It explains why it fetches from the NTS public page rather than the law office API, but it does not explicitly state when NOT to use it or name the sibling as the search alternative.

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

search_tax_interpretation국세청 예규 검색A
Read-only

[국세청 예규·법령해석 검색] 법제처 OPEN API(target=ntsCgmExpc)로 국세청이 직접 회신한 예규(서면·재산·법인·부가 등)를 검색한다. 결과마다 안건명·안건번호·해석일자·ntstDcmId 를 보여준다. 본문은 ntstDcmId 로 get_tax_interpretation 을 호출한다. korean-law 의 search_decisions(domain='nts') 와 같은 목록이지만 본문 조회용 ntstDcmId 를 바로 준다.

ParametersJSON Schema
NameRequiredDescriptionDefault
pageNo페이지 (기본 1)
sortNo정렬: lasc(안건명↑) ldes(안건명↓) dasc(해석일자↑) ddes(해석일자↓)
queryYes검색어 (예: '1세대 1주택 비과세', '접대비 한도')
explYdNo해석일자 범위 YYYYMMDD~YYYYMMDD (예: '20200101~20251231')
searchNo검색범위 1=안건명(기본) 2=본문
displayNo페이지당 건수 (기본 20, 최대 100)

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already carry readOnlyHint=true, so the safety profile is covered. The description adds meaningful behavioral context beyond annotations: it names the upstream API (target=ntsCgmExpc), states that only list fields are returned (not full text), and reveals that the result includes ntstDcmId for subsequent full-text lookup. This gives the agent a clear model of the tool's boundaries.

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 a single compact paragraph with the tool name in brackets, a clear verb, and then the essential distinctions. Each sentence adds value: what it searches, what it returns, how to get full text, and how it differs from a related search. It is slightly dense but economical for the information conveyed.

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?

Even though there is no output schema, the description explicitly lists the four return fields, so an agent knows what to expect. It also routes the agent to the sibling tool for the full text, covering the most important follow-up. Pagination and sorting are documented in the schema, so the description is sufficiently complete for a read-only search tool.

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 description coverage is 100% and each parameter (query, sort, search, explYd, display, page) already has descriptive text. The tool description adds little to parameter semantics themselves, though it contextualizes why ntstDcmId matters. Baseline 3 is appropriate because the schema carries the parameter-documentation burden.

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 uses a specific verb '검색한다' (searches) against a well-defined resource: National Tax Service precedents via the Law Making Information API. It explicitly lists the result fields (안건명, 안건번호, 해석일자, ntstDcmId) and distinguishes itself from the sibling get_tax_interpretation by noting that the full text must be fetched via that tool.

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 states that full text retrieval requires calling get_tax_interpretation with ntstDcmId, which tells the agent when to switch to the sibling. It also compares itself to korean-law's search_decisions(domain='nts'), noting it is the same list but with the ntstDcmId readily available. However, it doesn't explicitly spell out 'use this only for list retrieval' as a when-not condition.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 2 tool updatesv0.1.0
    • First observedget_tax_interpretation
    • First observedsearch_tax_interpretation
Deploy Server
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

TDQS

A4.4/5.0

Scored across 2 tools

Disambiguation5/5

The two tools have clearly distinct roles: one searches and returns metadata with IDs, the other retrieves the full text by ID. There is no overlap or ambiguity between them.

Naming Consistency5/5

Both tool names follow the same verb_noun pattern: search_tax_interpretation and get_tax_interpretation. The naming is perfectly consistent and predictable.

Tool Count4/5

With only two tools, the set is minimal and slightly below the typical 3-15 range, but it fits the server's narrow purpose well. The two tools form a complete search-then-fetch workflow without unnecessary extras.

Completeness5/5

The server fully covers its intended read-only domain: searching for tax interpretations and retrieving their full text. There are no obvious gaps or dead ends in the workflow.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • taxlaw-nts-mcp

    kim-go-chon
    A
    license
    A
    quality
    B
    maintenance
    Enables searching and retrieving tax law data from the Korean National Tax Service database, including interpretations, rulings, forms, publications, and site menus via MCP tools.
    14
    1
    MIT

  • Korean Law MCP Server

    woongaro
    A
    license
    Not graded
    quality
    D
    maintenance
    Enables searching and retrieving Korean statutes, precedents, and constitutional court decisions via MCP, using the National Law Information Center API.
    2,938 npm
    1
    MIT

  • LexLink-ko-mcp

    joohyukjung
    F
    license
    A
    quality
    C
    maintenance
    MCP server for Korean National Law Information. Enables searching and retrieving Korean laws, English-translated laws, administrative rules, court precedents, and constitutional decisions via 54 MCP tools.
    54
    -

  • nts-taxlaw-mcp

    zisu17
    A
    license
    A
    quality
    B
    maintenance
    MCP server that directly queries the Korean National Tax Service tax law information system for tax law interpretations, precedents, and guidance. It supports exact document-number lookup, keyword search, and structured retrieval of ruling details and legal grounds.
    9
    MIT