Japan Corporate Number

@pipeworx/japan-corporate-number

日本国税厅（国税庁）的法人编号登记册 （法人番号公表サイト）——涵盖自 2015-10-05 起签发的所有 13 位法人番号：法定名称、片假名读音，以及国税厅持有时提供的英文名称、地址、法人类别（股份公司、有限责任公司、政府机构、非营利组织等）和状态（正常存续，或已注销／合并，并附国税厅公布的说明）。截至 2026-09-30 的版本共收录 5,837,980 个实体。

本项目是 Pipeworx 的一部分——一个将 AI Agent 接入 1882+ 个实时数据源的 MCP 网关。这是独立的非官方集成，与上游提供方无关联、未获其认可，也非由其发布。

gBizINFO（mcps/gbizinfo，经产省）是不同的数据源，会以相同的法人编号关联更丰富的政府记录——采购、补贴、专利、财务数据等，但覆盖范围有限。本项目提供完整的基础登记册（来自国税厅，涵盖所有登记编号）；取得编号后，可使用 gbizinfo 查询政府记录详情。

工具

• jp_corporate_number(number) — 按 13 位法人番号查询单个实体。 查询前会验证校验位（见下文“校验位”），对于格式错误的编号、 校验位未通过的编号，或格式正确但未收录在登记册中的编号，均会返回 带有 reason 的 found: false；绝不会返回空对象。
• jp_company_search(name, prefecture?, limit?) — 按日文名称搜索 （子串匹配；株式会社、(株)、㈱、有限会社、合同会社等可作为前缀或 后缀接受），也可按国税厅为部分实体公布的英文名称／片假名读音搜索， 或按 GLEIF 为持有 LEI 的实体登记的英文名称搜索。 prefecture 可接受日文名称、英文名称或 2 位代码。 结果包含 lei 和 matched_via（register_name 或 gleif_lei_bridge）；响应中包含 name_bridge.status。

身份验证

无需密钥。网关会直接提供数据——调用方无需提供密钥，也不需要任何供应商密钥（该登记册以月度文件形式发布，而非实时 API）。这些工具只能通过托管网关使用：独立构建版本没有可读取的数据，会明确报错（StoreUnavailableError）说明这一点，绝不会返回空结果。

数据来源和再利用条款

• 日本国税厅（国税庁），法人番号公表サイト——每月发布的全国法人编号登记册。Pipeworx 会加载每月版本；每个响应中的 data_as_of 表示所加载版本的日期。获取数据的方式（以及已验证的列映射）仅记录在 scripts/japan-corporate-number/README.md 中，该文件不会发布——CLAUDE.md 第 9b 步（a4c024647）：注明来源，但绝不提及源文件／路径／字段名称。
• 使用条款（摘录自国税厅使用条款页面的日本公共数据许可 v1.0）：必须注明来源（“本コンテンツを利用する際は出典を記載してください”——使用本内容时须注明来源）；对数据进行编辑／衍生处理时，必须将此事与来源标注分别说明；绝不得将编辑／处理后的数据呈现得仿佛是政府自行制作的（“編集・加工等した情報を、あたかも国（又は府省等）が作成したかのような 態様で公表・利用することは禁止します”）。除此之外，许可较为宽松——不限制商业再利用和再分发。本 README 和每个工具响应均注明来源及 data_as_of；数据归国税厅所有，由 Pipeworx 重新整理，绝不将其呈现为政府制作。

法人类别代码（法人種別）

已观察到的完整代码集：101 国家政府机构，201 地方政府，301 株式会社（股份公司），302 合同会社 （相当于有限责任公司），303 合名会社，304 合资会社，305 其他登记法人（如社团法人／财团法人），399 其他，499 外国公司等。标签是对国税厅标准代码表的尽力英文释义；始终会同时返回原始代码。

状态 — 一个真正的正确性陷阱（以及其中的另一个陷阱）

因合并而注销的公司（process_type 71/72，约 31,000 个实体）带有 closure_event_text（一条提及另一方的日语句子），但这些行的 closure_date 和 closure_cause_code 均为 NULL——这两个字段由完全不同的注销 机制填充（主要是 process_type 21，约 784K 行），而这种机制大多没有 closure_event_text。只检查 closure_date 会漏掉所有被合并的实体。

陷阱中的陷阱：closure_event_text 描述的合并可能来自任一方，只有措辞能说明是哪一方。“...を合併”（吸收[另一方]）指的是存续方——该实体继续存在（例如，丰田汽车公司吸收一家子公司）。“...に合併し解散”（合并进入[另一方]并解散）指的是消失的实体。把任何 closure_event_text 都视为已注销是错误的——我们曾发现它将一家仍在运营的活跃公司报告为已注销。status 在设置了 closure_date 时为 closed_or_merged，或者在设置了 closure_event_text 且其中确实包含 解散（“解散”）时也为 closed_or_merged。

校验位

法人番号的首位是对其余 12 位（从最高位开始）计算的校验位，权重依次为 2,1,2,1,...（最高位的基数位权重为 2），将结果相加后对 9 取模，校验位 = 9 - (sum mod 9)。已通过登记库中的真实号码验证（1000012160153、1000013050386、 1000013050394 均通过；朴素的“教科书式”权重 1,2,1,2,... 三个都未通过）。jp_corporate_number 会先验证这一点再进行查询，因此 格式错误或不可能的号码会返回具体的 bad_format / bad_check_digit 原因，而不是简单地返回“未找到”。

“日语和罗马字匹配”——这是什么，又不是什么

