korean-law-mcp系统架构深度解析：99个内部工具如何压缩成10个曝光工具，AI上下文成本直降52%-创锋一号

korean-law-mcp系统架构深度解析：99个内部工具如何压缩成10个曝光工具，AI上下文成本直降52%

【免费下载链接】korean-law-mcp법제처 국가법령정보를 LLM에서 바로 조회하는 MCP 서버. 법령·판례·조례 검색과 인용 검증 | MCP server for Korean law — search statutes, precedents, and ordinances, and verify citations项目地址: https://gitcode.com/gh_mirrors/ko/korean-law-mcp

korean-law-mcp 是一个韩国法律 MCP 服务器，它把韩国法制处（国家法令信息）的法令、判例、条例、行政规则等官方数据接口，包装成 AI 助手可直接调用的工具。这个项目内部其实有99 个工具，但每次只向 AI 客户端"曝光"其中10 个——这一设计让 AI 每次会话加载的工具列表上下文成本直降 52%（约 6,000 → 约 2,900 个 token）。今天这篇文章就用大白话拆解：为什么 AI 工具少即是多？99 到 10 是怎么压缩的？没曝光的功能又去哪里了？

一、先搞清楚：为什么"工具数量"会影响AI成本？

很多新手不知道，MCP 服务器接入 AI（如 Claude、ChatGPT）时，客户端会先调用一次ListTools，把所有工具的名称 + 描述 + 参数结构读进 AI 的上下文窗口。

这意味着：

工具越多、描述越长 → 每次会话固定消耗的 token 越多（钱也越多）
AI 要在一堆工具里"挑工具"，候选越多，选错的概率越高

korean-law-mcp 覆盖法令、判例、解释例、关税、条约、学校规则……官方 API 就有 42 个端点，最初曝光的工具一度有 19 个，工具列表上下文高达约15.1KB。开发者在 v4.4.0 做了一个关键架构决策：曝光 10 个，隐藏 89 个。

二、核心架构：三层"漏斗"设计

整个压缩逻辑可以用一个漏斗来理解（详见官方架构文档 docs/ARCHITECTURE.md）：

99 个内部工具（allTools[] 全部注册） │ 按 V3_EXPOSED 名单过滤 ▼ 10 个曝光工具（ListTools 只看到这些） │ 未命中？走两跳通道 ▼ discover_tools（按意图找工具）→ execute_tool（代理执行）

第 1 层：注册中心——99 个工具全都要

所有工具统一注册在 src/tool-registry.ts 的allTools[]数组里，每个工具包含名称、描述、Zod 参数校验模式和执行函数。注意：隐藏 ≠ 删除，89 个"隐身"工具依然完整可用。

第 2 层：曝光名单——一个 Set 决定一切

到底曝光谁？答案只有一个地方：src/lib/tool-profiles.ts 里的V3_EXPOSED名单。注册中心在生成工具列表时执行一行过滤（src/tool-registry.ts）：

tools/list响应只返回这 10 个工具，其余 89 个的描述一个字都不会发给 AI
名单集中维护在单一源文件，避免"过滤逻辑"和"引导文案"两处各持一份名单导致不一致

第 3 层：两跳通道——没曝光的功能随时找得到

这是架构里最巧妙的一环。如果用户问"帮我查一下关税解释例"（一个没曝光的工具能力），AI 不会干等，而是走 src/tools/meta-tools.ts 提供的两个元工具：

discover_tools：传入自然语言意图（如"关税"），它在 src/lib/tool-discovery.ts 中按"别名精确匹配 > 分类名 > 描述模糊匹配"分级检索，还内置了"税务审议院""韩国反垄断委员会"等实务叫法的别名表
execute_tool：拿到工具名后代为执行，参数照样走 Zod 严格校验

匹配结果还被刻意限制为最多 5 个分类（实测把一次响应的平均大小压低了 67%），超出部分会明确告知"另有 N 个分类被省略"，绝不静默截断。

三、曝光的 10 个工具都是谁？怎么选出来的？

工具	定位	压缩了什么
`legal_research`	多步骤法务研究总入口	吞并 8 个`chain_*`链式工具，用`task`参数区分
`legal_analysis`	精密分析总入口	吞并 4 个杀手级功能（引用验证/判例存废/行为时法/影响图谱），用`mode`参数区分
`search_law`/`get_law_text`	法令搜索 / 条文全文	最常用的高频查询
`get_annexes`	别表（附表）查询	曾因走两跳浪费 15 秒而被提名为曝光
`search_decisions`/`get_decision_text`	18 个裁决领域统一检索/全文	判例、宪法法院、税务审议院……一次覆盖
`ordinance_radar`	条例整理雷达	地方公务员追踪上位法改动的刚需
`discover_tools`/`execute_tool`	两跳通道的入口与执行器	89 个隐身工具的总通道

曝光标准写在代码注释里（src/lib/tool-profiles.ts），总结起来就三条：高频直达的、链式工具经常回退调用的终点、走两跳平均要多花 5 秒以上的——才配占一个曝光名额。

其中legal_research的 8 种任务模式（全面研究、法体系、执法依据、抗辩准备、修法追踪、条例比较、程序细则、文档审阅）直接内联在 src/tools/legal-research.ts 中，连"用户把scenario值误填到task参数"这种 AI 常见手误都会被自动纠正。

四、52% 是怎么省下来的？

v4.4.0 的实测量化数据（CHANGELOG.md）：

工具列表上下文：约 15.1KB → 约 7.2KB（≈6,000 → ≈2,900 token），52% 削减
8 个chain_*工具 → 1 个legal_research（task 参数）
4 个分析工具 → 1 个legal_analysis（mode 参数）

而且这个"压缩"是无损的：

旧工具名全部保留在allTools里，老客户端直接按旧名调用照常工作（向下兼容）
execute_tool通道让新客户端也能按旧名触达 89 个隐身工具
连tools/list的响应都在首次请求时构建好缓存复用，stateless HTTP 模式下不再每次重复转换 Zod → JSON Schema

配合其他优化——判例响应压缩再省 74% token、批量条文一次 API 调用、LRU 缓存命中率约 82%——整套"省 token"的组合拳才成立。

五、这套设计对写 MCP 服务器的人有什么启发？

工具列表是"常驻税"：每多一个工具描述，每个会话都要为此付费，暴露要克制
用参数代替工具：同质工具合并为一个入口 +task/mode枚举，是压缩上下文最直接的杠杆
隐藏不等于移除：保留全量注册 + 发现/代理两跳通道，功能一个不少
单一事实源：曝光名单、别名表、分类表都集中维护，避免多份拷贝各自过期
截断必须出声：匹配结果超限时要告诉调用方"还有 N 条没显示"，静默截断等于制造幻觉

六、相关源码与文档导航

想了解	看这里
整体架构图与执行预算	docs/ARCHITECTURE.md
99 个工具注册与输出门禁	src/tool-registry.ts
曝光名单与工具分类别名	src/lib/tool-profiles.ts
两跳发现/执行机制	src/tools/meta-tools.ts
意图匹配与分级检索	src/lib/tool-discovery.ts
8 合 1 的链式研究入口	src/tools/legal-research.ts
52% 削减的完整变更说明	CHANGELOG.md

一句话总结：korean-law-mcp 的精髓不是"多"，而是该藏的 89 个工具一个不少、该省的每 1 个 token 都不浪费——这正是它敢把法制处 42 个官方 API 全部收进 10 个曝光工具背后又敢于承诺 52% 上下文削减的底气。

创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考

企业官网建设流程全解析