Skip to main content
Glama
yamayued

houjin-bangou-api-mcp

by yamayued

houjin-bangou-api-mcp

CI MIT License

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 クライアントからそのまま使える形で返す

最短の使い方:

  1. npm install

  2. HOUJIN_BANGOU_API_APPLICATION_ID を設定する

  3. npm run build

  4. MCP host から dist/server.js を起動する

  5. 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 install

2. 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_ID

Windows 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 build

4. Point your MCP host at the built server

All MCP clients need the same launch details:

  • command: node

  • args: the absolute path to dist/server.js

  • env: 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.js

Equivalent ~/.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_ID

Windows 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.js

  • Keep the application ID in the client config env block or --env flag

  • Run npm run build again after pulling new commits

  • Restart 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_number

Arguments:

{
  "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_name with { "name": "任天堂株式会社" }

  • get_corporation_updates with a recent date window such as { "from": "YYYY-MM-DD", "to": "YYYY-MM-DD" }

  • get_corporation_by_number with responseType: "02" or responseType: "01"

After the first call works, use one command for the full live verification path:

npm run verify:live

Expected 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:

  1. Open the official application ID registration page on the invoice site.

  2. Submit the registration form and receive an application ID.

  3. 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 dev

Build:

npm run build

Production entrypoint:

npm start

npm 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 number

  • corporateNumbers: optional array of up to 10 corporate numbers

  • history: optional boolean to include historical records

  • responseType: optional response type, 12 XML, 02 Unicode CSV, 01 Shift-JIS CSV

search_corporations_by_name

Inputs:

  • name: corporation or organization name

  • responseType: optional response type, 12 XML, 02 Unicode CSV, 01 Shift-JIS CSV

  • mode: optional search mode, 1 prefix or 2 partial match

  • target: optional target, 1 name, 2 furigana, 3 both

  • address: optional 2-digit prefecture code or 5-digit city code

  • kinds: optional array of corporation kind filters: 01, 02, 03, 04

  • change: optional boolean to include changed records

  • close: optional boolean to include closed corporations

  • assignmentFrom: optional assignment date lower bound in YYYY-MM-DD

  • assignmentTo: optional assignment date upper bound in YYYY-MM-DD

  • divide: optional page number for paginated API results

get_corporation_updates

Inputs:

  • from: start date in YYYY-MM-DD

  • to: end date in YYYY-MM-DD

  • responseType: optional response type, 12 XML, 02 Unicode CSV, 01 Shift-JIS CSV

  • address: optional 2-digit prefecture code or 5-digit city code

  • kinds: optional array of corporation kind filters: 01, 02, 03, 04

  • divide: 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.

  • corporateNumber must be a 13-digit string

  • corporateNumbers can contain 1 to 10 values

  • corporateNumber and corporateNumbers are mutually exclusive

  • address must be either a 2-digit prefecture code or a 5-digit city code

  • assignmentFrom and assignmentTo must be real dates on or after 2015-10-05

  • assignmentFrom must be on or before assignmentTo

  • from and to for get_corporation_updates must be real dates on or after 2015-12-01

  • from and to for get_corporation_updates must stay within 50 days inclusive

  • divide must 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 data

  • 02: Unicode CSV from the source API, returned by this MCP as raw text

  • 01: 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 API

  • corporations: normalized corporation records from the XML payload

Common metadata fields:

  • lastUpdateDate: source update date reported by the API

  • count: total record count for the request

  • divideNumber: current page number reported by the source API

  • divideSize: total number of pages reported by the source API

Common corporations[] fields:

  • corporateNumber: 13-digit corporate number

  • name: Japanese corporation name

  • furigana: furigana when the API provides it

  • prefectureName, cityName, streetNumber: Japanese address fragments

  • enName, enPrefectureName, enCityName, enAddressOutside: English fields when present

  • kind: official corporation kind code

  • process: official source process code

  • correct: normalized boolean flag from the source 0 or 1

  • latest: normalized boolean flag from the source 0 or 1

  • hidden: normalized boolean flag from the source hidden marker

  • closeDate, closeCause: closure metadata for dissolved or closed corporations

  • successorCorporateNumber: successor corporation number when present

  • changeCause: official reason code for a change

  • assignmentDate, 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:

  1. Call search_corporations_by_name or get_corporation_updates without divide first.

  2. Read metadata.divideSize.

  3. If divideSize is greater than 1, call the same tool again with divide: 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 test

Expected result:

  • all tests pass

Build

npm run build

Expected result:

  • dist/server.js is generated without TypeScript errors

  • dist/index.js is generated for package imports

MCP connection check

npm run smoke:mcp

Expected result:

  • the three tools are listed

  • if HOUJIN_BANGOU_API_APPLICATION_ID is set, live API calls also succeed

One-command live verification

npm run verify:live

Expected 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:companies

Expected result:

  • National Tax Agency, Nintendo, Toyota Motor, and Sony Group are all found as expected

Advanced filter check

npm run check:advanced-filters

Expected 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-types

Expected result:

  • 12 returns structured data

  • 02 returns Unicode CSV text

  • 01 returns Shift-JIS CSV text decoded into readable output

Packaged install check

npm run smoke:package

Expected 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:pack

Expected result:

  • npm pack --dry-run succeeds 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_ID in the environment passed to the MCP host

Diff range is rejected

Symptom:

  • from must be on or before to

  • from and to must be within 50 days

  • from 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-05

  • assignmentTo 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 13 for Tokyo prefecture or 13101 for Chiyoda City

CSV was expected but structured data came back

Symptom:

  • the result contains metadata and corporations

Fix:

  • set responseType to 02 or 01

  • leave responseType unset or use 12 when 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.

Pull requests are expected to pass CI:

  • npm test

  • npm 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 tools
get_corporation_by_numberGet Corporation By NumberC

Fetch corporation details from the National Tax Agency Corporate Number API.

ParametersJSON Schema
NameRequiredDescriptionDefault
historyNoInclude historical records when true.
responseTypeNoResponse format: 01 CSV (Shift-JIS), 02 CSV (UTF-8/Unicode), 12 XML.
corporateNumberNo
corporateNumbersNoUp to 10 corporate numbers in one call.

TDQS

C2.9/5.0
Behavior2/5

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.

Conciseness4/5

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.

Completeness2/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines2/5

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
toYes
fromYes
kindsNo
divideNo
addressNo
responseTypeNoResponse format: 01 CSV (Shift-JIS), 02 CSV (UTF-8/Unicode), 12 XML.

TDQS

B3.3/5.0
Behavior2/5

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.

Conciseness5/5

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.

Completeness2/5

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.

Parameters2/5

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.

Purpose5/5

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.

Usage Guidelines3/5

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
modeNo1 for prefix match, 2 for partial match.
nameYes
closeNoWhen true, include closed corporations. When false, active only.
kindsNo
changeNoWhen true, include changed records. When false, latest only.
divideNo
targetNo1 for name only, 2 for furigana only, 3 for both.
addressNo
assignmentToNo
responseTypeNoResponse format: 01 CSV (Shift-JIS), 02 CSV (UTF-8/Unicode), 12 XML.
assignmentFromNo

TDQS

C2.4/5.0
Behavior2/5

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.

Conciseness3/5

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.

Completeness1/5

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.

Parameters1/5

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.

Purpose4/5

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.

Usage Guidelines2/5

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.

  1. 3 tool updatesv0.1.0
    • First observedget_corporation_by_number
    • First observedget_corporation_updates
    • First observedsearch_corporations_by_name

TDQS

B3.4/5.0

Scored across 3 tools

Disambiguation5/5

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.

Naming Consistency5/5

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.

Tool Count5/5

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.

Completeness5/5

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

ActivityInactive
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers

  • F
    license
    B
    quality
    D
    maintenance
    MCP server for searching Japanese government procurement notices via the Kanpou API. Enables LLMs to search by date, keyword, or detailed criteria.
    3
    1
    -
  • A
    license
    Not graded
    quality
    C
    maintenance
    MCP 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 npm
    MIT
  • A
    license
    A
    quality
    B
    maintenance
    MCP 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.
    8
    MIT