mcp-jp-corporate-id

mcp-jp-corporate-id

日语版请点击此处

一个 MCP（Model Context Protocol）服务，用于验证和规范化日本的 法人番号（houjin bangou）和合格发票开具者注册号码，并对常见书写形式变体中的公司名称进行规范化和匹配。

完全不使用网络访问（v1 不会调用外部 API）。所有检查均通过代码中内置的公式和字典数据完成。

请先阅读

• 此工具只验证数字和名称的格式。它不会验证某家公司是否实际存在，也不会验证发票注册当前是否有效。 如需进行实际验证，请务必直接查询国税厅的官方网站：
  • 法人番号公表网站
  • 适格发票开具者公表网站
• 切勿输入日本个人番号（My Number）。 公司注册号码（12 位）和个人 My Number（12 位）长度相同，此工具无法区分输入的是哪种号码。calculate_check_digit 的响应始终会包含相关警告。
• 此服务绝不记录请求输入，验证错误消息也绝不会回显提交的原始号码。

工具（共 7 个）

工具	描述
validate_corporate_number	验证 13 位法人番号的校验位
calculate_check_digit	根据 12 位公司注册号码计算校验位，并推导出 13 位法人番号
validate_invoice_number	验证合格发票注册号码（“T” + 13 位数字）
parse_corporate_number	拆解法人番号的结构（类别、登记机关代码、组织类型、流水号）
normalize_company_name	规范化公司名称的写法（株式会社/(株)/㈱ 等、前后缀位置、旧字体形式）
generate_matching_key	生成用于公司名称去重和匹配的规范化键
compare_company_names	判断两个公司名称是否可能指向同一实体（只有在严格且范围狭窄的条件下才会返回 likely_different；无法判断时返回“unknown”）

每个工具的响应都会包含其逻辑所依据的主要来源（sources）。

1. validate_corporate_number

验证 13 位法人番号的校验位是否正确。接受全角数字、连字符和空白字符，并会在验证前进行规范化。如果规范化后的长度不是 13 位，或校验位不匹配，工具会返回 valid: false，而不会抛出异常。

2. calculate_check_digit

根据 12 位公司注册号码（依据商业登记记录分配）计算校验位，并推导出 13 位法人番号。如果规范化后的输入不恰好为 12 位，工具会抛出异常（不会猜测或在前面补零）。

注意：12 位号码既可能是 My Number（个人号码），也可能是公司注册号码。每个响应都会包含 caution 字段，提醒调用方切勿提交 My Number。如果登记机关代码部分超出主要来源确认的常见范围（0100–5000），则会添加 note。

3. validate_invoice_number

验证合格发票登记号（“T” + 13 位数字）。

• 对于由法人持有的号码（“T” + 法人编号），会通过数学计算验证校验位；若匹配，则返回 entityType: "corporate"。
• 由个体经营者和非法人组织持有的号码，是国税厅另行颁发的 13 位数字，与个人编号和任何法人编号均不重叠。**在所审查的主要来源中，未能确认这类号码的校验位算法是否有公开文档说明。**如果号码不符合法人编号的校验位公式，该工具会返回 entityType: "individual_or_other"，仅验证格式，并明确说明此类号码无法进行数学验证。
• 如果输入甚至不符合“T” + 13 位数字的格式，则返回 formatValid: false（而非抛出异常）。

4. parse_corporate_number

验证 13 位法人编号的校验位，然后解析其 12 位基础编号的结构。

• category：national_organ_legislative / national_organ_administrative / national_organ_judicial / local_government / registered_corporation / unregistered_corporation_or_unincorporated_association / unused_range
• 对于 registered_corporation，返回 registryOfficeCode（4 位）、organizationTypeCode（原始 2 位）和 serialNumber（6 位）。
• 在所审查的主要来源中，未能确认 2 位组织类型代码与实际法人形式（股份公司、有限责任公司等）之间的映射是否有文档说明的数字代码表（《商业登记规则》定义了三种文本类别，但所审查的条文未列出对应的数字代码）。因此，该工具只返回原始 2 位代码，不附带标签——详见下文“无法验证的项目”。

