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

korean-law-mcp

by chrisryugj
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

인용 검증·법령 분석·신구조문대비표

legal_analysis
Read-onlyIdempotent

Verifies Korean legal citations against official databases, checks case validity, finds law versions at a given date, maps citing decisions, and generates before/after amendment tables.

Instructions

Korean-law-mcp — [정밀분석] 검증·분석·신구조문대비표 5종 통합. mode: verify_citations=텍스트 속 법령 조문·판례 인용('민법 제750조', '대법원 2013다61381' 등)이 실존하는지 법제처 DB 교차검증, LLM 환각 방지 — 판례는 실존불가/미확인 구분(text 필수) | cite_check=판례 생사 확인 — 사건번호로 후속 인용 역추적+변경·폐기 감지, 한국형 Citator(caseNumber 필수) | applicable_law=사건 시점에 시행되던 법령 버전+그 시점 조문+부칙 경과조치, 행위시법 판단(lawName+date 필수, jo 선택). 제명이 바뀐 법령은 옛 이름 시절 버전으로 특정. 법령이 아니면 행정규칙(고시·훈령 — 예: '스프링클러설비의 화재안전기준', 'NFTC 103')의 기준일 시행 버전 | impact_map=한 조문을 인용한 판례·헌재·해석례·행심·조례 역방향 그래프+mermaid(lawName+jo 필수, jo는 '제103조'·'103조'·JO 6자리 코드 '010300' 모두 수용) | amendment_table=일부개정안의 신구조문대비표(신·구조문대비표·신구대비표·개정안 대비표) 작성 — 개정 후 조문만 주면 현행 조문을 법제처에서 가져와 법제처 대비표 표기 그대로 대조: 바뀐 부분 밑줄(채팅 표에서는 굵은 글씨), 개정안 칸의 같은 부분 '----'(글자 수만큼, 문장 끝 마침표 유지), 같은 항·호 '①·② (생 략)'/'(현행과 같음)' 묶음, <신 설>·<삭 제>·<단서 신설>. 줄표 수·묶음·밑줄 범위를 규칙대로 계산한 결과라 표를 그대로 쓸 수 있다(lawName+amendments 필수, 조례·행정규칙은 amendments[].currentText). 로컬 실행에서는 outputPath 로 한글(.hwpx) 저장

Input Schema

