houjin-bangou-api-mcp
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@houjin-bangou-api-mcpsearch for company named 'ソニー'"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
houjin-bangou-api-mcp
MCP server for the Japan National Tax Agency Corporate Number API.
This project wraps the official Corporate Number Publication Site Web-API and exposes it as MCP tools for local AI clients.
日本語
houjin-bangou-api-mcp は、国税庁の法人番号公表サイト Web-API を MCP から使いやすくするための
軽量サーバーです。
できること:
法人番号で法人情報を取得する
法人名で検索する
更新差分を期間指定で取得する
XML / UTF-8 CSV / Shift-JIS CSV を扱う
MCP クライアントからそのまま使える形で返す
最短の使い方:
npm installHOUJIN_BANGOU_API_APPLICATION_IDを設定するnpm run buildMCP host から
dist/server.jsを起動するnpm run verify:liveでまとめて確認する
詳細なセットアップ、入力制約、レスポンス形式、検証方法はこの README の後半に英語でまとめています。
Related MCP server: kaisha-mcp
Why this exists
The National Tax Agency already provides an official API, but using it from LLM tools still requires a thin integration layer. This repository aims to be that layer:
small and auditable
easy to self-host
close to the official API
practical for Japanese business research workflows
Features
Get a corporation by 13-digit corporate number
Get up to 10 corporations in one request
Include historical records for corporation number lookups
Search corporations by name
Filter name searches by mode, target, address, kind, change status, close status, assignment date, and page
Fetch updates within a date range
Filter update searches by address, kind, and page
Support the official response formats: CSV (Shift-JIS), CSV (Unicode), and XML
Return normalized JSON-style output from the official XML API
Coverage
This MCP server targets the latest supported Ver.4.0 Corporate Number API and exposes the
documented request conditions for its three core endpoints:
/num/name/diff
Requirements
Node.js 18 or later
A National Tax Agency Web-API application ID
Official documentation:
Quick Start
This is the shortest path from clone to a successful MCP call.
1. Install dependencies
npm install2. Set your application ID
Use an environment variable and never commit the real value.
macOS or Linux:
export HOUJIN_BANGOU_API_APPLICATION_ID=YOUR_APPLICATION_IDWindows PowerShell:
$env:HOUJIN_BANGOU_API_APPLICATION_ID = "YOUR_APPLICATION_ID"For local development, copy .env.example and load it with your preferred workflow.
3. Build the server
npm run build4. Point your MCP host at the built server
All MCP clients need the same launch details:
command:
nodeargs: the absolute path to
dist/server.jsenv:
HOUJIN_BANGOU_API_APPLICATION_ID
If your client has a UI for adding a local stdio MCP server, use those values directly.
JSON-based hosts: Claude Desktop, Claude Code .mcp.json, and compatible clients
Use this when your client reads an mcpServers JSON object:
{
"mcpServers": {
"houjin-bangou-api": {
"command": "node",
"args": [
"/absolute/path/to/houjin-bangou-api-mcp/dist/server.js"
],
"env": {
"HOUJIN_BANGOU_API_APPLICATION_ID": "YOUR_APPLICATION_ID"
}
}
}
}The same entry works well in a project-local .mcp.json. If you already use Claude Desktop, you
can also reuse the same mcpServers entry there and import it into Claude Code later.
Codex CLI
Add the server once:
codex mcp add houjin-bangou-api --env HOUJIN_BANGOU_API_APPLICATION_ID=YOUR_APPLICATION_ID -- node /absolute/path/to/houjin-bangou-api-mcp/dist/server.jsEquivalent ~/.codex/config.toml entry:
[mcp_servers.houjin-bangou-api]
command = "node"
args = ["/absolute/path/to/houjin-bangou-api-mcp/dist/server.js"]
env = { HOUJIN_BANGOU_API_APPLICATION_ID = "YOUR_APPLICATION_ID" }Continue
Continue uses YAML-based MCP configuration. Add the same server under ~/.continue/config.yaml
or in a dedicated file inside .continue/mcpServers/:
mcpServers:
houjin-bangou-api:
command: node
args:
- /absolute/path/to/houjin-bangou-api-mcp/dist/server.js
env:
HOUJIN_BANGOU_API_APPLICATION_ID: YOUR_APPLICATION_IDWindows path example
{
"mcpServers": {
"houjin-bangou-api": {
"command": "node",
"args": [
"C:\\Users\\YOUR_USERNAME\\path\\to\\houjin-bangou-api-mcp\\dist\\server.js"
],
"env": {
"HOUJIN_BANGOU_API_APPLICATION_ID": "YOUR_APPLICATION_ID"
}
}
}
}Tips:
Always use an absolute path to
dist/server.jsKeep the application ID in the client config
envblock or--envflagRun
npm run buildagain after pulling new commitsRestart or reload the MCP client after changing the configuration
5. Make the first successful call
Start with the smallest happy path:
Tool:
get_corporation_by_numberArguments:
{
"corporateNumber": "7000012050002"
}Illustrative result shape when responseType is omitted:
{
"metadata": {
"lastUpdateDate": "YYYY-MM-DD",
"count": 1,
"divideNumber": 1,
"divideSize": 1
},
"corporations": [
{
"corporateNumber": "7000012050002",
"name": "国税庁",
"latest": true
}
]
}Once that works, try:
search_corporations_by_namewith{ "name": "任天堂株式会社" }get_corporation_updateswith a recent date window such as{ "from": "YYYY-MM-DD", "to": "YYYY-MM-DD" }get_corporation_by_numberwithresponseType: "02"orresponseType: "01"
6. Run the recommended end-to-end live check
After the first call works, use one command for the full live verification path:
npm run verify:liveExpected result:
the server builds once
MCP tool registration succeeds
the real-company checks pass
advanced filters pass
all response types pass
If HOUJIN_BANGOU_API_APPLICATION_ID is missing, this command fails immediately with a clear
message instead of running partial checks.
Getting an Application ID
You need a National Tax Agency Web-API application ID before the MCP server can call the live API.
As of March 12, 2026, the official flow is:
Open the official application ID registration page on the invoice site.
Submit the registration form and receive an application ID.
If you will use that ID with the Corporate Number API, follow the current instructions on the Corporate Number API portal, which point to the invoice site flow and email confirmation.
Official pages:
At the time of writing, the Corporate Number API portal instructs users who obtained an ID from the
invoice site to email invoice-webapi@nta.go.jp with their name, email address, and a note that
they want to use the Corporate Number API. Always check the official pages above for the latest
procedure before sharing credentials or support instructions.
Run
Development:
npm run devBuild:
npm run buildProduction entrypoint:
npm startnpm start launches a stdio MCP server and waits for a client connection. Seeing no prompt after
startup is normal.
Package Imports
The packaged CLI still lives at dist/server.js, but importing the package root is now safe and
side-effect free.
Root import:
import { HoujinBangouApiClient, formatApiError, parseCorporationListXml } from "houjin-bangou-api-mcp";Subpath imports:
import { getApplicationIdFromEnv } from "houjin-bangou-api-mcp/nta-api";
import { parseCorporationListXml } from "houjin-bangou-api-mcp/xml";This keeps the CLI entrypoint focused on MCP server startup while allowing programmatic reuse of the request builder and XML parser.
MCP Tools
get_corporation_by_number
Inputs:
corporateNumber: 13-digit corporate numbercorporateNumbers: optional array of up to 10 corporate numbershistory: optional boolean to include historical recordsresponseType: optional response type,12XML,02Unicode CSV,01Shift-JIS CSV
search_corporations_by_name
Inputs:
name: corporation or organization nameresponseType: optional response type,12XML,02Unicode CSV,01Shift-JIS CSVmode: optional search mode,1prefix or2partial matchtarget: optional target,1name,2furigana,3bothaddress: optional 2-digit prefecture code or 5-digit city codekinds: optional array of corporation kind filters:01,02,03,04change: optional boolean to include changed recordsclose: optional boolean to include closed corporationsassignmentFrom: optional assignment date lower bound inYYYY-MM-DDassignmentTo: optional assignment date upper bound inYYYY-MM-DDdivide: optional page number for paginated API results
get_corporation_updates
Inputs:
from: start date inYYYY-MM-DDto: end date inYYYY-MM-DDresponseType: optional response type,12XML,02Unicode CSV,01Shift-JIS CSVaddress: optional 2-digit prefecture code or 5-digit city codekinds: optional array of corporation kind filters:01,02,03,04divide: optional page number for paginated API results
Input Rules and API Limits
These rules are enforced by the MCP server before the request reaches the official API.
corporateNumbermust be a 13-digit stringcorporateNumberscan contain 1 to 10 valuescorporateNumberandcorporateNumbersare mutually exclusiveaddressmust be either a 2-digit prefecture code or a 5-digit city codeassignmentFromandassignmentTomust be real dates on or after2015-10-05assignmentFrommust be on or beforeassignmentTofromandtoforget_corporation_updatesmust be real dates on or after2015-12-01fromandtoforget_corporation_updatesmust stay within 50 days inclusivedividemust be a positive integer
Response Types
The official API type switch is exposed through responseType.
12: XML from the source API, returned by this MCP as structured JSON-style data02: Unicode CSV from the source API, returned by this MCP as raw text01: Shift-JIS CSV from the source API, returned by this MCP as raw text
Structured example: responseType: "12"
This example shows the shape of a successful response, not a fixed live snapshot.
{
"metadata": {
"lastUpdateDate": "YYYY-MM-DD",
"count": 1,
"divideNumber": 1,
"divideSize": 1
},
"corporations": [
{
"corporateNumber": "7000012050002",
"name": "国税庁",
"prefectureName": "東京都",
"cityName": "千代田区",
"latest": true
}
]
}Raw CSV example: responseType: "02" or responseType: "01"
{
"responseType": "02",
"contentType": "text/csv;charset=UTF-8",
"raw": "YYYY-MM-DD,1,1,1\n1,7000012050002,01,1,2018-04-02,2015-10-05,\"国税庁\",..."
}Use 12 when you want fields you can safely consume in tools or downstream code. Use 01 or 02
when you need the source CSV payload.
Structured Response Fields
When responseType is omitted or set to 12, the MCP server returns:
metadata: source pagination and result metadata from the official APIcorporations: normalized corporation records from the XML payload
Common metadata fields:
lastUpdateDate: source update date reported by the APIcount: total record count for the requestdivideNumber: current page number reported by the source APIdivideSize: total number of pages reported by the source API
Common corporations[] fields:
corporateNumber: 13-digit corporate numbername: Japanese corporation namefurigana: furigana when the API provides itprefectureName,cityName,streetNumber: Japanese address fragmentsenName,enPrefectureName,enCityName,enAddressOutside: English fields when presentkind: official corporation kind codeprocess: official source process codecorrect: normalized boolean flag from the source0or1latest: normalized boolean flag from the source0or1hidden: normalized boolean flag from the source hidden markercloseDate,closeCause: closure metadata for dissolved or closed corporationssuccessorCorporateNumber: successor corporation number when presentchangeCause: official reason code for a changeassignmentDate,updateDate,changeDate: important source dates
The MCP server keeps official field names close to the source API so users can map the values back
to the National Tax Agency documentation. For the normative meaning of codes such as kind,
process, closeCause, and changeCause, use the official Ver.4.0 specification:
Pagination
The official API paginates some responses. This MCP server exposes the same page metadata through
metadata.count, metadata.divideNumber, and metadata.divideSize.
Typical workflow:
Call
search_corporations_by_nameorget_corporation_updateswithoutdividefirst.Read
metadata.divideSize.If
divideSizeis greater than1, call the same tool again withdivide: 2,divide: 3, and so on until you reach the last page.
Illustrative example:
{
"name": "株式会社",
"divide": 2
}The MCP server does not auto-follow all pages yet. That is intentional so callers can control API usage and stop early when they already have enough records.
Verification Checklist
Use these checks in order when setting up or debugging.
When the upstream API returns a code-prefixed validation failure, this MCP server preserves the
official message and may append a short Hint: sentence to point you toward the most likely input
problem.
Basic test suite
npm testExpected result:
all tests pass
Build
npm run buildExpected result:
dist/server.jsis generated without TypeScript errorsdist/index.jsis generated for package imports
MCP connection check
npm run smoke:mcpExpected result:
the three tools are listed
if
HOUJIN_BANGOU_API_APPLICATION_IDis set, live API calls also succeed
One-command live verification
npm run verify:liveExpected result:
build runs once at the start
the script stops on the first failing live check
successful output ends with
verify:live completed successfully
Real-company check
npm run check:companiesExpected result:
National Tax Agency, Nintendo, Toyota Motor, and Sony Group are all found as expected
Advanced filter check
npm run check:advanced-filtersExpected result:
multiple corporate numbers resolve in one request
filtered name search returns the expected narrow result set
filtered diff search returns live update records
Response type check
npm run check:response-typesExpected result:
12returns structured data02returns Unicode CSV text01returns Shift-JIS CSV text decoded into readable output
Packaged install check
npm run smoke:packageExpected result:
installed package entrypoints expose the three tools
package root imports do not start the server or require environment variables
missing application ID fails clearly
Windows installs work even when the repository path contains non-ASCII characters
Package dry-run
npm run check:packExpected result:
npm pack --dry-runsucceeds and includes the intended files
Installation Paths
Use from this repository today
Clone the repository, run npm install, build it, and point your MCP host at
/absolute/path/to/houjin-bangou-api-mcp/dist/server.js.
Use from npm later
This repository is ready for package-oriented verification, but npm publishing is still a future
distribution path. Once published, the README can add an npx-based install path alongside the
repository-based setup above.
Common Issues
Missing application ID
Symptom:
the server exits immediately with
Missing HOUJIN_BANGOU_API_APPLICATION_ID
Fix:
set
HOUJIN_BANGOU_API_APPLICATION_IDin the environment passed to the MCP host
Diff range is rejected
Symptom:
from must be on or before tofrom and to must be within 50 daysfrom must be on or after 2015-12-01
Fix:
keep the date window within 50 days inclusive
use dates on or after
2015-12-01
Name assignment dates are rejected
Symptom:
assignmentFrom must be on or after 2015-10-05assignmentTo must be on or after 2015-10-05
Fix:
use assignment date filters on or after
2015-10-05
Address code is rejected
Symptom:
address must be a 2-digit prefecture code or 5-digit city code
Fix:
pass values such as
13for Tokyo prefecture or13101for Chiyoda City
CSV was expected but structured data came back
Symptom:
the result contains
metadataandcorporations
Fix:
set
responseTypeto02or01leave
responseTypeunset or use12when you want structured output
Upstream request timed out
Symptom:
Corporate Number API request timed out after 15000 ms
Fix:
retry the request after confirming network connectivity
reduce the request scope when possible, for example by narrowing date ranges or filters
Contributing
Public contributions are welcome. Please open a pull request instead of pushing directly to
main.
Contribution guide: CONTRIBUTING.md
Code of conduct: CODE_OF_CONDUCT.md
Roadmap: ROADMAP.md
Pull requests are expected to pass CI:
npm testnpm run build
Current GitHub Actions coverage:
Ubuntu and Windows test/build on Node.js 18, 20, and 22
packaged install smoke tests on Ubuntu
packaged install smoke tests on Windows from a non-ASCII workspace path
Security
Keep your application ID out of Git history, screenshots, and issue reports.
Use environment variables only.
Treat all logs as potentially public before sharing them.
License
MIT
Available Tools
3 toolsget_corporation_by_numberGet Corporation By NumberC
Fetch corporation details from the National Tax Agency Corporate Number API.
| Name | Required | Description | Default |
|---|---|---|---|
| history | No | Include historical records when true. | |
| responseType | No | Response format: 01 CSV (Shift-JIS), 02 CSV (UTF-8/Unicode), 12 XML. | |
| corporateNumber | No | ||
| corporateNumbers | No | Up to 10 corporate numbers in one call. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for disclosing behavior. It only says 'Fetch corporation details,' which is generic and fails to mention capabilities like handling multiple corporate numbers, response format options, or historical record retrieval. This is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no filler. It is front-loaded with the action and resource. While minimal, it is appropriately sized for a simple fetch tool, though it could be more informative without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's four parameters, no output schema, and sibling tools, this description is incomplete. It fails to explain when to use this tool (by corporate number) versus searching by name, the meaning of the responseType and history parameters, or any return value details. The sparse description leaves too much to be inferred.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 75%, so most parameters are explained there. However, the description itself adds no parameter context, and the corporateNumber parameter lacks a schema description. Baseline 3 is appropriate since the schema does most of the work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Fetch') and the resource ('corporation details') from a specific source ('National Tax Agency Corporate Number API'). It is unambiguous, though it doesn't explicitly distinguish itself from sibling tools like search_corporations_by_name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not mention scenarios where this tool should be used over alternatives, nor does it reference sibling tools. The agent is left to infer from the tool name and siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_corporation_updatesGet Corporation UpdatesB
Fetch corporations updated within a date range from the Corporate Number API.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | ||
| from | Yes | ||
| kinds | No | ||
| divide | No | ||
| address | No | ||
| responseType | No | Response format: 01 CSV (Shift-JIS), 02 CSV (UTF-8/Unicode), 12 XML. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the basic read operation but fails to mention response formats, pagination, rate limits, or any other behavioral traits. The responseType parameter hints at format, but the description does not elaborate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. Every phrase contributes to understanding the core function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given six parameters, no output schema, and no annotations, a one-sentence description is inadequate. It omits return format details, parameter semantics, and any practical usage context, leaving the agent under-informed for invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 17%, leaving five of six parameters undocumented. The description adds minimal value: it mentions 'date range' which maps to from/to, but does not explain kinds, divide, address, or responseType meanings, failing to compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Fetch' and the resource 'corporations updated within a date range', which distinguishes it from sibling tools that fetch by number or name. The scope is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The date-range scope implies when to use this tool, but there is no explicit guidance on alternatives or exclusions. Sibling tools are not referenced, though their existence is evident from the context signals.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_corporations_by_nameSearch Corporations By NameC
Search corporations by name using the official Corporate Number API.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | 1 for prefix match, 2 for partial match. | |
| name | Yes | ||
| close | No | When true, include closed corporations. When false, active only. | |
| kinds | No | ||
| change | No | When true, include changed records. When false, latest only. | |
| divide | No | ||
| target | No | 1 for name only, 2 for furigana only, 3 for both. | |
| address | No | ||
| assignmentTo | No | ||
| responseType | No | Response format: 01 CSV (Shift-JIS), 02 CSV (UTF-8/Unicode), 12 XML. | |
| assignmentFrom | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It only mentions the official API, but doesn't describe read-only nature, pagination (divide), return formats, or rate limits. Too little for a complex search tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no redundancy, but it is under-specified for a tool with 11 parameters. It is concise but not appropriately structured to convey necessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (11 params, no output schema, no annotations), this one-line description is severely insufficient. It fails to mention response types, pagination, or any operational details, making it incomplete for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low (45%), and the description adds no parameter-level meaning. It doesn't explain any of the 11 parameters beyond the trivial fact that name is used, which is already in the required schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches corporations by name, using a specific verb 'search' and resource 'corporations'. It implicitly distinguishes from get_corporation_by_number (search by number) and get_corporation_updates (updates), though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus sibling tools. The phrase 'by name' weakly implies a use case, but there are no explicit context signals, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
3 tool updates
v0.1.0- First observed
get_corporation_by_number - First observed
get_corporation_updates - First observed
search_corporations_by_name
TDQS
Scored across 3 tools
Each tool addresses a distinct operation: exact lookup by corporate number, search by name, and retrieval of updates over a date range. There is no overlap in purpose, making it easy for an agent to select the correct tool.
All tool names follow a clear verb_noun pattern with snake_case (get_/search_), and the suffix indicates the query parameter (by_number, by_name, updates). Minor pluralization variation (corporation vs. corporations) is semantically meaningful and does not detract from consistency.
With exactly three tools, the server is tightly scoped to the three main endpoints of the Corporate Number API. Each tool earns its place, and the count is well within the ideal range for a focused MCP server.
The tool set fully covers the public surface of the National Tax Agency Corporate Number API: lookup by number, search by name, and updates. There are no obvious missing operations for common use cases, and agents can accomplish all typical tasks without workarounds.
Maintenance
Related MCP Connectors
MCP server for Japan geodata: cadastral lot numbers (chiban) and reverse geocoding, for AI agents.
- UnifAPIOAuthcom.unifapi
Hosted MCP server for live public-data APIs and Skills for AI agents.
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
Related MCP Servers
- FlicenseBqualityDmaintenanceMCP server for searching Japanese government procurement notices via the Kanpou API. Enables LLMs to search by date, keyword, or detailed criteria.31-
- AlicenseNot gradedqualityCmaintenanceMCP server for the Kaisha API, providing official Japanese company-registry data including corporate numbers and qualified invoice registrations, with pay-per-call via USDC micropayments.2 npmMIT
- AlicenseAqualityBmaintenanceAn MCP server that validates Japanese corporate numbers and invoice registration numbers, and normalizes/matches company names across notation variants.721 npmMIT
- AlicenseAqualityBmaintenanceMCP server for Japanese public business data, enabling AI agents to validate and look up corporate numbers, search bank/branch codes, and check national holidays. Runs locally with no telemetry; live corporate registry data requires a free NTA app ID.8MIT