5. normalize_company_name

规范化公司名称的写法，并将去除法人形式后的“主体名称”分离出来。

• 转换主要法人形式的写法（株式会社/(株)/（株）/㈱ 等）。
• 判断法人形式是作为前缀（株式会社○○）还是后缀（○○株式会社）出现。
• 规范化全角/半角字符，以及一组经过筛选的旧字形/变体汉字（例如 髙→高、﨑→崎）。

词典限制：仅涵盖主要法人形式和变体字符。它并未囊括所有日本法人形式或写法变体；词典中未收录的内容无法识别，并会原样保留在主体名称中。

6. generate_matching_key

内部使用 normalize_company_name，并移除主体名称中的空白，以生成用于去重的匹配键。

7. compare_company_names

规范化两个名称并进行比较，返回 verdict、confidence 级别和 reasons。

设计：判定结果和原因均由同一份结构化证据自动生成

该工具不会分别手动编写判定结果／置信度逻辑和说明文本，而是从单个结构化对象 evidence 中同时生成两者，并在响应中原样包含该对象：

字段	含义
scriptMismatch	名称主体的字符类型差异是否大到无法进行有意义的比较
bodyMatch	名称主体之间的关系："exact"（完全匹配）、"partial"（部分匹配）或 "none"（不匹配）
commonTokens	实际找到的共同子字符串
labelMatch	公司类型标记（株式会社／合同会社等）是否匹配（不适用时为 null）
positionMatch	前缀／后缀位置是否匹配（不适用时为 null）
distinguishing	支撑 likely_different 判定的共同词元 + 区分元素组合（其他情况为 null）

判定逻辑（evidence → verdict／confidence）和说明逻辑（evidence → reasons）是两个独立函数，且都只读取同一个 evidence 对象。更改判定规则会自动使说明保持同步，因此从结构上来说，不可能出现置信度很高的判定，但 reasons／notes 却写着“无法确定”的情况。

字符类型不匹配保护（在任何评分之前运行）

如果两个名称主体的字符类型差异很大——一方仅由拉丁字母组成，另一方则包含日语字符（平假名／片假名／汉字）——那么原则上将它们作为字符串进行比较毫无意义。例如，“日本電気株式会社”（Nippon Electric Company）和“NEC”指的是同一家公司，但两者的名称主体字符串完全没有共同字符（“NEC”是无法通过字符串比较检测到的缩写）。检测到此类字符类型不匹配时，工具会立即返回 unknown（confidence: "low"），而不会尝试评分。

返回 likely_different 的条件

只有在以下所有条件均满足时，才会返回 likely_different：

• 两个名称主体具有至少 2 个字符的共同前缀或后缀（“共同词元”）。
• 双方剩余的非共同部分（“区分元素”）均至少有 2 个字符，且两个区分元素不同。

示例：“東京電力”（Tokyo Electric Power）与“東北電力”（Tohoku Electric Power）——它们具有共同后缀“電力”（“Electric Power”），而“東京”（Tokyo）和“東北”（Tohoku）则是区分元素。由于两者遵循相同的命名模式，但在明确标识地区的元素上存在差异，该工具会将它们视为很可能是不同的公司。

如果不满足此条件（完全没有共同部分，或一个名称只是另一个名称的子字符串），就没有证据表明它们是不同的公司，因此工具始终返回 unknown。两个字符串仅仅不匹配或没有重叠，本身绝不能作为返回 likely_different 的依据——字符串没有重叠并不能证明它们是不同的实体。reasons 文本会区分“完全没有共同部分”和“仅部分匹配”，而不会对两者使用相同的措辞。

置信度上限为 medium，并且在设计上始终与判定结果一致

confidence 只有两个可能的值："medium" 和 "low"。"high" 已被移除。 自 2006 年 《公司法》废除了类似商号限制后，只要总公司所在地不同，两家互不相关的公司就可以登记为相同名称。因此，原则上，仅凭商号匹配绝不能支撑较高置信度（"high"）。

