The full upstream README, mirrored here for reference. Install config, tool schemas, adoption signals, and an original overview live on the Gbizinfo listing page.
Japanese corporate registry — company profiles, government procurement awards, subsidies, patents, certifications, financials and workplace disclosure, keyed on the 13-digit 法人番号 (corporate number). Source: gBizINFO, Ministry of Economy, Trade and Industry (METI).
Part of Pipeworx — an MCP gateway connecting AI agents to 1683+ live data sources.
gbiz_company_search(name?, prefecture?, city?, corporate_type?, has?, capital_min?, capital_max?, employees_min?, employees_max?, founded_year?, limit?, page?, _apiKey) — find companies and their corporate numbers.
gbiz_company_profile(corporate_number, _apiKey) — registry profile: legal name, kana and romanised forms, address, representative director, capital, headcount, establishment date, business summary, website, dissolution.
gbiz_company_procurement(corporate_number, limit?, _apiKey) — Japanese government contracts awarded: order date, title, amount in yen, awarding ministry.
gbiz_company_subsidies(corporate_number, limit?, _apiKey) — subsidies and grants received: approval date, programme, amount, granting ministry.
gbiz_company_records(corporate_number, kind, limit?, _apiKey) — patent, certification, commendation, finance or workplace.
The five kinds do not share one response shape. patent, certification and commendation come back as a LIST under a key matching the kind, with returned and total_on_record counts. finance and workplace are ONE record per company, so they come back as an OBJECT — finance under finance (accounting standards, the fiscal-year cover page, a management_index period series and major_shareholders), and workplace statistics under workplace_info, whose key deliberately does not match its workplace kind because that is what the upstream returns. For the object kinds limit caps the arrays nested inside, and total_on_record is a per-array map rather than a single number.
Platform key, since 2026-09-13 (fleet #1940). The gateway holds PLATFORM_GBIZINFO_KEY and injects it, so callers need no key of their own. _apiKey is still accepted for anyone who would rather use their own token and its own quota.
It shipped BYOK-only first, with platformKeyEnv deliberately absent, so the gateway's keyBlockedTools() sank these tools from routing while no key existed — an honest no_match beats routing Japanese-company questions to a tool that can only refuse. The secret and platformKeyEnv landed in the same change, which is the rule that ordering exists to enforce (the fda-inspections precedent, fleet #617).
To use your own token, register free at https://info.gbiz.go.jp/hojin/various_registration/form. A non-Japanese applicant can register: the form's 利用者区分 radio offers 法人担当者 (corporate — wants a 13-digit 法人番号, Japanese company name, department, postcode, address and phone) and 個人利用者 (individual), for which the required fields are just email, password, purpose and the two consent boxes. This is the distinction that makes gBizINFO usable where the NTA 法人番号 API is not — that one's application path requires a Japanese corporate number with no individual alternative. The token arrives by email.
The public OpenAPI document at https://api.info.gbiz.go.jp/hojin/v3/api-docs?group=v2 embeds a token in info.description. The same sentence says, in Japanese, that it is for checking behaviour on the Swagger page only. It is useful for reading response shapes while building. It is not a credential to ship, and this pack does not carry it.
500 - Internal Server Error.; a wrong token answers a clean 401. Passed through, a missing credential reads as an upstream outage. Translated to an auth refusal here.api.info.gbiz.go.jp and the version is v2. The bare info.gbiz.go.jp answers /hojin/v1/... with the same 500/401 signature, so it looks like a working base until you try v2 there and get an HTML 404.{id, errors, message, hojin-infos} and nothing else — no count, no next-page marker. limit caps at 5000 and page at 10. Nothing here claims a total it was not given; a search reports more_pages_possible instead./subsidy is empty. Don't use a company like that as a smoke test — it banks a passing test that proves nothing. 苫小牧市 (1000020012131) has 61 subsidies.gbiz_company_profile, gbiz_company_procurement, gbiz_company_subsidies and gbiz_company_records all take either the 13-digit 法人番号 or the company name, and a resolved name comes back as resolved_from. This is not a convenience. Measured the day the platform key landed: ask_pipeworx sent "what Japanese government procurement contracts has Toyota Motor received?" straight to gbiz_company_procurement with a non-numeric argument, because a router picks the tool whose description matches the question, not the one whose argument the caller happens to hold. Telling it in prose to call gbiz_company_search first does not change that.
The match strips the corporate-form token before comparing — the registered name is トヨタ自動車株式会社, so a bare トヨタ自動車 matched ten filers exactly until that normalisation existed, and 株式会社 appears before or after the name depending on the company. A name matching several filers refuses and lists them rather than taking the first: answering confidently about the wrong company is the failure this pack is most careful about.
A Latin-script name search does not find the company you mean. name=Toyota matches the romanised name field, which most Japanese companies leave empty and which is dominated by municipal bodies — it returns 豊田市稲橋財産区 ("Toyota City Inahashi property ward"), not トヨタ自動車株式会社, with a clean 200. name=トヨタ自動車 returns the carmaker. The tool description says so, and a Latin-script query comes back with a match_note saying which field it actually matched. For a specific company the corporate number is the reliable key.
https://api.info.gbiz.go.jp/hojin/v2/ — spec at https://api.info.gbiz.go.jp/hojin/v3/api-docs?group=v2, Swagger UI at https://api.info.gbiz.go.jp/hojin/swagger-ui/index.html?urls.primaryName=v2Add to your MCP client (Claude Desktop, Cursor, Windsurf, etc.):
tools/list at https://gateway.pipeworx.io/gbizinfo/mcp returns the tools in the table
above plus the shared Pipeworx meta-tools — ask_pipeworx,
discover_tools, search_within, remember/recall and the rest of the
gateway-wide set. So the tool count you see is larger than this table: a
single-pack endpoint currently lists roughly 30 shared tools alongside the
pack's own. The connection's initialize response states its exact scope, and
is the authoritative answer for a given day.
This is deliberate, not multiplexing by accident. The meta-tools are what let a
scoped connection answer a question this pack does not cover — via
ask_pipeworx, which routes across the whole catalog — without you adding a
second MCP server. There is currently no way to mount a pack endpoint without
them; if the extra schemas cost you more context than the routing is worth,
connect to the full gateway once rather than to several pack endpoints.
Or connect to the full Pipeworx gateway to get every pack's tools listed directly, instead of just this one's:
Both URLs reach the same gateway and the same 1683+ data sources. The
only difference is which pack's tools are listed directly; ask_pipeworx
reaches all of them from either one.
No account needed for the first calls. Inspect any tool: GET https://gateway.pipeworx.io/v1/tools/gbiz_company_search. Find one: POST https://gateway.pipeworx.io/v1/tools/search_packs with {"query":"..."}.
This package also runs as a local stdio MCP server — no Pipeworx account, no gateway round-trip:
Or run it directly to confirm it starts:
It speaks MCP over stdin/stdout and answers initialize/tools/list/tools/call
for only this pack's tools — none of the shared meta-tools the gateway
connection above adds. Same source, same tools, no ask_pipeworx routing.
Instead of calling tools directly, you can ask questions in plain English — this works on the pack endpoint above as well as on the full gateway:
The gateway picks the right tool and fills the arguments automatically.
MIT