Gbizinfo

@pipeworx/gbizinfo

日本企业注册信息——以 13 位法人番号（企业编号）为索引的企业资料、政府采购中标信息、补贴、专利、认证、财务信息和职场披露信息。数据来源：gBizINFO，日本经济产业省（METI）。

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

工具

• gbiz_company_search(name?, prefecture?, city?, corporate_type?, has?, capital_min?, capital_max?, employees_min?, employees_max?, founded_year?, limit?, page?, _apiKey) — 查找企业及其法人番号。

• gbiz_company_profile(corporate_number, _apiKey) — 注册资料：法定名称、假名及罗马字形式、地址、代表董事、资本、员工人数、成立日期、业务概述、网站、注销信息。

• gbiz_company_procurement(corporate_number, limit?, _apiKey) — 日本政府采购中标信息：订单日期、标题、金额（日元）、授标部委。

• gbiz_company_subsidies(corporate_number, limit?, _apiKey) — 已获补贴和资助：批准日期、项目、金额、授予部委。

• gbiz_company_records(corporate_number, kind, limit?, _apiKey) — patent、certification、commendation、finance 或 workplace。

  这五种类型的响应结构并不相同。 patent、certification 和 commendation 会以 LIST 形式返回，放在与类型同名的键下，并附带 returned 和 total_on_record 计数。每家公司只有一条 finance 和一条 workplace 记录，因此它们会以 OBJECT 形式返回——finance 放在 finance 下（包括会计准则、财年封面页、management_index 时期序列和 major_shareholders），职场统计则放在 workplace_info 下。这个键名特意与其 workplace 类型不同，因为这是上游返回的名称。对于对象类型，limit 会限制其中嵌套数组的长度，total_on_record 则是按数组分别统计的映射，而非单个数字。

身份验证

自 2026-09-13 起使用平台密钥（fleet #1940）。 网关持有 PLATFORM_GBIZINFO_KEY 并会注入该密钥，因此调用方无需自备密钥。仍接受 _apiKey，供希望使用自有令牌和配额的用户选择。

该工具包最初仅支持 BYOK，故意未设置 platformKeyEnv。因此，在没有密钥时，网关的 keyBlockedTools() 会阻止这些工具参与路由——当工具只能拒绝时，将日企相关问题路由到该工具，不如诚实地返回 no_match。密钥和 platformKeyEnv 在同一次变更中加入，这正是设立此顺序规则的目的（参照 fda-inspections 先例，fleet #617）。

如需使用自有令牌，可在 https://info.gbiz.go.jp/hojin/various_registration/form 免费注册。非日本申请人也可以注册：表单中的利用者区分单选项包括法人担当者（企业用户——需要提供 13 位法人番号、日文企业名称、部门、邮政编码、地址和电话）和个人利用者（个人用户），所需字段仅为电子邮箱、密码、用途和两个同意框。 正是这一区别让 gBizINFO 在 NTA 法人番号 API 不适用的场景下仍可使用——后者的申请流程要求提供日本法人番号，没有个人用户选项。令牌会通过电子邮件发送。

公开的 OpenAPI 文档位于 https://api.info.gbiz.go.jp/hojin/v3/api-docs?group=v2，其中在 info.description 内嵌了一个令牌。同一句日文说明表示，该令牌仅用于在 Swagger 页面上检查行为。开发时可用它查看响应结构，但它不是可随产品发布的凭据，本工具包也不包含它。

值得了解的上游行为

• 缺少令牌时返回 HTTP 500，而非 401。 省略请求头时，gBizINFO 会返回 500 - Internal Server Error.；令牌错误时则会正常返回 401。若直接透传，缺少凭据会被误认为是上游服务故障。这里会将其转换为身份验证拒绝。
• 主机是 api.info.gbiz.go.jp，版本是 v2。 裸域名 info.gbiz.go.jp 对 /hojin/v1/... 的请求会返回相同的 500/401 特征，因此在尝试访问 v2 并得到 HTML 404 之前，它看起来像是可用的基址。
• 无结果时返回 HTTP 404——状态码和响应正文都与不存在或格式错误的法人番号相同。对于搜索，这表示零个匹配项，是正常结果；只有按编号查询时才可以报告为未找到。
• 响应中不包含总数。 信封结构为 {id, errors, message, hojin-infos}，除此之外没有其他内容——没有计数，也没有下一页标记。limit 上限为 5000，page 上限为 10。这里不会声称有任何未提供的总数；搜索会改为报告 more_pages_possible。
• 返回空数组且状态码为 200，是表示真实公司没有该类记录的正常方式。 Toyota 的 /subsidy 结果为空。不要用这样的公司进行冒烟测试——那样通过的测试毫无证明力。苫小牧市（1000020012131）有 61 条补贴记录。