在 TypeScript 类型层面，confidence 的有效值受 verdict 限制：unknown 只能对应 confidence: "low"，而 likely_same 和 likely_different 只能对应 confidence: "medium"。从结构上来说，此工具不可能同时返回 unknown 和 confidence: "medium"。

此工具绝不会“通过降低置信度来模棱两可”。 对于本质上无法确定的情况——例如下文所述的前缀／后缀位置不匹配——工具会将 verdict 本身设为 unknown，而不是降低 likely_same 的置信度。对于仅依据 verdict 进行分支处理的调用方（例如自动合并所有标记为 likely_same 的批处理任务），这一点很重要：如果歧义只体现在 confidence 中，调用方就会在不知情的情况下忽略歧义。

reasons 始终会具体说明工具得出结论的原因，或无法得出结论的原因（例如文字体系不匹配、没有共同词元、只有部分重叠、公司类型或前缀／后缀位置不匹配、可能存在缩写／英文名称等），并直接根据 evidence 生成。每个响应还会附带一条关于此方法局限性的固定说明：

此工具只会基于写法规范化进行文本比较；无法判断某个缩写、英文名称或昵称是否指向同一实体。要确定实体身份，必须交叉核对法人编号。

此工具能够和不能确定的事项

情况	示例	判定	置信度
主体名称、公司类型以及前后缀位置均匹配	"株式会社サンプル" vs. "㈱サンプル"	likely_same	medium（相同的商号仍可能属于不同公司 — 请交叉核对法人编号）
主体名称和公司类型匹配，但前后缀位置不同（前缀 vs. 后缀）	"株式会社サンプル" vs. "サンプル(株)"	unknown	low（前后缀位置是商号本身的一部分 — 法律上属于不同商号，可能属于不同公司）
主体名称匹配，但公司类型本身不同（株式会社 vs. 合同会社）	"株式会社サンプル" vs. "合同会社サンプル"	unknown	low（组织形式变更 — 例如，股份公司转为 LLC — 会保留相同的法人编号，因此两条记录可能只是同一实体在不同时间点的记录）
字符体系不匹配（一方仅含拉丁字母，另一方含日文）	"日本電気株式会社" vs. "NEC"	unknown	low（评分前触发保护条件）
存在共同常见词元（≥2 个字符），且显著区分元素各自至少有 2 个字符	"東京電力" vs. "東北電力"	likely_different	medium
一个主体名称是另一个的子字符串（不符合区分元素条件）	"株式会社サンプル" vs. "株式会社サンプル商事"	unknown	low
完全没有共同词元	"株式会社あいうえお" vs. "株式会社かきくけこ"	unknown	low

此工具返回 likely_same（medium）的唯一情况，是主体名称、公司类型和前后缀位置均匹配。 即使主体名称看似匹配，只要前后缀位置或公司类型不同，就仍有可能是不同实体，原则上无法排除这种可能，因此工具会返回 unknown。只有满足上述严格的“共同模式 + 明显不同的标识符”条件时，才会返回 likely_different。其他所有情况均为 unknown。unknown 不表示“很可能不同”，而表示“此方法无法确定”。如需确定身份，请获取各公司的法人编号，并使用 validate_corporate_number 或类似方式进行交叉核对。

主要来源

只有在直接查阅并阅读以下主要来源后，才实现了号码验证逻辑 （最后检查日期：2026-07-29）：

