mcp-jp-corporate-id

日本語版はこちら

An MCP (Model Context Protocol) server that validates and normalizes Japanese corporate numbers (houjin bangou) and qualified invoice issuer registration numbers, and normalizes/matches company names across common notation variants.

No network access is used at all (v1 calls no external APIs). Every check is done with formulas and dictionary data embedded in the code.

Read this first

• This tool only validates the format of numbers and names. It does NOT verify that a company actually exists, or that an invoice registration is currently valid. For real-world verification, always check the official National Tax Agency sites directly:
  • Corporate Number Publication Site
  • Qualified Invoice Issuer Publication Site
• Never enter a Japanese Individual Number (My Number). A company registration number (12 digits) and an individual My Number (12 digits) have the same length, and this tool cannot distinguish which kind of number it was given. calculate_check_digit always includes a caution about this in its response.
• This server never logs request input, and validation-error messages never echo back the raw number that was submitted.

Tools (7 total)

Every tool's response includes the primary sources (sources) behind its logic.

1. validate_corporate_number

Verifies whether the check digit of a 13-digit corporate number is correct. Accepts full-width digits, hyphens, and whitespace, which are normalized before validation. If the normalized length isn't 13 digits, or the check digit doesn't match, the tool returns valid: false rather than throwing.

2. calculate_check_digit

Computes the check digit from a 12-digit company registration number (assigned based on commercial registry records) and derives the 13-digit corporate number. Throws if the normalized input isn't exactly 12 digits (no guessing or zero-padding).

Caution: a 12-digit number could just as easily be a My Number (individual number) as a company registration number. Every response includes a caution field reminding callers never to submit a My Number. If the registry office code portion falls outside the typical range (0100–5000) confirmed from primary sources, a note is added.

3. validate_invoice_number

Validates a qualified invoice registration number ("T" + 13 digits).

• For numbers held by corporations ("T" + corporate number), the check digit is verified mathematically; a match returns entityType: "corporate".
• Numbers held by sole proprietors and unincorporated associations are separate 13-digit numbers issued by the NTA that overlap with neither My Number nor any corporate number. The check-digit algorithm for this class of number could not be confirmed as publicly documented within the primary sources reviewed. When the number doesn't match the corporate-number check-digit formula, the tool returns entityType: "individual_or_other", validates format only, and explicitly states that mathematical verification isn't possible in this case.
• If the input doesn't even match the "T" + 13 digits shape, formatValid: false is returned (not an exception).

4. parse_corporate_number

Verifies the check digit of a 13-digit corporate number and then parses the structure of its 12-digit base number.

• category: national_organ_legislative / national_organ_administrative / national_organ_judicial / local_government / registered_corporation / unregistered_corporation_or_unincorporated_association / unused_range
• For registered_corporation, returns registryOfficeCode (4 digits), organizationTypeCode (raw 2 digits), and serialNumber (6 digits).
• The mapping from the 2-digit organization type code to an actual corporate form (stock company, LLC, etc.) could not be confirmed as a documented numeric code table in the primary sources reviewed (the Commercial Registration Rules define three textual categories but the reviewed article text does not spell out numeric codes for them). The tool therefore returns only the raw 2-digit code with no label — see "Items that could not be verified" below.

5. normalize_company_name

Normalizes company-name notation and separates out the "body name" with the corporate form removed.

• Converts between major corporate-form notations (株式会社/(株)/（株）/㈱, etc.).
• Detects whether the corporate form appears as a prefix (株式会社○○) or suffix (○○株式会社).
• Normalizes full-width/half-width characters and a curated set of legacy/variant kanji forms (e.g. 髙→高, 﨑→崎).

Dictionary limits: only major corporate forms and variant characters are covered. This is not exhaustive of every Japanese corporate form or notation variant; anything not in the dictionary is left unrecognized and stays in the body name as-is.

6. generate_matching_key

Uses normalize_company_name internally and strips whitespace from the body name to produce a matching key for deduplication.

7. compare_company_names

Normalizes both names and compares them, returning a verdict, a confidence level, and reasons.

Design: the verdict and the reasons are both machine-generated from the same structured evidence

Rather than hand-writing the verdict/confidence logic and the explanatory text separately, this tool derives both from a single structured object, evidence, which is included as-is in the response:

The decision logic (evidence → verdict/confidence) and the explanation logic (evidence → reasons) are two separate functions that both read only from this same evidence object. Changing the decision rules automatically keeps the explanation in sync, so it's structurally impossible to end up with a confident verdict whose reasons/notes say "cannot be determined."

Script-mismatch guard (runs before any scoring)

If the two body names differ greatly in character type — one is Latin-only while the other contains Japanese (hiragana/katakana/kanji) — comparing them as strings is meaningless in principle. For example, "日本電気株式会社" (Nippon Electric Company) and "NEC" refer to the same company, yet their body-name strings share no characters at all ("NEC" is an abbreviation that cannot be detected by string comparison). Whenever this script mismatch is detected, the tool returns unknown (confidence: "low") immediately, before attempting any scoring.

Condition for returning likely_different

likely_different is returned only when all of the following hold:

• The two body names share a common prefix or suffix ("common token") of at least 2 characters.
• The remaining, non-shared part on each side (the "distinguishing element") is at least 2 characters long on both sides, and the two distinguishing elements differ.

Example: "東京電力" (Tokyo Electric Power) vs. "東北電力" (Tohoku Electric Power) — they share the suffix "電力" ("Electric Power") as a common token, with "東京" (Tokyo) and "東北" (Tohoku) as the distinguishing elements. Because both names follow the same naming pattern but diverge on a clear, region-identifying element, this tool treats them as likely different companies.

When this condition is not met (no shared part at all, or one name simply being a substring of the other), there is no positive evidence of being different companies, so the tool always returns unknown. The mere fact that two strings don't match or overlap is never, by itself, grounds for likely_different — string non-overlap is not evidence of being different entities. The reasons text distinguishes "no shared part at all" from "only a partial match" rather than using the same wording for both.

Confidence is capped at medium, and stays consistent with the verdict by construction

confidence has only two possible values: "medium" and "low". **"high" has been removed.** Since the 2006 enactment of the Companies Act abolished the similar-trade-name restriction, two unrelated companies can be registered under the same name as long as their head-office locations differ — so a match based on trade name alone can never justify strong confidence ("high"`) in principle.