可在需要法人番号的任何地方使用公司名称

gbiz_company_profile、gbiz_company_procurement、gbiz_company_subsidies 和 gbiz_company_records 都接受 13 位法人番号或公司名称，解析后的名称会作为 resolved_from 返回。这并非只是为了方便。平台密钥到位当天的实测结果是：ask_pipeworx 将 “what Japanese government procurement contracts has Toyota Motor received?” 原样交给 gbiz_company_procurement，参数不是数字，因为路由器会根据问题与工具描述的匹配程度选择工具，而不会考虑调用方手头的参数。用文字告诉它先调用 gbiz_company_search，也不会改变这一点。

匹配前会去除公司组织形式标记再进行比较——注册名称为トヨタ自動車株式会社，因此在进行这种规范化之前，仅输入トヨタ自動車就会精确匹配 10 个申报主体；而株式会社在不同公司的名称中可能位于名称之前或之后。如果名称匹配到多个申报主体，工具会拒绝请求并列出这些主体，而不是随便选第一个：自信满满地回答错误公司的信息，是本工具包最谨慎防范的问题。

调用方会踩的坑，而非构建者

使用拉丁字母搜索名称，找不到你想要的公司。 name=Toyota 会匹配罗马字名称字段，大多数日本公司都将该字段留空，而该字段中的结果主要是市政机构——它会返回豊田市稲橋財産区（“丰田市稲橋财产区”），而非トヨタ自動車株式会社，并且状态码正常返回 200。name=トヨタ自動車 则会返回这家汽车制造商。工具描述中对此有说明；使用拉丁字母查询时，返回结果会附带 match_note，指出实际匹配的字段。查询特定公司时，法人番号是可靠的键。

数据来源

• REST API v2：https://api.info.gbiz.go.jp/hojin/v2/ — 规范文档：https://api.info.gbiz.go.jp/hojin/v3/api-docs?group=v2，Swagger UI：https://api.info.gbiz.go.jp/hojin/swagger-ui/index.html?urls.primaryName=v2
• 发布方：経済産業省 / METI（法人番号 4000012090001），https://info.gbiz.go.jp/

快速开始

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

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

此端点实际提供的内容

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

这是有意为之，并非意外的多路复用。元工具可以让一个限定范围的连接回答此工具包未涵盖的问题——通过可跨整个目录路由的 ask_pipeworx 实现——这样你就不必再添加第二个 MCP 服务。目前无法挂载不含这些元工具的工具包端点；如果额外的架构定义占用的上下文多于路由带来的收益，请改为连接一次完整网关，而不是连接多个工具包端点。

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

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

两个 URL 都连接到同一个网关和相同的 1879+ 个数据源。唯一的区别在于直接列出哪个工具包的工具；无论连接哪一个，ask_pipeworx 都可以访问所有工具。

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

curl -X POST https://gateway.pipeworx.io/v1/tools/gbiz_company_search \
  -H 'Content-Type: application/json' \
  -d '{"name":"トヨタ自動車","limit":3}'

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

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

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

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

或者直接运行它，确认服务能够启动：

npx -y @pipeworx/mcp-gbizinfo

它通过 stdin/stdout 使用 MCP 协议，并仅针对本工具包的工具响应 initialize/tools/list/tools/call——不包含上方网关连接所添加的任何共享元工具。来源相同，工具相同，但不支持 ask_pipeworx 路由。

使用 ask_pipeworx

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

ask_pipeworx({ question: "your question about Gbizinfo data" })

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

更多内容

• 文档和指南
• pipeworx.io

许可证

MIT