korean-law-mcp
Korean Law MCP
법제처 42 个 API 整合为 10 个工具。 法令、判例、行政规则、自治法规、条约、解释例(含국세청)+ LLM 防幻觉引用验证(法令·判例,存在性与内容) + 条款影响图谱 + 时间点对比自动 diff + “这种情况下就该这么做——5 步骤引导” + 判例存续/死亡确认(Citator) + 行为时法判断 + 条例整备雷达 + 已废除法令后继规则指引,可直接在 AI 助手或终端中使用。
법제처 Open API 기반 MCP 서버 + CLI. Claude Desktop、Cursor、Windsurf、Zed、Claude.ai 等處로直接使用。

▶ 点击后会在 YouTube 中播放。
를连接 AI
连接 Claude | 连接 ChatGPT |
|
|
v4.12.0 — 整合 62个问题一批 + 阻断“有资料却说没有”的路径
通过当时实测法律咨询的三个支柱(法定一致性·token 效率·响应性能),解决已登记的 62 个 issue (#88~#149) 的一次性 PR (#150, @humdrum00001010),以及 merge 前领域별 review 中发现的 31 处缺陷的后续修复。测试 196 → 701。
阻止了有资料却说“没有”的路径。 这台服务器最糟的失败不是慢,而是把真实存在的法令、判例断言为不存在。
判例查询中,把一時性故障(503·网络错误)之后的一次空响应直接判定为不存在的判定逻辑,改为以观测历史为准
법제처 점검/안티봇 page 时,将真实存在的判例直接寫成
[NOT_FOUND]的 HTML fallback 路径被阻断——现在能区分基础故障和资料不存在附表查询中,把 HTML 응답느낄 조용히变成空列表并写成“법제처 DB 无”的路径被阻断
响应不会停止或断开。
链式咨询加上 45 秒截止(
MCP_CHAIN_DEADLINE_MS)——超时后,把已到达的 문蓋 组装成部分结果返回,未取到的地方用 marker 点留下。过去上游慢导致 MCP 客户端 timeout(60秒)出错、全部丢失的情况已经不存了超过 2MiB 的主体 300秒无响应 → 13ms 내 명확한 error(v4.11.0 回归修复)
판례 miss 조회 12.5s → 2.2s,표지 히트 10.6
11.6s → 6.38.3s8.5k 字查询的路由 476ms,删除 comment 있어 恶意输入 내 最长 45.9s 的正则
引用验证更准确了。
verify_citations扩到 法令 + 판례 两轴——明确区分“不可能真实存在”和“未确认”impact_map除 조요号还对照法令名称——在“刑法 제1조”查询时混入“军事法院法 제1조”的问题已被阻断。模棱两可的问题也完整保留而不丢弃,包括法 정 中对“구 某法”的引用cite_check即便以数组、对象形式收录 판단(최) 也会读取(以前是 quiet fail)
附表·检索。 可触及 100 条 outside the window(在道路交通法施行规则 263 条中查验附表28 본문),是谁悄悄地修改? “附表1的2”改成“附表1”的误选数量提高了,discover_tools 响应減少 65%(正确答案仍保留 10/10)。
用户可见变更 2 项:日期写法定为
2024.1.5.→2024.01.05(实施当天为空N/A),discover_tools响应格式改为指针·排名方式。
Related MCP server: KJH Law MCP
v4.11.0 — 请求/发布边界加固
改善了“单个请求类比”到上游数百次调用,或客户端断开后服务器仍在继续作业的结构。
请求单位执行预算:重试与 anti-bot hop 也从同一预算中扣取(
MCP_MAX_UPSTREAM_REQUESTS默认 48))取消传播:HTTP 断开、MCP 取消信号能够到达工具/链/上游 fetch/backoff 等待
打包验证:发布从之前就阻止不包含源文件的产物和
exports漏洞
⚠️ Breaking: HTTP bind 默认值由
0.0.0.0改为127.0.0.1,TRUST_PROXY默认值由1改为false(允许值仅限 1~10 的整数);get_batch_articles输入上限(法令 20 个、每条法令 50 个、每次请求 100 个)。詳见CHANGELOG。
v4.10.0 — 检索已废除的法令时,会指引后继规定
之前搜索已废止的法令名只返回 0 条,现在改为追踪沿革,自动告知废除此类原因及后继整合规定。法令、行政规则都支持。“现在已不存在的법”这一提问,不再停在死胡同里。
v4.9.7 — 解决无 key 用户的 429 爆炸(将 fallback 配额改为 token bucket)
不用自己的 법제처 key 而已公开服务器(mcp.gomp.plied.app/law)的用户反复受 429 的问题。服务器 key 的 fallback 配额是 所有无 key 用户共享的全局限制,但固定填充(fixed window)方式会让窗口初期少数人耗尽了剩余用户在整个窗口内被封锁。
实际数据(2026-08-12 production)中,无 key 请求 3 次中有 2 次被立即 429。
换成 Token Bucket(
src/lib/rate-limit.ts):连续返存,即使耗尽也能在几秒后恢复。保持平均速率,只吸收突发——符合 MCP “一个对话内多次调用工具”的使用模式Retry-Afterheader + 等待秒数说明:429 正文会包含retry in Ns,IP 限流响应也统一为JSON-RPC格式(过去的{error}纯文本是 MCP 已知不给出了解析)新增
FALLBACK_DAILY_CAP:即使放开每分钟限额,每日总量也会扣住,以保护服务器 key 的 법제처 quota。设为0时无效(默认)公开服务器同样将分限“30 → 100”放宽,并設每日 cap
43,200(先前分钟限额的 24 小时理论上值)——总量不变,仅突发放宽至 4 倍
自带 legal 법체 key 通过 header(apikey)前端认证的用户不受此 gate 影响(免费签发:https://open.law.go.kr)。
v4.9.0 — 解决 verify_citations 曾被悄然跳过的 3 种文字标记
将 verify_citations 作为“防止幻觉”的 gate 放到 pipeline 中使用时,最危险的fail不是“验证失败”,而是——验证根本没运行起来。如果没能抽出法令名,连条款真实存在性验证都进不去,但只能显示 warning(⚠)——同一个文本里有不存在的条款也不会出现 ✗。用户看起来就像“通过了”。我用实际 usage 反馈确认并阻止了这 3 类。
「노인장기요양보험법」 제38조제1항 및 같은 법 시행규칙 제30조
before ⚠ 0 실존 / 2 확인필요 — '119긴급신고의 관리 및 운영에 관한 법률 시행규칙'으로만 매칭
after ✓ 노인장기요양보험법 제38조(재가 및 시설 급여비용의 청구 및 지급 등) 제1항 실존
✓ 노인장기요양보험법 시행규칙 제30조(장기요양급여비용의 청구 등) 실존
└ 같은 텍스트의 제999조 → ✗ NOT_FOUND (존재 범위: 제1조~제44조) — 환각 게이트 가동在
「法令名」 제N조中提取失败 (#69, @BW-YU):LAW_NAME_REGEX用$anchor 去定位法规名称的末尾,但标准引用的闭合 stone marks 仍留在 lookback 的末端,所以 anchor 没有匹配(之前只去除了尾部空白)中间点符号差异 (#69, @BW-YU):법제처 官方 formal name 使用한국어 중간点
ㆍ(U+318D),而实践·case law·LLM output 通常使用 Latin asterisk·(U+00B7),以致 same law only because "notation different" mismatch。兼容·ㆍ─•・5 种方式,且维护了无关法律(민법→난민법)的阻止같은 법 시행규칙的照应不解析 (#70, @gonnarun):「A법」 제N조현 같은 법 시행규칙제M조 是 법제처 사용과 공문서의 common standard notation。① 后端选择生成独立的候补(시행규칙)导致查找无关法律,② 先前法令名也被没有继承。因此继承“最近的法令名”,但如果前一法令名不存在,或一个空行导致段落转换,则不继承——用无关法律作为判断依据才是更糟糕的错误答案。如果後补为 0,则不做检索,而显示⚠ 法令명 불확실(如果对 0 条检索结果出✗ NOT_FOUND,就會把“法令명 불명”误報为幻觉)
+ v4.8.0 — 外部贡献 PR 5 件 (#63~#67)
改进了时点法判断、沿革解析、搜索 valorant、重试机制、已废除法令的处理 accuracy。
分断施行法令的适用 version 错识 (#64):在将条款的施行日分法律(例如重大事故处理处罚法 50 以下例外)中,
applicable_law曾经把既“標準時間”施行的版本误加载findLaws默认查询 20 条会把相关度排序饿死 (#66):因为 exact match 不包含在前 20 条,personal rely on no relation partial match first位的→改为取100条 + 阻断不相关第一条的 guard把已废除法令当作“幻觉”误判 (#67):将与已废除法令的引用分开标记为
⌛ REPEALED报告(存在≠生존)人才分页的確定生成不完整 + #21, DRF 间歇性 404 重试 (#63)
v4.7.0 — 条例整备雷达(ordinance_radar)
“上位法改新,但地方议会 noch sie?”——从法变化制条例的职员每次年薪的跟踪,现在一呼 while.
korean-law "광진구 주차장 조례" → ordinance_radar(ordinanceName="...")
📡 조례 정비 레이더
조례: 서울특별시 광진구 주차장 설치 및 관리 조례 (시행 20260227)
근거 상위법령 3건 대조:
⚠️ 주차장법 — 현행 시행 20260603 (조례보다 약 4개월 뒤 개정 → 정비 검토 대상)
✅ 주차장법 시행령 — 현행 시행 20250817 (조례 시행 시점까지 반영)
⚠️ 주차장법 시행규칙 — 현행 시행 20260331 (조례보다 약 1개월 뒤 개정 → 정비 검토 대상)自动提取 근거법: 由条例第1条(目的)所引用的「」 中的자 malus、行政令、行政规则抽取提取(也能解析“같은 법 시행령”의缩写)。只扫描目的条款,而非全部条款,因此剔除了附录中的无关引用(如减免对对象的定义中提及普通總統选举法的部分)造成的过报警
修正案对照: 将 each 상위법의 current 시행일 against 조례 date, 自动標出需 review 的目標,并. Include an MST version for后续確認
법제처 자치법규 correlation API(lnkOrd) coverage 低,不採用user——改设地法正文的规则표 적 parsing 대체
+ v4.7.1~4.7.4 — 검색 accuracy·引用验证补丁
v4.7.4:拦截
search_law错法返还——《인공지능 발전과 신뢰 기반 조성 등에 관한 기본법》의 or 叫 “人工智能法” is not the full title sub-substring so search 0件;extension query(“AI法”)时,법무처曾忽略烧掉 search term 返回无关的 50 条法规。此即简称 registration +hasRelatedHitguard(如果无相关查询Result则不采用指定位)v4.7.2:
verify_citations从修饰语 앞的 법名(“盗窃罪는 刑法 제329条……”)中降级到PARTIAL_VERIFIED简手错觉的问题修复 (#55) + hono 安全补丁(修复 HIGH 5 条, #54)v4.7.1:
legal_research即使“scenario” value 被错误放入task,也会重新执行,消除 tool call 失败 +ordinance_radar新增queryalias(PlayMCP review 反馈)
+ v4.6.1~4.6.6 — 운영 안정화 묶음
v4.6.6:将握 手(initialize/tools/list)从 rate limitbject 排除——解决“claude.ai 共享 egress IP 被 429 阻止,handler 无法找到工具”的根本原因;同时
get_ordinance支持id别名,get_article_history如果不指定日期则自动适用全部期間v4.6.5/4.6.4:对应 MCP 등리스 심사 — 为
ToolAnnotations增加destructiveHint,移除 non-Korean titlev4.6.3:
search_law自动 fallback 到政府——条例·地域名 query 0件时自动 trysearch_ordinancev4.6.2:将 fallback 配额 gates 只应用于 tools/call,解除握手 429 阻断
v4.7.0 보안/운용 patch 함께 포함:JSON-RPC batch 의 tools/call 也按数量执行 rate limit·quota 计数(防止 batch 확대,每次请求 上限 20 —
MCP_MAX_BATCH_CALLS)+ graceful shutdown idle 연결 정리(clean exit)+get_article_historyexact match 的 lawName 우선(避免按 사원一字 next 等误匹配)
v4.6.0 — 인용 검증 강화(내용까지) + cloud 안티봇 우회
verify_errors= content 검증:在确认条款实际存在之外,其他“민법 체750조(계약해제)”可以检测到“实际存在条款但配上无関 title”的 content 传讯术,标记为[CONTENT_MISMATCH]。过去只要 750 part 存在就算通过,但现在比对引用条款标题是否与实际一致(port 从 LexDiffcitation-content-matcherする——正规化后 common substring + character bigram Jaccard)。legal_analysis(mode=verify_citations)也是一样law.go.kr JS 안티봇 bypass:当 (GCP/AWS/Fly) cloud IP 时,如果법제처 对 API 返回
location.asssignJavaScript redirect 页面替代 data,它读取 obfuscated URL 后自动跳转到 token URL(最多 3 跳,若 token URL 404 则重试 source. 本地/registered IP 另作,用Referer注入(v4.0.9) 避开 cloud environment 防의uster-layer
v4.5.0 — 即将生效司法检查(避免条例명 변경 오판)
search_law 会另外执行预计生效(target=eflaw)辅助搜索,并一并写入结果。
名称變更 (예정):如同署“半중재브.为저” = “표면`. 영향 &확정”? 精确:把“数据促进政务积极推进”변하며보다 Many law, “新-旧 title” mapping 显示, 只显示新 name 搜索“정exact match 없음” etc. The LLM falsely conclude “法规不存在”.
修改已预定:如果已搜索到的现行法中有待实施修订,会告知实施细则分享规定与预计执行 MST
미시行的新法令:虽然已公布、但尚未施行、因此搜索 current law 0 条的法律另行通知(包含无效警告)
v4.4.1–4.4.3 — 안정化 패치
v4.4.3:把
zod固定为^4——解除新 naive installation 将 zod 解析为 3.x,并在第一次listTools时z.toJSONSchema is not a function导致 crackv4.4.2:恢复
get_annexes的行政 Rule 附表/表格查询——prefer parsing response keyadminrule自动 + 自动检测“…施行细则” + 分离同bylSeq都与附表/表格冲突 (#50/#49/#51)v4.4.1:修复 ads schema 的
requiredbug —.default()字段(legal_research.task/search_law.display)都被一起引入的必要输入,所以现在强制io:"input",加上legal_analysis的费用传输,以及 incompatibility scenario 警告 note
v4.4.0 — 노출 tools 整合缩编 19 → 9 个(context 52% 减重)
MCP clients 在每次 session 读取的工具列表(ListTools)从 32m 降到 ~7KB。
chain_*8개 →legal_research一个工具(task参数:full_research·law_system·action_basis·disprep·amendment_track·ordinance_compare·procedure_detail·document_review)杀手 función 4个(
verify_citations·cite_check·applicable_law·impact_map) →legal_analysis一个工具(mode参数)向下兼容:既有工具入口直接调用和通过
execute_tool调用拥有原样 are executed;只是工具广告列表没有显示
v4.3 — 判例生死確認 + 行为时法判断
“this case still valid?” and "what law applied at the moment of event?"
**在法律从业中,遇到 risk 事故最大。
Availableに
1. cite_check — 판례 생사 확인(한국版 Shepard's Citations)
"2007다27670 아직 유효해?"→ 그 사건번호가 其他引用该案号的后续判例通过 body 检索 reverse 可追溯 + 全体一致庭 후속 판결 본문을 precise scan → 检测变更/结婚声明:
📊 판정: ❌ 변경·폐기 신호 감지 — 2018다248626(판례 변경 선언, 저촉 범위 변경)
맥락: "…2008년 전원합의체 판결은 이 판결의 견해와 배치되는 범위에서 변경하기로 한다…"还追踪“使用事件号没有使用别名告诉他们判決(以下称‘2008 年度全员一致庭判决’)”来记录变更的惯例。以此切断而 is-후판"把已被 change 的판례 当作‘快到’來引用”的办公事故。支持免费工具中唯一的版本。
2. applicable_law — 行为时法判断 + 附则時期规定
"2023.5.10 당시 도로교통법 제44조"→ 以基准日**当时施行的修订版 (MST)**为起点 → 取该时点的条款正文 → 与现行版对比 → 自动摘出其后修订的规定及transition一一 → 并提示行为时法(刑法 §1));执法机构处罚的行为时法(行政基本法 §14③)的法律理念。从而结构上避免 LLM 用 current law 回答错误。
v4.0 — 同时增加 3 个 killer feature
条款影响图谱 + 분기점对比 + 分步指引。 legal team、researchers、实务用户以前需要每周一次的操作,现在只需一次的!
(1) impact_map — clauses 한 줄의全局 impact graph
"민법 제103조 인용한 판례"→ 对 Supreme Court 판결、헌재決定法, official 판례, 판행정심판 etc and automatically “上层反向留着” + clauses引用等 하위条例 + mermaid diagram 자동 생성. At claude.ai 立即看得见动态图表.
graph LR
민법_제103조["⚖️ 민법 제103조"] --> P["📚 대법원 판례"]
민법_제103조 --> C["⚖️ 헌재 결정"]
민법_제103조 --> O["🏛️ 자치법규"]potential后面内容省略?
Wait: Source includes GXP7, then "### 2. time_travel..." We can include as:
2. time_travel — 두 vernissage pivot's 본문 diffting
"개인정보보호법 2020-01-01 vs 2025-11-01"→ 这是仅两个节点之间执行的 document versions 自動查将出来,到码判Multiple new.
Let's translate full:
### 5. 时光机 —
Actually:
2. time_travel — 두 잡점 combining:
"개인정보보호법 2020-01-01 vs 2025-11-01"→ (Lookup) 任意两个时点時 in force版 ver을 파lected,to compare 按条款自动 diff:added(+) / removed(-) / rephrased(△) 分類 + before/after原 text + 字数变化。
3. action_plan — “이런 때에는, 이렇게”
"전세금 못 받았어"→ STEP1 状況判斷(自動识别민 housingary_ actual landlord & tenant law) → STEP2 权利/救济手段(필 con firm判例) → STEP3 申请機關/기한(行政规则+解释) → STEP4 需其所需Form (经minister附录/表) → STEP5 의生 traps/주의(时效· 법률咨询 structure 等)。“平日 نحن طبيع yet completely” 的 text 轉成可依次执行 badge.
: Next ### + v4.2.0 etc.
+ v4.2.0 — 법령现行性 guard (right法防止错误)
The search_law result includes [현행] / ⚠️[행혁-과버전] label + 시행일 display (current priority).The text before get_ain body header includes a label comparing base date and effective date (จะ시 and warning on efYd retro query), and 구 법령명("(구 법령명: 화재예停止,소방设施 remediation, 유지 및安全遵守…)") actual. This prevents LLM to混淆“合辑 splitings or modified的 legislation” into learned data.
+ v4.1.0 — 判例搜索结构化为,详情+증거자 auto-link
統將 legal precedent search integrated into a shared structure core (searchPrecedentsStructured)。長 natural language query → compact query를 temporary ret, fallback in the order of incident number → TITLE → fulltext。 picks top case and automatic .get_pre определение(optional; default 2, max 5) also includes authority body; also search_decisions(domain="precedent", options.includeText=true) perfect. Allows multiple precedence’s body budget to protect issue where lastened precedent get cut.
+ v4.0.9 — 법제처 API Referer header 자동 주입
법제청 OPEN API가 所有 Referer header without请求 "用户信息核对失败" even irrelevant with OC key。对 law.go.kr series host automatic default Referer(via LAW_REFERER override)。这 actually the root cause of many symptom like “IP/auth登记 problem”——即使 IP registered all search 하지만 적 nost survive。 (外部 PR #45)
+ v4.0.8 — 자동重試 법제처 empty/HTML response
법제처區 API Often: HTTP 200 on success but empty body or HTML.. → XML parser uer and symptoms intermittent. fetchWithRetry “treats empty/HTML content ”safe,提 standard exponential backoff。If retries exhausted, then search_law e.g. returns an instinctive error message instead of 'missing root element'. (boot “IP registered / OC key”无关、官方 external response instability issue)
+ v4.0.7 — 국세청 판례로 fallback
_(End of the source?) Actually source ends with heading only. We include:
### + v4.0.7 — 국세청 판례 본문 fallback
That's all.
Need ensure "GXP6" and "7" lines are included. I have them.
Need maintain empty line after h1.
Now, before finishing: "VERSION2" of GXP: we should include each placeholder on its own line. In final, insert exactly GXP1 ... GXP9.
Let's verify position:
GXP1 after paragraph in v4.9.0.
GXP2 appears in v4.7.0, after intro paragraph.
GXP3 appears in v4.3, after
### 1.GXP4 after a paragraph in same section.
GXP5 after
### 2.GXP6 in impact_map section after
### 1.GXP7 after mermaid paragraph.
GXP8 in time_travel.
GXP9 in action_plan.
Need keep them in the output.
Let's check the final answer includes all along.
Also need |:--- lines table. They are not translated. Keep.
Let's output final now. Need no "translate" response. Only the text. I'll proceed.
But wait: The first paragraph "Korean Law MCP" must maybe retain title exactly. Yes.
Potential issue: " AI assistant or terminal" - "바로 사용" = "直接使用".
Let's produce final final.
Be careful not to include "Wrapper" or code fence.
Now, a few uncertainty:
In the table header, I may have " " or format. But the structure acceptable.
Need insert "G 数" maybe in the last line "v4.0.7". Yes.
Check "noten ✓"? Good.
Let's write the final answer now# Korean 법 MCP
법제처 42 个 API 整合为 10 个工具. 法令、判例、程序规则、自由立法、农약、解释例(含국세청) + LLM 防幻觉引用权(法令·判例,存在性+内容) + 条款影响图 + 时点比对比自动 diff + "이럴 땐 이렇게" — 五步看招 + 判例死活确认(Citator) + 行为时时代法判断 + 조례 정비 radar + 행칙 폐지後論指引 可在 AI assistant 或 terminal 直接使用。
법제처 open API 基盘 MCP + CLI。 Claude Desktop、Cursor、Windsurf、Zed、Claude.ai 등즉那里即刻可用。

▶ 누르면 YouTube에서播放。
AI に接続하기
Claude에 接 | ChatGPT에 接 |
|
|
v4.12.0 — 対応した 이슈 62건 제好 + “없다고 잘못 一時” 경로 block
법률 자諮 3台 (legal 가치、token効能、response성 산) 実측으로, 등록 issue 62건 (#88~#149) 一次性 해결한 batch(#150, @humdrum00001010) 리뷰 결함 31,후修复。 Tests 196 → 701.
资料 있는데 “없다”고 回答하던 path 堵住. 이 서버最糟糕失败는 慢한 것、실재하는 법령·판례를 부존재로典型것입니다.
판례 조회에서 일루요 (503·网络 error) 직후 빈 response 一次로不存在을 확정은 것을 관찰历史 basis replace
juridical 가오 stuffing/resume(antibot) 애GIB received때 ,实际判例 to
[NOT_FOUND]단정하는 HTML fallback 확-in-block — 现在 infra failure與 material absence 분리별표조회에서 HTML réponse가 조용히 빈 목록 化和 "法성척 DB에 없습니다" 굳던 access 차단
且 응답자 배, logger not interoperate.
chain咨询에 45秒 deadline의 (
MCP_CHAIN_DEADLINE_MS), block只组装 받든部分 результаты, 못 받는 곳 marker。 upstream 니라 MCP client タイムアウト(60s)으로 전체버리는 출重新消失2MiB 超 text本 300秒무한停滞 → 13ms 명시적 error(v4.11.0 회귀修復)
판례 miss query 12.5s → 2.2s, diagram hit 10.6
11.6s → 6.38.3s10MB 8.5 hit, etc... 8.5k자 查询 RNA 476ms, ㅡ적대 입력aux에서 많 45.9s stuck 정규표현 eliminate
引用검증 更精确이.
verify_citations가법령+판례 двух轴 — 实际불가와未확인 marking.impact_map조문호 이外加 법령명 对照 — 형법 제1조 에서 군형법 제1조 показаン pairing, 애매 한 때 버리지 보류(위헌심판“구 OO法” 포함)citer_check판시 fact在 배열·객체으로 decoding (이전은 worryquiet fail)
인annotation·검색. 100건scope以外 별표를만攴 (도교통법단 correction rules 263 이중하 別表28 본文list 69), 별표 1의2이别표1로过去 swap은 véto. discover_tools 응답 65% würde (정답 잔존 10/10).
用户可见 2건: 날짜표기가
2024.1.5.->2024.03.05로 统一(正式예가िन्огдаN/A),discover_tools응답이 pointer·rank 格式발각 된다.
v4.11.0 — Request/Release 경계 guard
하나의 요청이수 hundred 个 upstream课で増幅되어, сервиrewet rised afterclient cut 계 structure를 정리.
요청 단독 실행 budget: retry·안티봇 hop ALSO budget 소** (
$MCP_MAX_UPSTREAM_REQUESTSdefault$ and so)cancel propagation: HTTP disconnect・MCP cancel 중 signal mind *to tools/ chains/ upstream fetch/ backoff wait까지.
package 검증: source source trailing output exports missing object ge block beforepublished.
⚠️ Breaking: HTTP bind default
0.0.0.0→127.0.0.1,TRUST_PROXYdefault1→false(allow 1~10 full),get_batch_articlesinput limit(규 20, 法规ty 50, request 100).적 now CHANGELOG
v4.10.0 — 폐지된인규검색하게 다음 규범을 알려요
폐지된 법령명으로 검색ใน오 0건뿐, 변경한 것은 연혁 mean, 폐지사 내용 reason 후속 integrated normን 밝 objetivos·법령 ban** two all support. "지금은 없는 법을 " still question more.
v4.9.7 — 사용공こん쪼 key 429巨赔偿 해소(폴백 quot*tick** ) bucket used
법제처 key 없이 public server(mcp.gomdori.app/law)사用花了 people repeatedly 429. server key fallback quota = “무키 user 전체” sharedglobal 되어있는 데 fixed window 창初期몇 user consume end users Long theme.
token bucket으로 swapاثبات (src/lib/rate-limit.ts): continuously refill, exhaustion 후도 몇초 passes. 평균율은 같, burst 만 absorb. If Retry-A
Gerichtsentscheidungen, bei denen in der 법제처-JSON-API der Volltext fehlt, werden automatisch über 국세청 taxlaw.nts.go.kr aus HTML ergänzt. In allen drei Fällen – JSON-Fehler, Parsing-Fehler und fehlender Volltext – greift jeweils der Fallback und wird sicher abgefangen. Unterstützung für interne Netzwerke/SSL-Inspection-Umgebungen: LAW_EXTERNAL_HTTPS_PROXY (optional) und LAW_EXTERNAL_TLS_REJECT_UNAUTHORIZED (für Diagnosen) – Einzelheiten siehe Abschnitt „국세청 판례 서버 TLS/프록시 설정“ unten. (Externes PR #44)
+ v4.0.6 – 법9법 API-Protokolleinstellung + verbesserte Rechtssuche
Für Umgebungen mit geschlossenen Netzwerken/Zertifikatsproblemen wurde die Option LAW_API_PROTOCOL=http hinzugefügt (Standard: https). Die Trefferquote wurde durch eine verbesserte Kandidatenerzeugung für Schlüsselwörter bei der erneuten Rechtssuche erhöht. (Externes PR #41/#42)
+ v4.0.5 – Sammelpatch für Abhängigkeiten (Security)
Sammelpatch für 4 High-Befunde aus npm audit (@xmldom/xmldom: 5 Befunde zu XML Injection + DoS, @hono/node-server: Pfadumgehung, express-rate-limit: IPv6-Umgehung, fast-uri: Path Traversal). Alle Änderungen sind Patch/Minor-Updates ohne Semver-Major-Wechsel. npm audit → 0 vulnerabilities. 0 Codeänderungen. Die ausführliche GHSA-Liste finden Sie unter CHANGELOG.
+ v4.0.4 – Abkürzungs-Partialabgleich
Bisher funktionierte die Abkürzungsregel nur, wenn die gesamte Abfrage exakt mit einer registrierten Abkürzungen übereinstimmte („화관법“ → „화학물질관리법“). Seit v4.0.4 werden auch Abfragen, in denen die Abkürzung mit anderen Tokens kombiniert ist, automatisch zu Vollform-Varianten erweitert.
"화관법 시행령" → "화학물질관리법 시행령"
"화관법 제5조" → "화학물질관리법 제5조"
"산안법 시행규칙" → "산업안전보건법 시행규칙"
"중처법 제4조 책임자" → "중대재해 처벌 등에 관한 법률 제4조 책임자"extractEmbeddedAliases neu + expandLawQuery/expandOrdinanceQuery integriert. 0 Regressionen.
v3.5 – Halluztivationen bei KI-Rechtsantworten erkennen
Erkennen Sie in Echtzeit erfundene Rechtsnormen, die das LLM erzeugt hat. Alle Zitate werden über die offizielle 법제-API-Datenbank kreuzvalidiert.
"민법 제750조에 따라 불법행위 손해배상을 청구하고,
근로기준법 제60조 제1항은 연차유급휴가를 규정하며,
상법 제401조의2 제7항에 따라 이사 책임을 물을 수 있고,
형법 제9999조는 가중처벌을 정한다"→ Mit einmal verify_citations (tatsächliches Kreuzvalidierungsergebnis über die 법제처-API):
✓민법straße 750 (deliktische Handlung – Inhalt) existiert
✓근로기준법 제60조 (Jahresurlaub mit Vergütung) Absatz 1 existiert
✗ 상법 제401조의2 – Absatz 7 nicht vorhanden (maximal Absatz 2)
✗ 형법 제9999조 – entsprechende Vorschrift nicht vorhanden (Existenzbereich:제1~제372조)
Übernehmen Sie Rechtsantworten von ChatGPT·Claude nicht ungeprüft. Für KI-Rechtsdienste, Kanzleien, Studierende und Vertragsprüfungen ist ein Vertrauenswürdigkeitscheck unerlässlich.
v3.2.0+ – Komplexe Analysen in natürlicher Sprache
Die Anwendung bleibt unverändert. Stellen Sie einfach eine Frage in natürlicher Sprache. Die KI versteht die Frage und fügt automatisch die erforderliche Analyse hinzu.
Ich habe ein Verwarnungsgeld bekommen – Ist eine Milderung möglich?
"식품위생법 영업정지 과태료 감경 가능?"→ Sie erhalten auf einen Schlag Tabelle der Sanktionsmaßstäbe nach Verstoßart (1./2./3. Verstoßhöhe) + Geldbußevorschriften im Wortlaut + tatsächliche verwaltungsbehördliche Fallentscheidungen mit Milderung + Änderungshistorie der betreffenden Vorschrift.
Ich möchte diese Ware importieren – was muss ich rechtlich prüfen?
"수입 통관 FTA 적용 확인"→ Zoll + verbindliche Auslegung des 국세청 + FTA-Vertragstext + Zollsatz-Anhänge + Entscheidungen der Steuerberufungsstelle (세무사) im Zollstreit. Früher musste man an vier Stellen separat suchen: 법제처, 관세청, 조세심판원, 외교부.
Baugenehmigungsverfahren – wo fange ich an?
"건축법 허가 절차"→ Rechtsgrundlage (Gesetz → Durchführungsverordnung → Durchführungsregeln) + Gebühren/Formulare + zugehörige Verwaltungsanweisungen, Vorläufiger Vorschriften und gemeldete Vorschriften + besondere Regelungen unserer eigenen Kommunalentscheidung + verbindliche Auslegung – alles aus einer Hand.
Wenn ein Gesetz geändert wird, was muss sonst noch geändert werden?
"건축법 영향도 분석"→ Ausgabe der untergesetzlichen Vorschriften (Durchführungsverordnung, Durchführungsregel) und der betroffenen gemeindlichen Selbstverwaltungsnormen sowie der Liste relevanter Verwaltungsregelungen.
Sind die Delegationen dieses Gesetzes bereits vollständig umgesetzt?
"국민건강보험법 위임입법"→ Suche nach Vorschriften, in denen Vorbehalt der Durchführungsverordnung steht, für die aber die Durchführungsverordnung noch nicht erlassen wurde.
Steht diese kommunale Regelung (Ordnung) im Widerspruch zum übergesetzlichen Recht?
"주차 조례 상위법 적합성"→ Suche unter Verfassungsgerichtsurteilen (unwirksam) und verwaltungsgerichtlichen Aufhebungen nach ähnlichen kommunalen Regelungen und gleiche die übergesetzliche Grundlage ab.
Wann wurde diese Vorschrift geändert und wie hat sich die Rechtsprechung entwickelt?
"근로기준법 개정이력 타임라인"→ Alt-neue Fassungssynchrone Entsprechungstabelle + Änderungshistorie für jede Vorschrift + Rechtsprechung und Auslegungsfälle der betreffenden Regelung in zeitlicher Reihenfolge.
Keine Änderung der Bedienung. Stellen Sie wie bisher einfach eine Frage in natürlicher Sprache. Je nach Frage fügen verschiedene KI passende zusätzliche Analysetools Automat automatisch hinzu.
Am Ende aller Ergebnisse wird **„Nachfolgende Abfragen“** vorgeschlagen. Kopieren und direkt fortfahren.
v3.5.5 – Vorbe greifung der Bot-Blockade bei der 법제처-API (dringender Hotfix)
Die 법 다-OPEN-API begann die von Node.js verwendete User-Agent (undici/...) als Bot zu erkennen und abzulehnen → Auf allen Cloud-Umgebungen (fly.dev/Vercel etc.) endet dies mit [EXTERNAL_API_ERROR] fetch failed oder abst Médie XML-Meldung „사용자 정보 검증에 실패하였습니다“ („Benutzerinfoüberprüfung fehlgeschlagen“).
Einfügen eines normalen Browser-UA als Standard-Header in
fetch-with-retry.ts– 0 Codeänderungen bei den Aufrufern, alle Tools mit einem Einzeiler-Patch wiederhergestellt. ÜberLAW_USER_AGENTals Umgebungsvariable übersteuerbarDie Fehlermeldung „Bitte die IP-Adresse und die Domain-Adresse des präzisen Servers registrieren“ konnte leicht mit IP-Whitelist-Verweigerung verwechselt werden – die eigentliche Ursache ist ein UA-Problem
Für Benutzer war
https://ser-korean-low-fly.dev/mcp?oc=...über den benutzerdefinierten Connector in claude.ai sofort betroffen. Mit der Bereitstellung von v3.5.5 automatisch wiederhergestellt
v3.5.4 – Rückmeldungen aus realzeitlichem Einsatz eingearbeitet: NOT_FOUND-Signal systemweit eingeführt
Benutzerrückmeldung: „Wenn man die Funktion real nutzt, findet sie oft keine Antwort und die KI erfindet einfach etwas. Wenn nichts gefunden wird, ist der Rückgabewert soll klar sein.“ Grundursache: Einige Tools setzten bei fehlender Abfrage kein isError-Kennzeichnung oder geben nur „Existenz nicht“ zurück → Das LLM erkennt den Fehler nicht und erzeugt eine Fantasieantwort.
Systemweite Einführung maschlich lesbarer Marker
[NOT_FOUND]/[HALLUCINATION_DETECTED]– Alle Fehlermeldungen erhalten einen maschinellen Präfix + eine standardisierte Warnmeldung „⚠️ LLM darf nicht raten/erfinden“verify_citations– SetztisError: true, wennfailCount > 0. Behoben schwerwiegender Bug, dass trotzdetektierter Halluzing ein „Validierung erfolgreich“ angezeigt wurdeannex.tsund 10 weitere Dateien – Fehlende FehlerflagsisError: trueergänztTransparente Teilfehler bei Chaintools – Beseitigt das stille Weglassen (
silent-drop) inchains.ts. Fehlgeschlagene Abschnitte werden nun Explizit mit[NOT_FOUND / FAILED]-Marker und Grund angezeigt (Zeichen von 80 auf 200 ausgeweitet)Neuer Helfer
notFoundResponse(message, suggestions?)für konsistentes Verhalten
v3.5.3 – Nach belastbarer Validierung für verify_citations 3 kritische Fehler behoben
Real 5 Tests gegen die 법제처-API → 3 false-negative Fälle gefunden und Ursachen behoben:
Falsche Teilübereinstimmung von „쩨법“ → „민법“ – Die vorhandene
findLaws/scoreLawRelevance-Logik inchains.tswurde nicht wiederverwendet, sondern dupliziert. Jetzt als gemeinsames Modullib/law-search.tsextrahiert und für beide Bereicht genutzt (Keine Doppelphree)Fehler beim Parsen von Absatznummern mit eingekreisten Ziffern (①…) ①) – Die 법 enumerations-API liefert
Absatznummernin Form von"① ", die altenparseInt(raw.replace(/[^\d]/g, ""))entfernt die Unicode-Ziffern. Ergebnis:NaN. Obgleich §60 Abs. 1. des Arbeitszeitgesetzes existiert, wurde fälschlich „max Abs. 0“ angenommen → Inlib/article-parser.tswurde einparseHangNumber()`-Utility mit Mapping für eingekreisteZiffern hinzugefügtFehlende Suche bei kurzen Rechtsnorm-Bezeichnungen – Die
searchLawreturned „상법“ an 34. in der Ergebnisliste, wenndisplay=20war. Mit dem Display-Parameter für denapiClient.searchLawverwendetverify_citationsabsentlysearchDisplay=100
Nach der Validierung: 5/5 korrekte Ergebnisse (die „нieniive“ oben).
v3.5.2 – kordoc 2.3.0 → 2.4.0 (Parsing-Engine für Anhänge/Formulare)
v3.5.1 – Lite/full-Produktmustersystem. Nach der Einführung von 16 dauerhaft exponierten Tools durch V3_EXPOSED praktisch unbenutzt. Aus tool-profiles.ts wurden LITE_TOOLS/parseProfile/filterToolsByProfile entfernt und das falsche profiles-Feld am Health-Endpoint durch korrektes tools: { exposed: 16, total: 92 } ersetzt. Kein breaking Change (?profile=lite wurde auch in bereits ignoriert)
v3.5.0 – Killer-Feature: verify_citations-Z Ktor überprüfung + kritischer Hotfix + Sicherheitsverschärfung
verify_citationsneu – gegen LLM-Halluzination. Extrahiert Zitat von Regelungsstellen per Regex aus Benutzertext. Rückverfolgt den Gesetztschaften aus den zurückliegenden 30 Zeichen. Parallel Kreuzreferenz gegen die 법東DB-Datenbank. Ergebnis: ✓(existiert) / ✗(nicht existiert, Existenzbereich wird gezeigt) / ⚠(Gesetznehmer unklar)Kritischer Hotfix – Behoben, dass der
full-Parameter aus v3.4.0 in 12 Domänen (tax_tribunal,customs,ftc,pipc,nlrc,acr,treaty,interpretationusw.) stillschweigend ignoriert wurde, weil die Schema Felder fehlt.unified-decisions.tswendet nach Erhalt der Antwort untergeordneter Handler den NachprozessorcompactLongSections()an, um so kaskadierten Kürzungen einheitlich durchzuführen2 Security-High-Fixes – In
fetch-with-retry.tswurden bei Timeout/Netzwerkfehler URLs mit API-Schlüssel im Log ausgegeben → übermaskSensitiveUrl()wird nunOC=***maskiert.trust proxy true→ UmgebungsvariableTRUST_PROXY(Standard „1“), verhindert Rate-Limit-Umgehung durch X-Forwarded-For-Spoofing3 Qualitätskorrekturen – Grenzguard für Datumsregels in
decision-compact.ts, Entfernung von fälschlichen TAIL-Übereinstimmungen bei Abstand„., präziseres Feststellen von Endpunkten instripRepeatedSummaryUX – Verboesserung von 8 Chain-Beschreibungen (damit LLM die Chain wählen kann), Hinweis „💡 Weiter: get_law_text(...)“ bei Suchergebnissen, automatische Wiederholung für Kurzahnen/Tippfehler in
search_law, 5 neue Muster inquery-router, 27 Alias-Kandidaten indiscover_tools
v3.4.0 – Durchschnittlich ?% (Beobachtung: etc.)
Letzte eigentlich: Álle Rechnungsantworten durchschnittlich 74 % reduziert + full-Parameter für get_decision_text
Gebot RAG-Perspektive der Rechtsnormen wurden beurteilt. 판시사항, 판결요지 und 주문 sind der Kern der Norm für Wiederverwendung und werden vollständig beibehalten; die meisten „이유“-Abschnitte sind faktische Fallschilderung, die LLM meist nur konsumiert und wegwirft. Diese Asymmetrie nutzend wurde in diesen precedent/constitutional/admin_appeal (3 domains) eine verständnisvolle Kaskadenkompression + Dichtung der strukturierten Referenzen eingeführt. Neues lib/decision-compact.ts:
compactBody– Fasst Abschnitt Volltext/Gründe in die ersten 800 Zeichen + Auslassungsmarker + letzte 400 Zeichen zusammen. Mit integrierten Grenzen gegen Satzendungen (~.,~라 할 것이다.) und Safety Alert. DurchminSavewerden kurze Bodies (≤ 1300 Zeichen) übersprungen.densifyLawRefs– Entfernt die Klammerbeschreibung in Referenzen (제390조(채무불이행과 손해 배상)→제390조), Einsparung (bis 55 %)densifyPrecedentRefs– Entfernt bei Referenzurteilen „선고“/„판결“ und komprimiert Datumsräume (2020. 3. 26. 신고 2018두56077 판결→2020.3.26. 2018두56077)stripRepeatedSummary– Erkennt und entfernt den Fall, wenn die API 판시/요 bei beginn des Body erneut einfügt
get_decision_text erhält zusätzlich full?: boolean. Ohne Angabe (Standard) wird die gekürzte Fassung, true die Volltextfassung geliefert. Der Marker in der Mitte einer Antwort ⋯ ausgelassen N Zeichen (mit full=true in Volltext anschauen) ⋯ dient als Hinweis.
messung (echte 법제 API, feste IDs, n=8):
Domain | avg needed before | after (average) | Savings |
판례 (case-law) | 5,230 chars | 3,049 chars | -42 % |
헌판 (Constitutional Court) | 8,368 chars | 1,703 chars | -80 % |
행정-Review | 8,429 chars | 1,491 chars | -82 % |
Complete | 7,606 chars (about 1.) | 1,960 chars (490 tok.) | -74 % |
Bei langen Entscheiden (15.000 Zeichen+) ist die Ersparnis mit 80–85 % besonders deutlich. Kurze Bodies bleiben dank minSave im Original. Ohne Qualitätsitäts V. 0 (Always available: 판시, 요지, Tenor).
Unter dem Strich gen auch die ListTools-Payload um -14% (9,671 → 8,40 bytes, same). Die Anzahl der „nach hinten gestellten“ Zeichen sí −155: 8 Kompakt-Beschreibungen von chain_*, überflüssige doppelte search_…/get_… – Feldbeschreibungen 17 Jahre alte Domain weg .
v3.3.1 – Lexikon der Kurztitel deutlich erweitert (von 11 auf 52, also +41)
Durch Anfrage „산안기준규칙“ in lexdiff wurde bekannt, dass die Schlüsselwort-ähnliche Suche von Gesetz – Sprache „국가기준기준“ erzeugt (Halluzination). Deshalb wurde LAW_ALIAS_ENTRIES in resolveLawAlias stark erweitert. Cohen Sie jetzt u. a.: häufige Labor / Sicherheit (산안법·중층법·근기법 etc.), persönliche Daten / Informations-Technologie (개보법·정보통신망법), … sowie Publikum/Umschichtung/Bekämpfung (청탁금지법·이해충돌환지법), öffentliche Beschaffung (국가법·지방청법, Eigentums-/Mieterecht/재현: 주임법·상매법·부거법), contract law (공정금지법·하거법·약관법·표시광, Franchise Law), finance (자본시장·특금법·및 전자지불법), Stadtplanung (국토법·도진법), environment (protective etc.), transport (사용자), civil/criminal procedure (민소법·형법·민은), social insurance (국건법·재보험법·고보험법), communication (전기통신사업법). Da api-client.ts/law-parser.ts bereits resolveLawAlias verwenden, allein das Hinzufügen der Daten profitiert die bestehenden Such- und Analysewege automatisch. Mit 41 neue + 3 Regression → 45/45 Tests bestanden.
v3.3.0 – Umstellung auf HTTP-stateless-Modus + kordoc 2.3.0 (Ersatz vor V3.3.0 eigentlich Sind etc.)
Das Problem: Remote-Server (korean-law-mcp.fly.dev) ständigen OOM-Kills → Session-IDs wurden ungültig. Grundlegend behoben durch Stateless-Pattern aus der MCP-Spezifikation sessionIdGenerator: undefined); für jede Anfrage wird eine neue Server + Transport-Instanz erzeugt und nach Ende freigegeben. In-Ema-Session-Map, InMemoryEventStore, idle cleanup – komplett entfänt. Bei server restarts, scale-out, deployments: keine Verluste mehr. GET /mcpundDELETE /mcpantworten genau wie im offiziellen Beispiel mit405. API-Keys werden über AsyncLocalstorage` anteiligRequest isoliert (verhindern Race-Conditions).
HTTP stateless-Umstellung – src/server/http-server.ts (siehe auch
@modelcontextprotocol/sdk/examples/server/simpleStatelessStreamableHttp.js)kordoc 2.2.5 → 2.3.0 – parsing engine up to date
komplette Entfernung des Session-Managementcodes – Code für
sessions-Map,MAX_SESSIONS, Idle-CleanupsetInterval von,post/der/Löschen. Aufteilung wurde entfernt (ersetzt durch das LRU-Eviction in v3.2.3).
v3.2.3 – Mittelfristige Verbesserung der HTTP-Session-Stabilität. MAX_SESSIONS 100→500 + LRU-Eviction. Wird in v3.3.0 durch stateless ersetzt.
v3.2.2 – Das Formular-/Anhangstool (**get_annexes) in in die Standard-Tools aufgenommen. Exposure: 14 → 15 Tools. Zusätzlich automatische beim Anhang-Abgleich bei Abfragen zu Erstattung/Kürzung.
v3.2.1 – kordoc 2.2.5-Update.
Bitte beachten: In den 8 vorbereiteten Kettentemplates wurde ein zusätzlicher scenario-Parameter eingeführt. (Expedite Natur (inzwischen mit verify_citations and impact_map from v4.0) = 17.)
scenario | Host-Ketten | Zusätzliche Abfragen |
| chain_action? | Straftabellen im Anhänge + Sanktionsklauseln + RechtsbehelfEntscheidungen mit „nicht mehr Sanktion“ + Entstehungshistorie |
| chain full research | Auslegungen der ZollBehörde + SteuerberufungFälle + FTA-Verträge + Zollsätzen + mehrgleisige/Vergleich |
| chain procedure detail | Rechtsordnung (Verwaltungsvorschrift) + Auslegungsbekanntmachung + bindende kommunale Normen |
| chain_law_system | Delegationsrecht-Status + Rechtsbaum (durchführungsVorschriften) + Artikelhistorie |
| chain law system | Laumwerebaum + Nachbarschaft + Verknüpfung der Artikel + Verwaltungsvorschriften |
| chain_amendment_track | Zeitlichen Zuordnung von Rechtsprechungsfällen & Auslegung |
| chain_ordinance_compare | Verfassungsgerichtliche Unglücksentscheidungen + Verwaltungsgerichtsaufhebung + die Rechtliche höhere Basis |
Szenarien werden aus den Stichwörtern automatisch erkannt oder können über den Parameter scenario direkt angegeben werden.
Weitere Verbesserungen:
Ausgabe von Verwaltungsvorschriften (Regelungen) definitionsgemäß in
get_law_system_treemit enthalten (내규/Erlass)3 Falle für die Gesetz-Suche – automatische Extrahieren des Gesetz-Patterns bei komplizierten Abfragen
Verbesserte Rechtsprechung/interpretation in
chain_action_basis(suche auf Grundlage des Rechtsklers)
v3.1.5 – kordoc 2.2.4 + Parsing-Engine verbessert, README aktualisiert.
v3.1.4 – kordoc 2.2.4 Update. Merged cells als HTML <table>-Ausgabe, weiter formatierte markdownToHwpx.
v3.1.3 – „keine Treffer“ Hinweise in 18 Tools integriert. Session-Cleanup-Zeitraum geändert (30min→10min).
v3.1.2 – kordoc 2.2.1-Update. Der GFM-Tabellen verwenden spezielle Sonderbuchstaben-Escape und sowie Pipe-Konflikte unterdrückt.
v3.1.1 – kordoc 2.1→2.2-Update.
v3.1.0 – Production Hardening
Durch reale Nutzungsbeobachtungen 20 Dateien korrigiert: potenzielle Bugs, Sicherheit und Stabilität verbessert.
Fehlendes
truncateResponsenachgerüstet – endlich die 50KB-Antwortgrenzung in 17 Tools.HTTP-Server-Session–Limit – MAX_SESSIONS=100 hinzugefügt, also 503 bei Überlast. (DoS)
CORS-Wildcard-Warnung – erscheint als Warung auf stderr, falls nicht gesetzt.
Parameterverschmutzung – Der Versuch, Domain-Felder in
search_decisions/get_decision_textzu überstimmen, wird verhindert.Stabilität – Auth-Fehler (401/403/429) werden jetzt sofort propagiert,
findLawssicher verpackt.API-Memory-Leak –
throwIfErrorverbraucht response body; keine Streams offen mehr.CLI-Design-Weiter – REPL mod: zwei Ctrl+C erzwingt das Rauskommen.
SSE-Server entfernt – ungenutzter Code, HTTP-Server hat SSE bereits.
Dead Code / Dependencies Cleanup –
zod-to-json-schema,ordinal hintsund Skriptstart:ssegelöscht.
v3.0.2 – Unified Architecture + Setup Wizard.
비. Versions je nach:법제 – The Korean legislative API in 41 APIs, v2 structured them into sind 89 Tools. v3 die API wieder auf 14 Tools kompressed (nach v3.2.2 15, v3.4.0 16, nach v4.0 17, nach v4.3 19, v4.4.0 again collatts to 9, currently 10).)
Legal Source: Korean | v2 | v3 | |
APIs / Tools | 41 | 89 | 14 |
KI-Kontextkosten... | - | ~110 KB | ~20 KB |
vollständig.. | - | 100% | 100% |
Profilführung | - | lite/full basis | single (nicht nötig) |
Warum wurden aus 89 Tools 14?
Fehler von v2: Ein Tool pro API. Das war zwar intuitiv, aber die AI muss alle 89 Schemas durchlesen – dadurch Hälfte des Kontexts geht nur für die Tool-Listen drauf.
v3 Ansatz: Ähnliche Tool-Muster in einen gemeinsamen domain Parameter zusammengef – Bereits 18 Domänen (Recht, Verfassung, Steuer, Fairhandel, etc.) werden durch 2 Tools search_decisions(domain) + get_decision_text(domain) abgedeckt.
Weitere Spezialwerkzeuge (Rechtsbegriffe, Anhange, Historie) werden unverändert verfügbar, aber nur bei Bedarf > über discover_tools → execute_tool.
Was verbessert sich aus Ursersicht?
Kleinere Karte für die KI, 나은 결과 in multi-round, deutlich weniger Verwirrung wegen Unbekannte Namen, Result matrimoniert ebenfalls; einfachere Schnittstelle.
KI ist genauer – Früher musste die KI aus 89 Kandidaten wählen, jetzt entscheidet sie anhand von nur 14 sofort.
Spürbar schnellere Antwortzeiten – Kontext um 82 % reduziert
Einfachere Einrichtung – Keine Profilwahl (lite/full) mehr nötig. In allen Clients dieselben 14 Tools
Sofortiger Zugriff auf 17 Entscheidungsdomänen – Direkt suchen, ohne den Umweg über
discover
Weitere Änderungen
kordoc 1.6 → 2.2.5 – Dokumentparsing-Engine aktualisiert (XLSX/DOCX-Unterstützung, bessere Sicherheit, Formularausfüllung)
Fehler bei der Volltextabfrage von Verwaltungsbeschwerden behoben – Fallback für API-Antwortschlüssel ergänzt
Fehler bei der Volltextabfrage englischsprachiger Gesetze behoben – Unterstützung der neuen API-Antwortstruktur
Für Entwickler
Bei der Gestaltung von MCP-Tools gilt: Anzahl der Tools ≠ Anzahl der Funktionen. Der Prozess, 44 APIs auf 89 Tools auszurollen und dann wieder auf 14 zu reduzieren, war die Reise zum richtigen Abstraktionsgrad.
Kernmuster: Dispatch Table + Domain Enum. Die bestehenden Handler-Funktionen mussten nicht um eine einzige Zeile geändert werden.
v2.3.2 – Produktionscode-Qualität verbessert (Dateien, −179 Zeilen). Emojis/Dekorationen reduziert, Chain-Caching, vereinheitlichte Fehlerbehandlung.
v2.3.0 – Tool-Profile (lite/full), API-Key per URL-Query, integrierter kordoc-Parser.
v2.2.0 – 23 neue Tools (64→87). Verträge, Verknüpfung Gesetz–Satzung, Dokumentanalyse-Engine.
v1.8~1.9 – 8 Verkettungstools, Stapelabfrage von Gesetzesartikeln, KI-Suchfilter, strukturiertes Fehlerformat.
Warum es das gibt
In Südkorea gibt es mehr als 1.600 geltende Gesetze, mehr als 10.000 Vorschriften und ein weitreichendes, sich bis zu 대법원(bis zum Obersten Gerichtshof), 헌법재판소 (Verfassungsgericht), 조세심판원 (Steuergerichtsbarkeit) und 관세청 (Zollbehörde) erstreckendes System von Fallentscheidungen. All das liegt auf 법제처, einer einzigen Website – doch die Developer-Experience ist miserabel.
Dieses Projekt verpackt das gesamte Gesetzesrechtssystem in 10 Tools, die direkt von KI-Assistenten oder Skripten aufgerufen werden können. Es wurde von einem Beamten entwickelt, der die manuelle Suche über hundert Seiten verschlissen hat.
Installation & Verwendung
Schritt 0: API-Schlüssel anfordern (kostenlos, 1 Minute)
Besorgen Sie zuerst den 법제처 Open-API-Authentifizierungsschlüssel(OC), den alle Methoden gemeinsam benötigen:
Rufen Sie die Open-API-Antragsseite von 법제처 auf.
Registrieren Sie sich und melden Sie sich an.
Klicken Sie auf die Schaltfläche „Open API 사용 신청“.
Nach dem Abschicken des Antrags wird Ihr Authentifizierungsschlüssel(OC) ausgestellt (z. B.
honggildong).Verwenden Sie diesen Authentifizierungsschlüssel in den nachfolgenden Einstellungen.
Methode 1: Claude Code-Plug-in (Ein-Zeilen-Installation, am einfachsten) ⚡
Wenn Sie Claude Code verwenden, genügen zwei Zeilen. Nach Ihren API-Schlüssel wird während der Installation automatisch gefragt.
/plugin marketplace add chrisryugj/korean-law-mcp
/plugin install korean-law@korean-law-marketplaceWährend der Installation erscheint eine Eingabeaufforderung zur Eingabe des 법제처-API-Schlüssels (z. B. der in Schritt 0 erhaltene Schlüssel wie honggildong). Er wird sicher als sensible Information gespeichert.
Anwendung: Fragen Sie Claude Code in natürlicher Sprache – das korean-law MCP-Tool wird dann automatisch aufgerufen.
"근로기준법 제74조 알려줘"
"민법 제750조 판례 검증해줘"Update: Wenn eine neue Version erscheint, holen Sie sie mit einer Zeile ein:
/plugin marketplace update korean-law-marketplaceIntern wird
npx --ignore-skip --ignore-scripts --omit=optional korean-law-mcp@latestausgeführt. Es wird also die neueste auf npm veröffentlichte Version verwendet, aber optionale OCR-, ML- und native Abhängigkeiten werden nicht installiert und Installationsskripte nicht ausgeführt.
Troubleshooting: Fehler Permission denied (publickey)
Tritt während der Installation dieser Fehler auf, hat der Claude-Code-Installer versucht, per SSH auf GitHub zuzugreifen, aber es ist kein SSH-Schlüssel hinterlegt (besonders häufig bei Nicht-Entwicklern und juristischen Fachleuten, die Git zum ersten Mal nutzen).
Failed to install: Failed to clone repository: Cloning into
'/Users/<user>/.claude/plugins/cache/temp_github_<id>'...
git@github.com: Permission denied (publickey).
fatal: Could not read from remote repository.Lösung (eine der beiden Varianten):
Über HTTPS umleiten (einfachste, empfohlene Variante): Im Terminal eine Zeile ausführen und dann
/plugin installerneut versuchen.git config --global url."https://github.com/".insteadOf "git@github.com:"SSH-Schlüssel erzeugen und bei GitHub registrieren: Falls Sie gewöhnlich andere Repos ort über SSH mit einem GitHub Account nutzen wollen:
ssh-keygen -t ed25519 -C "your-email@example.com" # 엔터 3번 cat ~/.ssh/id_ed25519.pub # 출력 복사Fügen Sie den kopierten öffentlichen Schlüssel unter GitHub → Settings → SSH and GPG keys → New SSH key ein.
Nach der Installation können Sie die obige Rewrite-Konfiguration einfach so bestehen lassen (HTTPS-Clone funktioniert dann immer).
Methode 2: Direkt auf im Claude.ai-Webclient verwenden (ohne Installation)
Ohne etwas zu installieren, geben Sie einfach eine Adresse ein. Sie benötigen eines der kostenpflichtigen Claude-Abos Pro/Max/Team/Enterprise (bei Free ist nur ein Connector möglich).
Connector hinzufügen:
Loggen Sie sich bei claude.ai ein.
Klicken Sie in der linken Seitenleiste unten auf Ihren Namen.
Wählen Sie „설정“ (bzw. Settings).
Gehen Sie zum Menü „커넥터“ (bzw. Connectors).
Klicken Sie im Bereich „커스텀 커넥터“ auf „커스텀 Connector hinzufügen“.
Geben Sie Folgendes ein:
Name:
korean-law(beliebiger Name möglich)URL: Fügen Sie die folgende Adresse ein. Ersetzen Sie
honggildongdurch Ihren in Schritt 0 erhaltenen Authentifizierungsschlüssel:
https://mcp.gomdori.app/law?oc=honggildongKlicken Sie auf Addieren bzw. 추가 – fertig registriert!
Tools aktivieren (wichtig!):
Klicken Sie auf "구성" (bzw. Configure) des angelegten Connectors.
Erscheint die Toolauswahl, stellen Sie alle Tools auf "항상 사용" (bzw. Always-Allow) ein.
Damit kann die KI Gesetze direkt nachschlagen, ohne dass Sie jedes Mal zustimmen müssen.
Nutzung:
Gehen Sie zum Chat zurück und geben Sie „근로기준법 제74조 알려줘“ ein – fertig!
Hinweis: Zum Ändern der Connector-URL müssen Sie den Connector löschen und neu hinzufügen.
Ab v3 ist keine Profilauswahl mehr erforderlich. Die 10 Tools decken alle 42 APIs ab. Wenn Sie bisher die Adresse
?profile=lite&oc=...eingetragen haben, können Sie sie so lassen – sie funktioniert weiterhin identisch.
###Methode 3: Mit AI-Desktop-Apps verwenden (ohne Installation)
Wenn Sie Desktop-Apps wie Claude Desktop, Cursor oder Windsurf verwenden, tragen Sie Folgendes in die Konfigurationsdatei ein.
Konfigurationsdatei finden:
App-Name | Windows | Mac |
Claude Desktop |
|
|
Cursor |
|
|
Windsurf |
|
|
Claude Desktop
Claude Desktop kann einen entfernten HTTP-MCP-Server nicht direkt verbinden; die Verbindung erfolgt über den mcp-remote-Adapter. Sie benötigen Node.js 18 or higher (for the use of npx):
{
"mcpServers": {
"korean-law": {
"command": "npx",
"args": [
"-y",
"mcp-remote",
"https://mcp.gomdori.app/law?oc=honggildong"
]
}
}
}Ersetzen Sie
honggildongmit Ihrem eigenen Authentifizierungsschlüssel. Wenn Sie Node.js nicht installieren möchten, verwenden Sie die lokale Installation aus Methode 4.
Cursor, Windsurf usw. (Clients mit Remote-HTTP-Unterstützung)
{
"mcpServers": {
"korean-law": {
"url": "https://mcp.gomdori.app/law?oc=honggildong"
}
}
}Wenn bereits andere MCP-Server eingerichtet sind, genügt es, innerhalb von
"mcpServers": { ... }nur den Teil"korean"S -law": { ... }hinzuzufügen.
Speichern und starten Sie die App neu – die Gesetzestools sind dann aktiv.
Methode 4: Direkt auf dem eigenen Computer installieren (offline möglich)
Wenn Sie ohne Internet arbeiten möchten oder nicht über ferne Server, installieren Sie direkt lokal.
Voraussetzungen: Node.js 20.19+ ist erforderlich (22.12+ empfohlen).
Automatische Installation (empfohlen):
npx --ignore-scripts --omit=optional korean-law-mcp setupDer Installationsassistent übernimmt die Eingabe des API-Keys, die Auswahl des AI-Clients und die automatische Registrierung in der Config-Datei in einem Schritt. Unterstützt werden Claude Desktop, Claude Code, Cursor, VS Code, Windsurf, Gemini CLI, Zed und Antigravity.
Manuelle Installation:
npm install --ignore-scripts --omit=optional -g korean-law-mcpFügen Sie in der Konfigurationsdatei der AI-App Folgendes hinzu (ersetzen Sie honggildong durch Ihren Bildschlüssel):
{
"mcpServers": {
"korean-law": {
"command": "korean-law-mcp",
"env": {
"LAW_OC": "honggildong"
}
}
}
}Nach dem Neustart der App ist alles fertig!
Methode 5: Direkt vom Terminal (CLI)
Als Entwickler können Sie auch direkt vom Terminal aus nach Gesetze suchen:
# 설치
npm install --ignore-scripts --omit=optional -g korean-law-mcp
# 인증키 설정 (honggildong을 본인 키로 바꾸세요)
export LAW_OC=honggildong # Mac/Linux
set LAW_OC=honggildong # Windows CMD
$env:LAW_OC="honggildong" # Windows PowerShell
# 사용 예시
korean-law "민법 제1조" # 자연어로 바로 조회
korean-law search_law --query "관세법" # 도구 직접 호출
korean-law list # 전체 도구 목록
korean-law list --category 판례 # 카테고리별 필터
korean-law help search_law # 도구별 도움말Übersicht: Übergabe des API-Keys
Sie can have the verification wiedergabe auf mehreren Wegen. Die obenstehende Reihenfolge gilt als Prioritäts:
Methode | Verwendung | Wann? |
In der URL |
| am einfachisten bei Web-Clients |
HTTP-Header |
| bei programmatischer Anbindung |
Umgebungsvariable |
| bei lokaler Installation (Methode 3, 4) |
Tool-Parameter |
| wenn für eine bestimmte Anfrage ein anderer Schlüssel genutzt wird |
Protokoll-Einstellung der juristischen API
Die Aufrufe der Act-API verwenden standardmäßig HTTPS. In Umgebungen mit schwacher Zertifikatsprüfung (Intranet, abgeschottete Netze usw.) können Sie LAW_API_PROTOCOL=http setzen, um per HTTP aufzurufen.
Am klarsten ist es, die Variable zusammen im env-Block der MCP-Clients-Konfiguration zu setzen:
{
"mcpServers": {
"korean-law": {
"command": "korean-law-mcp",
"env": {
"LAW_OC": "honggildong",
"LAW_API_PROTOCOL": "http"
}
}
}
}Sie können sie auch direkt im Terminal setzen oder eine .env-Datei verwenden:
export LAW_API_PROTOCOL=http # Mac/Linux
set LAW_API_PROTOCOL=http # Windows CMD
$env:LAW_API_PROTOCOL="http" # Windows PowerShellLAW_OC=honggildong
LAW_API_PROTOCOL=httpZulässige Werte sind http und https. Ohne Setzung oder bei ungültigen Werten wird https verwendet.
TLS-/Proxy-Einstellungen für die Gerichtsentscheidungen von 국세청
Die Volltexte von Entscheidungen der 국세청 (National Economic Service) sind manchmal nicht allein über die JSON-Antwort von 법제법 abgedeckt. Darum wird zusätzlich intern der Präzedenzfall-Server von taxlaw.nts.go.kr abgefragt. Dieser Server leitet HTTP auf HTTPS weiter – daher muss die Node.js-Laufzeitumgebung unabhängig von LAW_API_PROTOCOL=http dem Zertifikat von https://taxlaw.nts.go.kr vertrauen.
Im Intranet, abgeschlossenen Netzen, hinter Firewalls oder SSL-inspection-Proxies: Der Präzedenzfall im Browser geöffnet werden, aber nur Node.js fetch() kann mit [EXTERNAL_API_ERROR] fetch failed scheitern. Das liegt daran, dass Browser und Node.js verschiedene Zertifikatsspeicher und Proxy-Konfigurationen verwenden.
Prüfen Sie zunächst in der Produktiv Umgebung, ob die HTTPS-Verbindung mit Node.js funktioniert:
node -e "fetch('https://taxlaw.nts.go.kr/qt/USEQTA002P.do?ntstDcmId=200000000000019303').then(r=>console.log(r.status,r.url)).catch(e=>console.error(e.name,e.message,e.cause))"Wird die Verbindung im operativen Netz gekappt und muss über einen separaten Web-Proxy laufen, setzen Sie für den tatsächlichen Proxy-Server ein. Diese Einstellung gilt derzeit für die ausgehende HTTPS-Verbindung, die die Nationale Steuerrecht/Praxis-Daten nutzt:
LAW_EXTERNAL_HTTPS_PROXY=http://proxy-host:8080Unter Windows setzen Sie Systemumgebungsvariablen in einer Terminals mit Administratorrechten. Starten Sie danach Windows bzw. den Node.js-Prozess neu:
setx LAW_EXTERNAL_HTTPS_PROXY http://proxy-host:8080 /MBleibt die Unternehmenszertifikat-Prüfung im Proxy-Pfad ein Thema, kann Testzweken die TLS-Zertifikatsvalidierung nur für den externen HTTPS-Proxy-Pfad dieses Projekts temporär deaktiviert werden. Don't use im dauerhaften Betrieb:
setx LAW_EXTERNAL_TLS_REJECT_UNAUTHORIZED 0 /MNach der Diagnose entfernen:
reg delete "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment" /v LAW_EXTERNAL_TLS_REJECT_UNAUTHORIZED /fUsage examples
"관세법 제38조 알려줘"
→ search_law("관세법") → MST 획득 → get_law_text(mst, jo="003800")
"화관법 최근 개정 비교"
→ "화관법" → "화학물질관리법" 자동 변환 → compare_old_new(mst)
"근로기준법 제74조 해석례"
→ search_interpretations("근로기준법 제74조") → get_interpretation_text(id)
"산업안전보건법 별표1 내용 알려줘"
→ get_annexes(lawName="산업안전보건법 별표1") → HWPX 파일 다운로드 → 표/텍스트 Markdown 변환Tool-Struktur (10 Tools)
In v4.4.0 wurden die verfügbaren Tools konsolidiert (Kontextreduktion um 52 %). Die bisherigen 8 chain_*-Tools sind jetzt als task in legal_research integriert, die 4 Killer-Features als mode in legal_analysis. Die übrigen Spezialwerkzeuge erreichen Sie über discover_tools → execute_tool. Die direkte aufrufen alten Toolnamen funktionieren weiterhin abwärtskompatibel. In v4.7.0 kam ordinance_radar hinzu, also 10 Tools.
Kategorie | Werkzeug | Beschreibung |
Research (1) |
| Mehrstufige Gesetzesrecherche – |
Präzisionsanalyse (1) |
| Verifizierung & Analyse – |
Gesetze (3) |
| Gesetzessuche → Erhalt von |
| Volltextabfrage der Gesetzesartikel | |
| Abfrage von Anlagen/Formularen (Betrags-/Tariftabellen, Vorsätze) | |
Satzungen (1) |
| Pflege-Radar für Satzungen – automatischer Abgleich mit Gesetzesänderungen der übergeordneten (v4.7.0) |
Integration (2) |
| 18 Domains-integrierte Suche (Präzedenz, Verfassungsgericht, Steuerentscheide, Fair-Trade-Kommission, Arbeitsausschuss, Zoll, Interpretationsfälle, Verwaltungsentscheide, Datenschutzinspektionen, Rechtsauskünfte, Überprüfungen, Hochschulregeln, Körperschaften/Institute, öffentliche Einrichtungen, Verträge, englischsprachige Gesetze) |
| Volltextabfrage für die 18 Domainsen | |
Meta (2) |
| Suche über Spezialwerkzeuge (Begriffe, Anlagen, Verlauf, Vergleich) |
| Proxy-Ausführung von Spezialwerkzeugen |
legal_research task-Arten (8) (ehem. chain_*)
task | Beschreibung (e.g., | Szenarioerweiterung |
| Umfassende Recherche (KI-Suche → Gesetz → Präzedenz → Auslegung) |
|
| Analyse der Gesetzsystemstruktur (3-Ebenen-Vergleich, Delegation) |
|
| Grundlage für Verwaltungsentscheide (Erlaubnis, Genehmigung, Entscheid) |
|
| Vorbereitung für Streitigkeiten (Widerspruch, Klage, Verfahren) |
|
| Gesetzesänderungen verfolgen (Alt-Neu-Vergleich, Historie) |
|
| Vergleich von Satzung (übergeordnetes Gesetz → landesweite Satzungen) |
|
| Verfahrens-, Kosten- und Formularinformationen |
|
| Risikoanalyse in Verträgen/AGB ( | – |
legal_analysis Mods (4, vorher Killer-Features)
Mode | Beschreibung | Pflicht Parameter |
| Verhindert LLM-Halluzinationen – prüft in einem Zug, ob alle angeführten Paragrafen existieren (v3.5) |
|
| Status von Entscheidungen – Rückwärtsverfolgung, geänderte/verfallende Autorität, Koreanischer Citator (v4.3) |
|
| Bestimmung des Rechten zur Handlungszeit (v4.3) – passende Fassung + Übergangsbestimmung des Begleitgesetzes |
|
| Paragrafen-Wirkungsgraph – Rückwärts search nach zitierter Rechtsprechung, Auslegungen & Satzung + Mermaid (v4.0) |
|
Alle Details der Tools am docs/API.md.
Wichtigste Funktionen
42 APIs → 10 Werkzeuge – Gesetze, Rechtsprechung, Verwaltungsregeln, Satzung, Rechtsverordnung, Entscheidungen Konstituniv, Steuerhigkeiten, Zollinterpretation, Service-Channels, sämtliche Präzedenzfragen, Verträge, Staatliche Satzungen, Begriffsklärung.
MCP + CLI – Dieselben Tools über Claude Desktop und im Terminal.
Jurisfachlich spezialisiert – Automatische Erkennung von Kurzbeispielen (
화관법→화학물질관리법), Artikel-Umnummerierung (제38조↔003800), Visualisierung der 3-Ebenen-Behmechnung.Anhang/Formularprotokoll – HWPX·HWP·PDF·XLSX·DOCX automatisch in Text umwandeln (kordoc-Engine).
8 Kettentools + 9 Szenarien – Automatische situative Zusatzanalyse zur Standard-Kette (z. B. Bußgeldrabatt, Zollabwicklung, Überwachung der Rechtsetzungmacht).
18-Domain-Komplettsuche – ein einziges
search_decisionsgibt sofort Rechtsfälle, Verfassungsgerichtsentscheide, Steuerbeschwerden, Kartell- und Arbeitssachen, Zoll, Auslegungsfälle usw. zurück.Cache –1h für Suche, 24h für Volltextparagraphen.
Remote-Endpoint – ohne Installation direkt unter
https://mcp.gomdori.app/lawverfügbar (auch alte URLkorean-law-mcp.fly.dev/mcpbleibt abwärtskompatibel).
HTTP-/Executioneinstellungen
Der HTTP-Standardbind ist
MCP_HTTP_HOST=127.0.0.1, und vertrauensbehaftet für Proxy ist standardTRUST_PROXY=false. Für externe Bindungen mussMCP_AUTH_TOKENgesetzt sein;MCP_ALLOW_UNAUTHENTICATED_REMOTE=1nur zunächst, wenn Sie dies absichtlich öffentlich maiten. Hinter Proxyservern genau hopne Anzahl als Wert anifying,TRUST_PROXY=1.RATE_LIMIT_RPM=0deaktiviert nur die Begrenzung per IP.MCP_MAX_BATCH_CALLS(Standard 20), Request-Body, Upstream-Zahl / -Response sowie Response-Limit für Tools gelten weiterhin.MCP_MAX_BODY_BYTES,MCP_MAX_UPSTREAM_REQUESTS(Standard 48),MCP_MAX_UPSTREAM_BODY_BYTES,MCP_MAX_TOTAL_UPSTREAM_BODY_BYTESundMCP_MAX_TOOL_RESPONSE_CHARSwerden beim Start als ganze Zahlen validiert; falsche Werte verhindern den Serverstart. Das bestehendeMCP_BODY_LIMIT=master bytesbleibt kompatible.get_batch_articlesist auf 20 Gesetze und insgesamt 100 Paragrafen begrenzt. Das Schließe der HTTP-Verbindung bzw. der Abbruch überträgt bis infetch, einschließlich des Wartens auf den Retry und der Lesung der Antworten. JSON-RPC-Ansätze haben nur ein gemeinsamesBudget, die Abbruchsignale sind getrennt.Vor dem Publish wird
build/gelöscht, und die Packungen und Exports werden tatsächlich validiert.kordocbleibt erhalten, da es real für Apple-Anhänge/PDF/HWP-Parsen verwendet wird; nur das reine Chrom-JSpdfjs-dist@4.10.38ist als normale Abhängigkeit fixiert. Plugin-, Dokument- und Docker-Installationen werden--omit=optional --ignore-scriptsdie optionalen OCR/ML/native Abhängigkeit auslassen. CI/publication-Werkflows installieren ggf. optionale Funde der Entwicklungstools, prüfen aber mit deaktivierten Skripts; dann wird der Produktionsprudent erzeugt und ein PDF-Smoke-Test für Anhänge ausgeführt. Warnungen von transistiven Scans werden getrennt von den tatsächlich erreichbaren Serverpfaden bewertet.
Dokumentation
docs/API.md — Tool-Referenz
docs/ARCHITECTURE.md — Systemarchitektur
docs/DEVELOPMENT.md — Entwicklungsleitfaden
Star History
Datenquellen
Die Volltexte von Gesetzen, Verordnungen, Gerichtsentscheidungen, Verwaltungsvorschriften, kommunalen Rechtsvorschriften, Verträgen und Auslegungsfällen werden über die OPEN API des Nationalen Zentrums für Gesetzesinformation des Ministeriums für Gesetzgebung (https://open.law.go.kr/) abgerufen. Die Auslegungsfälle der Nationalen Steuerverwaltung werden über das Steuerrechts-Informationssystem abgerufen.
Für rechtlich bindende Entscheidungen prüfen Sie unbedingt den Originaltext im Nationalen Zentrum für Gesetzesinformation. Dieses Werkzeug kann die Abfrageergebnisse aufbereiten und zusammenfassen.
Der API-Authentifizierungsschlüssel (LAW_OC) muss beim Ministerium für Gesetzgebung jeweils individuell beantragt werden; er darf nur von der Person verwendet werden, die ihn erhalten hat.
Lizenz
Hinweise zu Referenzen auf Drittimplementationen und Datenquellen finden Sie in NOTICE.
Erstellt von 류주임 @ AI-Club AI.Do des Bezirksamts Gwangjin-gu
Available Tools
10 toolsdiscover_toolsARead-onlyIdempotent
Korean-law-mcp — [메타] 위 도구로 안 되는 경우. 전문도구(조세심판·관세·헌재·행심·공정위·개인정보위·노동위·학칙·조약·영문법령·용어 등 80+개) 카테고리 검색
| Name | Required | Description | Default |
|---|---|---|---|
| intent | Yes | 찾고 싶은 도구의 의도 또는 카테고리 (예: '공정위', '조약', '용어', '헌재') |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful context beyond that: it is a meta/category-search tool for 80+ specialized domains. Nothing in the description contradicts the annotations — '카테고리 검색' (category search) is consistent with a read-only, idempotent lookup.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact — a single sentence with the meta/fallback context front-loaded before the category list. While the parenthetical enumeration is dense, there is no waste and the key routing instruction comes first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter discovery tool with rich annotations and 100% schema coverage, the description is mostly sufficient: it states when to use it and what it searches. However, it does not describe the output/return format (there is no output schema), and the Korean-only text plus ambiguous '위 도구' reference leaves some agent-facing details unresolved.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: the 'intent' parameter is described with meaning and examples ('공정위', '조약', '용어', '헌재'). The description's listing of categories (조세심판, 관세, 헌재, etc.) reinforces what 'intent' accepts but adds little beyond the schema. Baseline 3 applies since the schema already carries the heavy lifting for the single parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear purpose: a meta-tool for category-based search across 80+ specialized legal tools (tax appeal, customs, constitutional court, etc.). It distinguishes itself from the sibling tools by branding itself as '[메타]' (meta) and a fallback when standard tools fail. The purpose is specific and recognizable, though it never names actual sibling tools and is written in Korean.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives an explicit condition — '위 도구로 안 되는 경우' (when the above tools don't work) — framing it as a fallback/discovery gateway. However, '위 도구' is vague and does not identify which siblings it applies to, nor does it state when NOT to use it or what 'not working' means. The guidance is present but underspecified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
execute_toolARead-onlyIdempotent
Korean-law-mcp — [메타] discover_tools 결과 도구를 프록시 실행. tool_name + params
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes | 도구에 전달할 파라미터 객체 | |
| tool_name | Yes | 실행할 도구 이름 (discover_tools로 확인한 이름) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false), so the description does not repeat that. It adds the important constraint that the tool must come from discover_tools, which is behavioral context beyond the annotations. No contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, brief sentence that front-loads the purpose and parameter essentials without any fluff. It is appropriately short for a simple proxy concept, though it could benefit from slightly more elaboration without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a proxy tool that can execute any tool, the description is minimal and omits key guidance. It does not explicitly state the prerequisite of calling discover_tools first, nor does it explain error handling or what happens with invalid tool names. The schema provides some context, but the tool description itself is insufficient for a complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the description merely restates the parameter names (tool_name + params) without adding further meaning. Since the schema already documents both parameters fully, the description adds no extra value, matching the baseline score for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that this is a proxy execution tool for tools discovered via discover_tools, taking a tool_name and params. It effectively identifies the function as a meta-tool that runs other tools, which distinguishes it from the specific sibling tools. However, it does not explicitly mention the return value, though that is implied to be the result of the underlying tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is to be used after discover_tools by referencing 'discover_tools 결과 도구' (tools from discover_tools results), but it does not explicitly state when to use it versus directly calling a specific tool. It lacks clear guidance on prerequisites or exclusions, leaving usage conditions to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_annexesBRead-onlyIdempotent
Korean-law-mcp — [별표] 별표/서식 조회. lawName+'별표N'으로 내용 추출. 금액/기준은 별표에 있는 경우 많음.
| Name | Required | Description | Default |
|---|---|---|---|
| jo | No | 위임 조문 (예: '제38조', '38'). 조문 동반 질의('관세법 제38조 별표2')의 조문 맥락 — 별표명의 '(제38조 관련)' 표기와 대조해 좁히고, 응답에 위임 관계를 표기 | |
| knd | No | 1=별표, 2=서식, 3=부칙별표, 4=부칙서식, 5=전체 | |
| query | No | 별표명으로 좁히기 (예: '운전면허 취소·정지', '과태료'). 번호를 모를 때 사용. 1건으로 좁혀지면 그 별표 본문을 바로 추출 | |
| bylSeq | No | 별표번호 (예: '000300'). 지정 시 해당 별표 파일을 다운로드하여 텍스트로 추출 | |
| annexNo | No | 별표 번호 (예: '4', '별표4', '제4호'). bylSeq 대체 입력 | |
| lawName | Yes | 법령명 (예: '관세법'). 별표를 바로 지정하려면 '... 별표4' 또는 '... 별표1의2'처럼 함께 입력 가능 |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the extraction method (lawName+'별표N') and a note about content location, which is useful context beyond the annotations, but it does not describe download/return behavior or other nuances. Given the annotations, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a single sentence stating purpose and extraction pattern, plus one hint sentence. It is front-loaded with the identifier '[별표]' and avoids redundant details. No filler is present, though the brevity limits the depth of guidance provided.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters, no output schema, and a specialized retrieval purpose, the description provides the core purpose and a usage hint but does not explain return formats, error conditions, or comprehensive selection logic against siblings. The detailed schema compensates for parameter understanding, but the overall context is still somewhat thin for an agent deciding when to invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all 6 parameters are already documented with meaning. The description's pattern lawName+'별표N' adds a small usage hint, but it largely repeats what the schema conveys (e.g., lawName can include '별표4'). No significant added value beyond the schema, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves annexes/forms (별표/서식) and gives the pattern lawName+'별표N' for extraction. It is specific to a resource type and distinguishes itself from siblings like search_law (search) and get_law_text (full text) by focusing on annex content, though it does not explicitly name those alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers a usage hint ('금액/기준은 별표에 있는 경우 많음' – amounts/criteria are often in the annex), implying when to use the tool for such content. However, it lacks explicit when-not-to-use guidance and does not mention alternative tools for comparison, leaving the decision partly to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_decision_textBRead-onlyIdempotent
Korean-law-mcp — [통합조회] 18개 도메인 전문 조회. domain+id. full=false(기본) 시 본문 계단식 축약
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | 일련번호/ID (search 결과에서 획득) | |
| full | No | true=본문 전문 그대로. 미지정=이유/전문 섹션 계단식 축약 (판시·요지·주문은 항상 full) | |
| domain | Yes | 도메인 선택 (enum 값 참조) | |
| options | No | 도메인별 옵션. treaty:{chrClsCd:'010202'(한)/'010203'(영)} english_law:{mst,lawName} prec/constitutional/admin_appeal/interpretation:{caseName} |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds genuinely useful behavior beyond this: full=false (default) progressively condenses the body, which informs the agent that full=true is required for unabridged text. This complements, and does not contradict, the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact — a single front-loaded line with no filler. The leading 'Korean-law-mcp —' prefix is meta labeling rather than functional content, and the dense Korean shorthand (계단식 축약) reduces immediate parseability, but the description remains efficient and well-oriented.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is complex — an 18-domain enum, a nested options object with domain-specific structures (treaty, english_law, precedent), and no output schema. The rich schema (100% coverage) carries most of the weight, and the description supplies the key default behavior. Still, the description leaves usage context (fetch vs search) unaddressed, which is significant given the absence of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all four parameters (domain, id, full, options) are already documented in the schema, including the full default behavior, domain enums, and options structure. The description restates domain+id and the full=false default without adding meaning beyond the schema, so it only meets the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action — full-text retrieval (통합조회) of decisions across 18 domains using domain+id. It identifies the resource (decision text) and the retrieval mechanism. However, it does not explicitly name siblings like get_law_text (law text vs decision text) or search_decisions (search vs direct id fetch), so differentiation is implied rather than stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. The description never mentions search_decisions, get_law_text, or when direct id-based retrieval is appropriate. The only usage hint ('obtained from search results') lives in the schema's id description, not the tool description, so the agent gets no explicit routing help between 9 siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_law_textARead-onlyIdempotent
Korean-law-mcp — [법령조회] 조문 전문 조회. mst/lawId 필수, jo로 특정 조문만 가능 — jo는 '제148조의2' 같은 자연어 조문 표기를 그대로 받는다(권장). 6자리 JO 코드를 직접 쓰려면 조번호 4자리 zero-pad + 의X 2자리: 제10조의2→001002, 제234조의2→023402(234002 아님).
| Name | Required | Description | Default |
|---|---|---|---|
| jo | No | 조문 번호. 자연어 표기 권장 — '제38조'·'제148조의2'를 그대로 넣으면 서버가 변환한다. 6자리 JO 코드 직접 지정 시 조번호 4자리 zero-pad + 의X 2자리: 제38조→003800, 제10조의2→001002, 제234조의2→023402(234002 아님) | |
| mst | No | 법령일련번호 (search_law에서 획득) | |
| efYd | No | 시행일자 (YYYYMMDD 형식) | |
| lawId | No | 법령ID (search_law에서 획득) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering safety. The description adds the jo conversion rule, which is useful behavioral detail. However, it states mst/lawId are 필수 (required) while the schema lists no required parameters, a contradiction with the schema. It also doesn't clarify what happens when jo is omitted. These inconsistencies reduce transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense sentence that front-loads the purpose and includes key usage details. It is concise and avoids fluff, though the parentheticals make it slightly dense. It earns a 4.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple lookup, but the description leaves ambiguity about behavior when jo is omitted and the return format. It also has the requiredness inconsistency with the schema. Given the tool's simplicity and the annotations covering safety, it's mostly complete but has notable gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all four parameters are already documented in detail. The description repeats the jo conversion rule but adds no new semantic beyond the schema. It mentions mst/lawId necessity, which is more of a usage note than parameter semantics. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves full text of a specific article ('조문 전문 조회'), which is a specific verb+resource. It distinguishes from siblings like search_law (which finds laws) and get_decision_text (which gets decisions) by focusing on article-level text retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly indicates that mst/lawId are obtained from search_law, establishing a workflow. However, it does not mention when to prefer this over other tools like get_annexes or legal_research, nor does it state when not to use it. The context is clear but lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
legal_analysisARead-onlyIdempotent
Korean-law-mcp — [정밀분석] 검증·분석 4종 통합. mode: verify_citations=텍스트 속 법령 조문·판례 인용('민법 제750조', '대법원 2013다61381' 등)이 실존하는지 법제처 DB 교차검증, LLM 환각 방지 — 판례는 실존불가/미확인 구분(text 필수) | cite_check=판례 생사 확인 — 사건번호로 후속 인용 역추적+변경·폐기 감지, 한국형 Citator(caseNumber 필수) | applicable_law=사건 시점에 시행되던 법령 버전+그 시점 조문+부칙 경과조치, 행위시법 판단(lawName+date 필수, jo 선택) | impact_map=한 조문을 인용한 판례·헌재·해석례·행심·조례 역방향 그래프+mermaid(lawName+jo 필수, jo는 '제103조'·'103조'·JO 6자리 코드 '010300' 모두 수용)
| Name | Required | Description | Default |
|---|---|---|---|
| jo | No | [impact_map 필수, applicable_law 선택] 조문 번호 — 자연어 표기('제103조', '제10조의2')와 6자리 JO 코드('010300', '001002') 모두 수용 | |
| date | No | [applicable_law 필수] 기준일 — 행위·계약·처분 시점 (예: '2023-05-10', '20230510') | |
| mode | Yes | 분석 유형 (도구 설명의 mode 표 참조) | |
| text | No | [verify_citations 필수] 검증할 법률 텍스트 (LLM 답변/계약서 등 조문 인용 포함 문자열) | |
| display | No | [cite_check] 후속 인용 판례 최대 표시 수 (기본 20) | |
| lawName | No | [applicable_law·impact_map 필수] 법령명 (예: '민법', '도로교통법') | |
| deepScan | No | [cite_check] 후속 인용 상위 판례 본문 정밀 스캔 (기본 true, false면 빠르지만 변경·폐기 감지 생략) | |
| caseNumber | No | [cite_check 필수] 사건번호 (예: '2013다61381', 문장 포함 가능) | |
| maxCitations | No | [verify_citations] 검증할 최대 인용 개수 (기본 15, 많을수록 느림) | |
| includeMermaid | No | [impact_map] mermaid 그래프 코드 출력 (기본 true) | |
| includeOrdinances | No | [impact_map] 자치법규 인용 검색 포함 (기본 true, false면 전국 조례 팬아웃 생략) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior. The description adds valuable behavior beyond that: DB cross-verification against the Ministry of Legislation, distinction between impossible and unconfirmed cases, change/repeal detection for case citations, temporal statute versioning, and mermaid graph output.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but well-organized: it front-loads the tool's general purpose, then uses separators to define each mode with its required inputs. Every segment carries load-bearing information; there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema, the description explains what each mode produces: verified/existence classification, subsequent-case tracing with change/repeal detection, applicable law version with transitional provisions, and reverse citation graph with mermaid code. Together with the fully described 11-parameter schema, this gives an agent enough context to call the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds meaningful conditional mapping that the schema does not: which parameters are mandatory per mode, how the jo parameter accepts both natural-language phrases and 6-digit codes, and what each mode requires. This is real added value over the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description is explicit and specific: it identifies legal_analysis as an integrated verification/analysis tool with four concrete modes (verify_citations, cite_check, applicable_law, impact_map), each naming its target resource and output. It is clearly distinguishable from sibling search/get/retrieval tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Each mode gives a scenario and the required parameters — e.g., verify_citations for existing legal citations in text, cite_check for case-viability, applicable_law for version-at-the-time analysis, and impact_map for reverse citation graphs. What prevents a 5 is that it never explicitly names the sibling alternatives or states when not to use them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
legal_researchARead-onlyIdempotent
Korean-law-mcp — [⛓리서치] 다단계 법령 리서치 통합 — 여러 API를 병렬로 엮는 복합 질문 전용. task: full_research=도메인·법령명 불명확한 자연어 질문 폴백(기본값, 예 '음주운전 처벌 기준') | law_system=법률·시행령·시행규칙 3단+위임+별표(예 '관세법 체계') | action_basis=처분·허가의 법적 근거+해석례+판례+행심(예 '영업정지 근거') | dispute_prep=불복·소송 준비, 판례+심판례+도메인 결정례(예 '과세처분 불복') | amendment_track=개정 이력+신구대조+연혁(예 '2023년 개정 뭐 바뀜') | ordinance_compare=조례 전국 비교+상위법 적합성(예 '서울시 주차 조례') | procedure_detail=절차·수수료·별표서식(예 '건축허가 절차') | document_review=계약서·약관 조항 리스크+근거법령(text 필수). scenario(선택): 확장 시나리오 — time_travel(두 시점 본문 diff)·timeline·penalty·action_plan·delegation·impact·compliance·customs·manual. 미지정 시 쿼리에서 자동 감지되며, task별 호환 조합은 scenario 파라미터 설명 참조. 단일 조회로 답이 되면 search_law/get_law_text 쓸 것.
| Name | Required | Description | Default |
|---|---|---|---|
| mst | No | [amendment_track] 법령일련번호 (알고 있으면) | |
| task | No | 리서치 유형 (도구 설명의 task 표 참조). 미지정 시 full_research | full_research |
| text | No | [document_review 전용·필수] 검토할 계약서/약관 전문 텍스트 | |
| lawId | No | [amendment_track] 법령ID (알고 있으면) | |
| query | No | 자연어 질문/법령명/키워드 (예: '음주운전 처벌 기준', '관세법 체계'). document_review 외 모든 task에서 필수 | |
| domain | No | [dispute_prep] 전문 분야 (tax=조세심판, labor=노동위, privacy=개인정보위, competition=공정위). 미지정 시 자동 감지 | |
| toDate | No | [time_travel] 비교 종료 시점 YYYYMMDD | |
| articles | No | [law_system] 함께 조회할 조문 번호 (예: ['제38조']) | |
| fromDate | No | [time_travel] 비교 시작 시점 YYYYMMDD | |
| scenario | No | 확장 시나리오. 미지정 시 쿼리에서 자동 감지. task별 호환: law_system=delegation·impact | action_basis=penalty | amendment_track=timeline·time_travel | ordinance_compare=compliance | full_research=customs·action_plan | procedure_detail=manual | |
| parentLaw | No | [ordinance_compare] 상위 법령명. 미지정 시 자동 검색 | |
| maxClauses | No | [document_review] 최대 분석 조항 수 (기본 15) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already carry the full safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false, openWorldHint=true), lowering the burden. The description does add genuinely useful orchestration context — parallel API chaining, automatic scenario/domain detection when unspecified, and the document_review text requirement. But it doesn't disclose richer runtime behavior such as latency, number of sub-calls, or rate-limit implications of the parallel execution. Moderate value over a rich annotation set.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but every section earns its place: purpose is front-loaded in the first clause, followed by a compact task table and scenario routing. For a 12-parameter, 8-task, 9-scenario tool this density is justified, not padding. Minor deduction for the encyclopedic listing style, which sacrifices scannability slightly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given high complexity (12 params, 3 enums, 8 tasks, 9 scenarios) and the absence of an output schema, the description covers a lot: task semantics, scenario compatibility, auto-detection behavior, and fallback routing. It does not describe the response/return shape, but with no output schema and a research-category tool this is a tolerable gap. Comprehensive for its complexity tier.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with every one of the 12 parameters already described in the schema including enums with examples, patterns (YYYYMMDD), and conditional requirements (document_review requires text). The description complements this by cross-referencing task-to-scenario compatibility and default values, but most semantic weight is already in the schema. Baseline 3 is appropriate since the description adds only marginal contextual value over the structured fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource: it is a Korean-law MCP multi-stage research tool that chains multiple APIs in parallel for complex questions. It enumerates 8 distinct task types with concrete examples, and explicitly differentiates from siblings by telling agents to use search_law/get_law_text for single-query answers. An agent can clearly tell this apart from the sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit routing guidance: use this only for composite/complex questions ('복합 질문 전용'), and states the exclusion condition — if a single search suffices, use search_law/get_law_text instead. Each task type carries a usage example, and the incompatible/when-to-avoid signals are explicit rather than implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ordinance_radarARead-onlyIdempotent
Korean-law-mcp — [자치법규] 조례 정비 레이더 — 조례가 인용한 근거 상위법령(법률/시행령/시행규칙)을 본문에서 추출하고, 각 상위법의 현행 시행일과 조례 시행일을 대조해 '상위법이 조례 시행 이후 개정됨 → 정비 검토 대상'을 자동 플래그. 조례 담당 공무원의 상위법 개정 추적·조례 정비 판단용. ordinSeq(또는 id)나 ordinanceName 중 하나 지정.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | ordinSeq 별칭 — 힌트가 id=로 안내하는 경우 대응 | |
| query | No | ordinanceName 별칭 — 자연어 조례명으로 검색 (search_law 등 다른 도구와 규약 통일) | |
| ordinSeq | No | 자치법규 일련번호 (search_ordinance 결과의 [번호]) | |
| ordinanceName | No | 자치법규명 — 지정 시 검색 후 첫 결과 사용 (예: '서울특별시 광진구 주차장 설치 및 관리 조례') |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, which cover the safety profile. The description adds the specific behavioral logic (extracting cited statutes, comparing effective dates, flagging maintenance targets), which goes beyond the annotations. However, it does not disclose potential limitations (e.g., how the analysis handles missing data, or whether it only works on Korean ordinances), so it provides partial value but not rich behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (about three sentences) and front-loaded with a clear purpose. It avoids repeating schema details and each sentence contributes (purpose, target user, input requirement). It is slightly longer than necessary but not wasteful. The structure effectively communicates the essential information without padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description should at least hint at the return value. It says results are 'automatically flagged' but does not describe the result format (e.g., a list of flagged statutes, a report, or a structured object). It also does not clarify what happens if both ordinSeq and ordinanceName are provided, or if neither is given, which are common edge cases. Given the complexity of the analysis, the description is incomplete in these respects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% — each parameter (id, query, ordinSeq, ordinanceName) has its own description. The description adds a rule beyond the schema: 'ordinSeq(또는 id)나 ordinanceName 중 하나 지정', clarifying that the agent must supply at least one of these two groups, which is not evident from the empty required array. This is a meaningful semantic addition that helps the agent understand how to combine the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('extracts', 'compares', 'flags') applied to a specific resource (ordinances' cited superior statutes), making it clear this is an analysis tool, not a search or retrieval tool. It uniquely combines extraction with date comparison and flagging, which clearly distinguishes it from siblings like search_law or get_law_text. No ambiguity remains about the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it is for ordinance officers tracking superior law amendments and maintenance decisions. It also dictates the input requirement (one of ordinSeq/id or ordinanceName). However, it does not explicitly state when NOT to use this tool or point to specific alternative tools for other scenarios, so it lacks explicit exclusions. The context is clear but alternatives are not named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_decisionsARead-onlyIdempotent
Korean-law-mcp — [통합검색] 18개 도메인(판례·해석례·헌재·행심·조세심판·관세·국세청·공정위·개인정보위·노동위·권익위·소청심사·학칙·공사공단·공공기관·조약·영문법령) 통합 검색. domain으로 선택. 판례 본문까지 필요하면 domain='precedent', options.includeText=true, options.detailLimit=N. 세무 관련 국세청 직접 회신 해석은 domain='nts'.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | 페이지 (기본1) | |
| sort | No | 정렬: lasc/ldes/dasc/ddes/nasc/ndes | |
| query | No | 검색 키워드 | |
| domain | Yes | 도메인 선택 (enum 값 참조) | |
| display | No | 결과 수 (기본20) | |
| options | No | 도메인별 옵션. prec:{court,caseNumber,fromDate,toDate} tax_tribunal:{cls,gana,dpaYd,rslYd} customs:{inq,rpl,gana,explYd} constitutional:{caseNumber} interpretation:{fromDate,toDate} treaty:{cls,natCd,eftYd,concYd} |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint=true, idempotentHint=true, destructiveHint=false) already carry the safety profile, so the bar is low. The description adds genuinely useful behavioral context beyond those: the default search does NOT include decision full text unless options.includeText=true and options.detailLimit=N are supplied — a non-obvious behavioral trait. No contradiction with annotations; a read-only search matches the declared hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but information-efficient: the core purpose (18-domain integrated search) is front-loaded, and the two usage rules (precedent full-text, nts routing) follow compactly. It crams a long domain list, but every element earns its place since it encodes the domain enum, which is otherwise only implicit in the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 6-parameter tool with nested options objects and no output schema, the description handles domain selection and the one critical behavior (includeText/detailLimit) well. However, it never describes return values or result shape, and with no output schema present the description carries that burden entirely. It also omits pagination/default-result semantics beyond what the schema already states.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description rises above baseline by demonstrating real usage patterns for the options object — tying the undocumented option keys includeText and detailLimit to a concrete scenario (full-text precedent retrieval). Since the options schema is a generic propertyNames object with no per-key documentation, the description's example closes a real documentation gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with '[통합검색] 18개 도메인 ... 통합 검색' — a specific verb (통합 검색, integrated search) bound to an explicit resource (18 named legal domains across precedents, rulings, constitutional decisions, tax, treaties, etc.). The explicit enumeration of all 18 domains with 'domain으로 선택' distinguishes it from siblings like search_law and get_decision_text, which handle narrower scopes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides strong internal routing guidance: '판례 본문까지 필요하면 domain='precedent', options.includeText=true, options.detailLimit=N' tells the agent how to request full precedent text, and '세무 관련 국세청 직접 회신 해석은 domain='nts'' disambiguates a tricky domain mapping. It does not, however, state when to prefer this integrated search over sibling tools (e.g., search_law), so cross-tool routing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_lawARead-onlyIdempotent
Korean-law-mcp — [법령검색] 법령명·조례명·행정규칙명 키워드검색 → lawId, mst 획득. 지자체 조례·규칙(자치법규), 훈령·예규·고시(행정규칙)도 검색 — 0건 시 자치법규/행정규칙으로 자동 폴백(예: '광진구 복무조례', '외국환거래규정'). 약칭 자동변환. 제명변경·시행예정 개정 자동 병기. 폐지된 법령·행정규칙은 폐지 사실과 후속(통합) 규정을 자동 안내. 법령·조례·행정규칙 조회 전 식별자 확보용.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | 검색할 법령명 (예: '관세법', 'fta특례법', '화관법') | |
| display | No | 최대 결과 개수 (기본 50 — 짧은 법령명 정확매칭 누락 방지) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description correctly does not repeat the safety profile. It adds valuable behavioral nuance beyond annotations: automatic fallback to autonomous laws/administrative rules on zero results, automatic conversion of abbreviated names, appending of renamed and pending-effective amendments, and guidance on repealed laws. These details help the agent anticipate behavior without contradicting the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose ('[법령검색] 법령명·조례명·행정규칙명 키워드검색 → lawId, mst 획득') and then provides relevant behavioral details in a structured, readable manner. It is relatively compact given the amount of behavioral nuance conveyed. Some sentences could be tightened, but it remains efficient and well-organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with no output schema, the description covers key aspects: what it returns (lawId, mst), the types of legal texts covered, fallback behavior, abbreviation handling, and handling of repealed laws. It does not explicitly describe the output format (e.g., list vs. single result) or error conditions, but the display parameter hints at a list of results. Given the tool's complexity and the presence of rich annotations, the description is sufficiently complete for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (both 'query' and 'display' are documented in the schema). The description itself does not add much beyond the schema: it mentions the query searches law names, but the schema already says that. The display parameter is not mentioned in the description. Since the schema fully covers parameter meaning, a baseline score of 3 is appropriate; the description adds no extra semantic value beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that this tool performs keyword searches for law names, ordinance names, and administrative rule names to obtain the identifiers lawId and mst. It explicitly frames itself as a precursor step ('before querying laws/ordinances/administrative rules to obtain identifiers'), which distinguishes it from siblings like get_law_text or legal_analysis. The verb 'search' and resource are specific and the purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear contextual guidance: it is meant to be used before querying laws, ordinances, or administrative rules to obtain identifiers. It also mentions automatic fallback behavior when zero results occur, which helps agents understand what to expect. However, it does not explicitly name alternative tools or state when NOT to use this tool, so it falls slightly short of a perfect 5.
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.
10 tool updates
v4.12.1- First observed
discover_tools - First observed
execute_tool - First observed
get_annexes - First observed
get_decision_text - First observed
get_law_text - First observed
legal_analysis - First observed
legal_research - First observed
ordinance_radar - First observed
search_decisions - First observed
search_law
TDQS
Scored across 10 tools
Each tool targets a distinct purpose: search_law finds identifiers, get_law_text retrieves text, ordinance_radar checks ordinance alignment, get_annexes extracts annexes, legal_research handles complex multi-step queries, legal_analysis does verification, discover_tools/execute_tool are meta, search_decisions searches decisions, get_decision_text retrieves decision text. No overlap or ambiguity.
Most tools follow a clear verb_noun pattern in snake_case (search_law, get_law_text, get_annexes, search_decisions, get_decision_text, discover_tools, execute_tool). A few (legal_research, legal_analysis, ordinance_radar) are noun-based rather than verb-based, creating a slight stylistic inconsistency but still readable and predictable.
10 tools is well-suited for a legal research server. It covers core search/retrieval, specialized analysis, meta tools for extending capabilities, and a unified decision search—all essential without being excessive. Each tool adds distinct functionality.
The tool set provides comprehensive coverage for legal research: law search/text/annexes, ordinance compliance, multi-domain decision search/retrieval, citation verification, and meta tools to access 80+ specialized tools. Missing operations are covered via legal_research scenarios and discover_tools, leaving no obvious gaps.
Maintenance
Related MCP Connectors
Korean fact-verification tools for AI agents: business registration, address, DART, apt prices, laws
LawOracle — 20 legal AI tools: case law search, contracts, EU regulations, citation graph.
Resolve, search and verify legal citations against the official sources, with provenance.
Search U.S. case law, fetch opinions, and ask matter-aware legal questions over your documents.
Related MCP Servers
- FlicenseNot gradedqualityDmaintenanceEnables real-time search and analysis of Korean laws, legal precedents, and administrative rules through the National Law Information Center Open API, allowing AI agents to access official legal information for contract review, compliance, and legal research.75-
- AlicenseNot gradedqualityDmaintenanceEnables AI assistants to search, retrieve, and analyze South Korean legal documents including statutes, precedents, constitutional decisions, and administrative rulings via the Ministry of Government Legislation Open API. Provides 89 specialized tools with features like legal abbreviation auto-recognition, annex extraction, and complex research chain workflows.MIT
- AlicenseNot gradedqualityDmaintenanceIntegrates 132 tools from the Korean Ministry of Legislation OPEN API to provide comprehensive access to Korean legal documents, including statutes, precedents, treaties, administrative rules, and local ordinances.10MIT
- AlicenseNot gradedqualityCmaintenanceProvides 17 tools for accessing Korean statutes, precedents, and administrative rules via the National Law Information Center API, with LLM hallucination prevention, citation verification, impact graphs, and time-travel diff.2,938 npmMIT