NameRequiredDescriptionDefault
joNo[impact_map 필수, applicable_law 선택] 조문 번호 — 자연어 표기('제103조', '제10조의2')와 6자리 JO 코드('010300', '001002') 모두 수용
dateNo[applicable_law 필수] 기준일 — 행위·계약·처분 시점 (예: '2023-05-10', '20230510')
modeYes분석 유형 (도구 설명의 mode 표 참조)
textNo[verify_citations 필수] 검증할 법률 텍스트 (LLM 답변/계약서 등 조문 인용 포함 문자열)
titleNo[amendment_table] 대비표 제목 (예: '건축법 일부개정법률안'). 생략 시 법령명으로 만든다
displayNo[cite_check] 후속 인용 판례 최대 표시 수 (기본 20)
lawNameNo[applicable_law·impact_map·amendment_table 필수] 법령명 (예: '민법', '도로교통법'). applicable_law는 약칭·옛 법령명과 행정규칙명(고시 — 예: '스프링클러설비의 화재안전기준', 'NFTC 103')도 받는다. amendment_table은 조례·행정규칙이면 amendments[].currentText 로 현행 원문을 같이 준다
deepScanNo[cite_check] 후속 인용 상위 판례 본문 정밀 스캔 (기본 true, false면 빠르지만 변경·폐기 감지 생략)
amendmentsNo[amendment_table 필수] 신구조문대비표를 만들 개정 조문 목록
caseNumberNo[cite_check 필수] 사건번호 (예: '2013다61381', 문장 포함 가능)
outputPathNo[amendment_table] 한글(.hwpx) 저장 경로 — 로컬 실행(STDIO·CLI)에서만
maxCitationsNo[verify_citations] 검증할 최대 인용 개수 (기본 15, 많을수록 느림)
includeMermaidNo[impact_map] mermaid 그래프 코드 출력 (기본 true)
includeOrdinancesNo[impact_map] 자치법규 인용 검색 포함 (기본 true, false면 전국 조례 팬아웃 생략)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv4.15.20
    • addedInput schema / properties / amendments
      Added value: +{
+  "description": "[amendment_table 필수] 신구조문대비표를 만들 개정 조문 목록",
+  "items": {
+    "properties": {
+      "currentText": {
+        "description": "현행 조문 원문 직접 입력(조례·행정규칙·미공포안). 신설 조는 빈 문자열",
+        "type": "string"
+      },
+      "jo": {
+        "description": "조문 번호 (예: '제22조'). 생략 시 text 첫머리의 조 번호",
+        "type": "string"
+      },
+      "text": {
+        "description": "개정 후 조문 — 조 머리부터, 한 줄에 항·호·목 하나. 안 바뀌는 항·호는 '② ∼ ⑤ (현행과 같음)'·'1.·2. (현행과 같음)'으로 줄여 쓴다(적지 않은 현행 항·호는 삭제로 본다). 지우는 항은 '③ 삭제', 조 전체 삭제는 '제5조 삭제'",
+        "type": "string"
+      }
+    },
+    "required": [
+      "text"
+    ],
+    "type": "object"
+  },
+  "maxItems": 30,
+  "type": "array"
+}
    • changedInput schema / properties / lawName / description
      Previous value: -"[applicable_law·impact_map 필수] 법령명 (예: '민법', '도로교통법'). applicable_law는 약칭·옛 법령명과 행정규칙명(고시 — 예: '스프링클러설비의 화재안전기준', 'NFTC 103')도 받는다"New value: +"[applicable_law·impact_map·amendment_table 필수] 법령명 (예: '민법', '도로교통법'). applicable_law는 약칭·옛 법령명과 행정규칙명(고시 — 예: '스프링클러설비의 화재안전기준', 'NFTC 103')도 받는다. amendment_table은 조례·행정규칙이면 amendments[].currentText 로 현행 원문을 같이 준다"
    • changedInput schema / properties / mode / enum
      Previous value: -[
-  "verify_citations",
-  "cite_check",
-  "applicable_law",
-  "impact_map"
-]New value: +[
+  "verify_citations",
+  "cite_check",
+  "applicable_law",
+  "impact_map",
+  "amendment_table"
+]
    • addedInput schema / properties / outputPath
      Added value: +{
+  "description": "[amendment_table] 한글(.hwpx) 저장 경로 — 로컬 실행(STDIO·CLI)에서만",
+  "type": "string"
+}
    • addedInput schema / properties / title
      Added value: +{
+  "description": "[amendment_table] 대비표 제목 (예: '건축법 일부개정법률안'). 생략 시 법령명으로 만든다",
+  "type": "string"
+}
  2. Changed1 schema field changedv4.15.5
    • changedInput schema / properties / lawName / description
      Previous value: -"[applicable_law·impact_map 필수] 법령명 (예: '민법', '도로교통법')"New value: +"[applicable_law·impact_map 필수] 법령명 (예: '민법', '도로교통법'). applicable_law는 약칭·옛 법령명과 행정규칙명(고시 — 예: '스프링클러설비의 화재안전기준', 'NFTC 103')도 받는다"
  3. Changed1 schema field changedv4.12.0
    • changedInput schema / properties / jo / description
      Previous value: -"[impact_map 필수, applicable_law 선택] 조문 번호 (예: '제103조', '제10조의2')"New value: +"[impact_map 필수, applicable_law 선택] 조문 번호 — 자연어 표기('제103조', '제10조의2')와 6자리 JO 코드('010300', '001002') 모두 수용"
  4. Addedv4.9.1
  5. Removedv4.9.1
  6. First observedv4.4.2

TDQS

B3.2/5.0
Behavior1/5

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

Annotations declare readOnlyHint=true, but the description explicitly states that in local execution outputPath saves an .hwpx file ('로컬 실행에서는 outputPath 로 한글(.hwpx) 저장'), which is an environment-modifying write and directly contradicts the read-only hint. Other behavioral details (legal DB cross-checking, hallucination prevention, reverse citation graph) are informative, but the contradiction overrides.

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

Conciseness3/5

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

The description front-loads the tool identity and mode list, but then packs five modes and detailed amendment_table formatting rules into one dense paragraph with pipe separators. It is not wasteful given the tool's complexity, yet it is hard to scan and would benefit from clearer structure.

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?

It covers invocation for all five modes, required parameters, and key behavioral constraints (e.g., hallucination prevention, version-at-incident-time, omission of amendments counted as deletion). However, with no output schema it gives little detail on return structures for four of the five modes, leaving the agent unable to anticipate response shapes.

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 the schema already documents all 14 parameters including the mode enum, required tags, and format notes. The description organizes which parameters belong to each mode but adds little beyond the schema's own parameter descriptions, so the baseline of 3 is appropriate.

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 clearly states that this tool integrates five precise legal-analysis modes and names each specific operation (verify_citations, cite_check, applicable_law, impact_map, amendment_table) with the legal resource it handles. However, it does not mention or differentiate from sibling tools such as legal_research, search_law, or get_law_text, so an agent gets no explicit routing guidance against alternatives.

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 mode-by-mode breakdown gives clear conditions for each mode and marks required parameters (e.g., text 필수, caseNumber 필수, lawName+jo 필수), so the agent knows how to invoke each mode. But it never states when not to use this tool or which sibling to choose instead, leaving alternative selection implicit.

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