GLEIF 名称桥接（fleet #3020）。 NTA 只为 580 万个实体中的 15,352 个发布了英文名称——不包括 Sharp、Sony Group 或 Toyota Motor。因此，每次搜索还会实时调用一次 GLEIF（Global Legal Entity Identifier Foundation）LEI 记录，并筛选日本的数据。对于日本实体，GLEIF 会将其 会社法人等番号 记录在注册机构 RA000412 下；法人番号是在该 12 位号码前加上 NTA 的校验位，因此每条 GLEIF 命中都能通过号码对应到登记库中的一行。在名称层级相同的情况下，桥接匹配的行会排在仅由登记库匹配的行之前，这使 Sharp Corporation 能在 100 多家名称含 シャープ 的公司中排在首位。桥接通过实时代理调用实现（不会复制任何数据），并采用故障开放策略：如果 GLEIF 不可用，搜索会仅根据登记库返回结果，并显示 name_bridge.status: "unavailable"。

jp_company_search 会匹配一个 FTS5 三元组索引，该索引包含日语核心名称（会去除公司后缀，例如“株式会社”/“K.K.”都会被去掉）、英文名称和片假名读音——具体包含该实体的 NTA 实际发布内容。它不是转写工具：如果公司没有登记英文名称/假名读音，那么 NTA 未记录过的罗马字查询将无法找到该公司——下文的 GLEIF 桥接除外。prefecture 会通过一个静态的 47 个都道府县表（src/prefectures.ts）进行解析，因此无论匹配的公司是否登记了英文地址，都可以使用日语名称、英文名称或代码进行查询——若直接按登记库中每家公司自己的 prefecture_en 列筛选，那么对于完全没有英文名称的公司所在都道府县，几乎所有实体都会被悄然漏掉。

FTS5 的三元组分词器按字符而非字节构建窗口：少于 3 个字符的查询不会生成三元组，因此即使它是实际存在的子串，通过 MATCH 也匹配不到任何内容（已验证：相同字符串的 2 字符日语查询通过 FTS 返回 0 行，通过 LIKE 返回 5+ 行）。对于任何少于 3 个字符的查询，jp_company_search 都会回退到普通子串扫描。

刷新和重复项检查说明：请参阅 scripts/japan-corporate-number/README.md（仅供操作人员使用，不会发布）和上文的 gbizinfo。

快速开始

添加到 MCP 客户端（Claude Desktop、Cursor、Windsurf 等）：

{
  "mcpServers": {
    "japan-corporate-number": {
      "url": "https://gateway.pipeworx.io/japan-corporate-number/mcp"
    }
  }
}

此端点实际提供的内容

https://gateway.pipeworx.io/japan-corporate-number/mcp 上的 tools/list 会返回上表中的工具，以及 Pipeworx 的共享元工具——ask_pipeworx、 discover_tools、search_within、remember/recall 和网关范围内的其他工具。因此，你看到的工具数量会多于表格中的数量：目前，单个工具包端点除了列出工具包自身的工具，还会列出大约 30 个共享工具。连接的 initialize 响应会说明确切范围，并且是当天范围的权威依据。

这是有意设计的，并非意外多路复用。元工具可以让限定范围的连接回答此工具包未涵盖的问题——通过 ask_pipeworx 在整个目录中进行路由——无需你再添加第二个 MCP 服务。目前无法挂载不包含这些元工具的工具包端点；如果额外的 schema 占用的上下文比路由带来的价值还多，请连接一次完整网关，而不是连接多个工具包端点。

或者，连接完整的 Pipeworx 网关，直接列出每个工具包的工具，而不只是此工具包的工具：

{
  "mcpServers": {
    "pipeworx": {
      "url": "https://gateway.pipeworx.io/mcp"
    }
  }
}

两个 URL 都会连接到同一个网关和相同的 1882+ 个数据源。唯一的区别是，哪个工具包的工具会被直接列出；无论连接哪个端点，ask_pipeworx 都能访问所有工具。

没有 MCP 客户端？通过 HTTP 调用

curl -X POST https://gateway.pipeworx.io/v1/tools/jp_corporate_number \
  -H 'Content-Type: application/json' \
  -d '{"number":"1000012160153"}'

首次调用无需账号。查看任意工具：GET https://gateway.pipeworx.io/v1/tools/jp_corporate_number。查找工具：使用 {"query":"..."} 向 https://gateway.pipeworx.io/v1/tools/search_packs 发送 POST 请求。

独立运行（无需网关账号）

此软件包也可以作为本地 stdio MCP 服务运行——无需 Pipeworx 账号，也无需经过网关往返：

{
  "mcpServers": {
    "japan-corporate-number": {
      "command": "npx",
      "args": ["-y", "@pipeworx/mcp-japan-corporate-number"]
    }
  }
}

或者直接运行，确认它可以启动：

npx -y @pipeworx/mcp-japan-corporate-number

它通过 stdin/stdout 使用 MCP 协议，并且只针对此工具包的工具响应 initialize/tools/list/tools/call——不包含上述网关连接所添加的任何共享元工具。使用相同的源代码和工具，但没有 ask_pipeworx 路由。

使用 ask_pipeworx

你可以用通俗的语言提问，而不是直接调用工具——此功能既适用于上面的工具包端点，也适用于完整网关：

ask_pipeworx({ question: "your question about Japan Corporate Number data" })

网关会自动选择合适的工具并填入参数。

更多信息

• 文档和指南
• pipeworx.io

许可证

MIT