• 校验位公式：NTA 法人编号网站，“校验位计算” https://www.houjin-bangou.nta.go.jp/documents/checkdigit.pdf
• 法人编号（13 位）结构：NTA 法人编号网站，“法人编号的结构” https://www.houjin-bangou.nta.go.jp/documents/houjinbangounokousei.pdf
• 法人编号制度概述（哪些对象会被分配编号；国家机关、地方政府、已登记法人等类别）：NTA 法人编号管理办公室，“关于法人编号”（2026 年 6 月版） https://www.houjin-bangou.nta.go.jp/setsumei/pamphlet/images/houjinbangou_gaiyou.pdf
• 《行政手续中用于识别特定个人的号码的使用法》第 39 条： https://laws.e-gov.go.jp/law/425AC0000000027
• 该法令的内阁令（2014 年内阁令第 155 号）第 35 条（法人编号结构）和第 36 条（向国家机关分配编号的单位）： https://laws.e-gov.go.jp/law/426CO0000000155
• 《法人编号分配规程》（2014 年财政部规程第 70 号）第 2 条（校验位公式）和第 3 条（未登记实体的基础编号）： https://laws.e-gov.go.jp/law/426M60000040070
• 《商业登记规则》（1964 年法务省规程第 23 号）第 1-2 条（公司登记编号的记录）： https://laws.e-gov.go.jp/law/339M50000010023
• 发票登记编号结构：NTA 合格发票开具方公示网站，“关于登记编号” https://www.invoice-kohyo.nta.go.jp/about-toroku/index.html

无法核实的项目（如实披露）

• 公司登记号码中两位数“组织类型”部分的具体数字代码表（例如，哪些数字代表“股份公司”与“有限责任公司”）无法确认。《商业登记规则》第 1-2 条定义了三个文字类别（“股份公司”；“普通合伙企业／有限合伙企业、有限责任公司及外国公司”；“商号使用者等”），但经审查的法规文本并未列出这些类别对应的数字代码，而网上找到的二手来源（博客文章等）彼此说法不一。因此，parse_corporate_number 只返回原始的两位数代码，不附带解释标签。
• 无法确认地方政府子代码（“20”／“30”）具体区分的对象（例如，都道府县与市町村）。
• 向个体经营者和非公司法人团体发放的 13 位发票登记号码的校验位算法，无法确认是否有公开文档记录。因此，这类号码只进行格式验证，不进行数学意义上的校验位验证。
• 公司形式和旧字形字典并非穷尽所有法定定义，而是实用的手工整理集合，涵盖常见写法。

设置

1. 前提条件

• Node.js（建议使用 LTS 版本）

node --version

2. 安装依赖项

npm install

3. 构建

npm run build

成功后，将创建 build/index.js。

在 Claude Desktop 中使用

将以下内容添加到 Claude Desktop 配置文件（claude_desktop_config.json）中：

{
  "mcpServers": {
    "jp-corporate-id": {
      "command": "node",
      "args": ["/absolute/path/to/mcp-jp-corporate-id/build/index.js"]
    }
  }
}

配置文件位置：

• Windows：%APPDATA%\Claude\claude_desktop_config.json
• macOS：~/Library/Application Support/Claude/claude_desktop_config.json

之后重启 Claude Desktop，即可使用 validate_corporate_number 等工具。

运行测试

npm test

所有测试都应显示 ✔。

项目布局

mcp-jp-corporate-id/
├── src/
│   ├── sources.ts          … list of cited primary sources
│   ├── errors.ts            … shared validation-error class
│   ├── normalize.ts         … full/half-width, hyphen, etc. input normalization
│   ├── checkDigit.ts        … the check-digit formula
│   ├── corporateNumber.ts   … 12-digit base-number structure parsing
│   ├── corporateIdCalc.ts   … logic for tools 1-4
│   ├── companyNameData.ts   … corporate-form dictionary, legacy-kanji map
│   ├── companyName.ts       … logic for tools 5-7
│   └── index.ts             … MCP server entry point (registers the 7 tools)
├── tests/                   … automated tests (node:test)
├── package.json
├── tsconfig.json
├── LICENSE
├── README.md                … this file
└── README.ja.md             … Japanese version

相关工具

同一作者开发的其他服务：

• mcp-jp-paid-leave — 用于计算《日本劳动基准法》规定的法定带薪年假的 MCP 服务
• mcp-jp-calendar — 用于查询日本营业日、法定节假日、五十日结算日和财季的 MCP 服务

许可证

MIT