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., "@jp-zengin-name convert 株式会社ガイタメドットコム to Zengin half-width kana"
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.
Format, check and compare Japanese bank-transfer account names (振込名義・口座名義カナ) the way Japanese banks accept them. MCP server, CLI and Python library. Standard library only, no network, MIT.
A Japanese bank transfer carries the payee and payer name in a restricted set: half-width katakana, digits, A-Z, a few symbols and a half-width space. Small kana are written large, ー becomes -, ・ becomes ., and words like 株式会社 are replaced by an abbreviation whose parentheses depend on where the word sits: ｶ) at the start, (ｶ) in the middle, (ｶ at the end (rules as published by one broker). Get one of these wrong and the transfer file is rejected. Accounting software reports it as 「振込依頼人名に使用できない文字が含まれています。」 (example FAQ).
A language model asked to "convert to half-width kana" usually keeps the small kana, writes 株式会社 out in full, and counts ガ as one character when the bank counts two (ｶﾞ).
株式会社 ガイタメドットコム -> ｶ)ｶﾞｲﾀﾒﾄﾞﾂﾄｺﾑ
ガイタメドットコム株式会社 オキナワシシャ -> ｶﾞｲﾀﾒﾄﾞﾂﾄｺﾑ(ｶ)ｵｷﾅﾜｼｼﾔ
かぶしきがいしゃ にっぽんしょうじ -> ｶ)ﾆﾂﾎﾟﾝｼﾖｳｼﾞ
合同会社 ネクサス・ツールズ -> ﾄﾞ)ﾈｸｻｽ.ﾂ-ﾙｽﾞ
キャット・フード -> ｷﾔﾂﾄ.ﾌ-ﾄﾞ
山田 タロウ -> error E_KANJI_NEEDS_READING (chars: 山田)What it does:
maps 59 legal-entity, branch and business words (株式会社, 合同会社, 医療法人, 一般社団法人, 特定非営利活動法人, 営業所, 健康保険組合 ...) to the bank abbreviation with the start / middle / end rule, also when spelled out in kana (カブシキガイシャ)
makes small kana large, converts hiragana, full-width letters and digits, ー ・ and full-width spaces
returns the half-width form for the transfer file and a full-width form for display
counts length the way the file does (a voiced kana is two characters) and warns above 30 (configurable)
refuses kanji other than entity words and tells you which characters need a reading. It never guesses a reading
compares a statement name with a customer name for reconciliation (入金消込), ignoring abbreviations, spaces, punctuation and width, and tells you when the entity type differs (ﾕ) vs 株式会社)
Every message comes in English and Japanese.
{"mcpServers": {"jp-zengin-name": {"command": "python", "args": ["-m", "zenginname.server"], "cwd": "/path/to/jp-zengin-name"}}}Tool | Input | Returns |
|
|
|
|
|
|
|
|
|
All tools are read-only and offline.
Related MCP server: JP Invoice & Tax MCP
python -m zenginname "株式会社 にっぽんしょうじ" # JSON, exit 1 on error
python -m zenginname --file names.txt # TSV: input, zengin, ok/NG, codes
python -m zenginname.bench # score on the 30 test casesfrom zenginname import format_name, check_name, match_names
format_name("ホシ 税理士法人")["zengin"] # 'ﾎｼ(ｾﾞｲ'
check_name("ｶ)ﾆｯﾎﾟﾝ")["errors"][0]["code"] # 'E_SMALL_KANA'
match_names("ｶ)ｻｸﾗ", "サクラ株式会社")["match"] # Truedata/zengin_name_cases_v1.jsonl has 30 inputs and expected outputs (entity positions, spelled entities, small kana, width, ヴ, old kana, split dakuten). This package scores 30/30. A naive converter (NFKC, hiragana to katakana, katakana to half-width) scores 2/30. The rules and the cases were written together, so 30/30 shows consistency with the published rules, not accuracy on real bank files. Corrections from people who send transfers are welcome as Issues.
Errors: E_EMPTY E_KANJI_NEEDS_READING E_CHAR_NOT_ALLOWED E_SMALL_KANA. Warnings: W_TOO_LONG W_MERGED_ROW W_ENTITY_ONLY W_PARENS W_SPACES.
It does not read kanji. Pass the reading (the agent should ask the user or use the reading on file).
Banks differ in details (maximum length, some symbols). Rows that are blank in the source table (医療法人社団, 公益財団法人, 公立大学法人 ...) use the abbreviation of the row above and return W_MERGED_ROW; confirm with your bank.
It formats names only. It does not handle account numbers, bank codes or money.
振込名義(口座名義カナ)を、銀行の振込で通る形(全銀の半角カナ)に整える道具です。小さいカナを大きく、ー→-、・→.、株式会社などは位置で変わる略語(先頭 ｶ)・途中 (ｶ)・末尾 (ｶ)にします。濁点は1文字に数えて字数を確かめます。漢字の読みは推測しません(法人の種類の言葉だけ変換し、ほかの漢字は E_KANJI_NEEDS_READING で返します)。入金消込で、通帳の名義と取引先名が同じかも比べられます。標準ライブラリだけ・外部通信なし・MIT。
Validate a half-width Zengin name from a CSV or bank file: only allowed characters, no small kana, no full-width characters, spacing, length. Returns ok, length, errors, warnings, abbreviations found.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| max_length | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world behavior. The description adds useful behavioral context by enumerating the validation rules and the return fields (ok, length, errors, warnings, abbreviations), which annotations cannot convey.
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?
A single dense sentence front-loads the purpose and validation rules, then lists the return shape. It is efficient with little waste, though the list of checks is somewhat compressed.
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?
There is no output schema, and the description partly compensates by naming the return fields. However, for a two-parameter tool with zero schema coverage, it omits the meaning and effect of max_length and does not specify input formatting constraints, leaving gaps an agent would need filled.
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 0%, so the description must carry parameter semantics. It never mentions the max_length parameter at all, and only vaguely implies length checking for the name parameter, leaving both inputs largely undocumented.
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?
States a specific verb ('Validate') and resource ('half-width Zengin name') and lists the concrete checks performed, so the tool's function is immediately clear. It does not explicitly differentiate itself from the sibling tools zengin_name_format and zengin_name_match, which keeps it below a 5.
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 phrase 'from a CSV or bank file' and the title's 'already formatted' imply this is for checking existing names rather than formatting or matching them. However, the description never explicitly says when to use this versus zengin_name_format or zengin_name_match, so usage is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Turn a payee or payer name into the form Japanese banks accept in transfers (Zengin): half-width katakana, digits, A-Z and a few symbols; small kana made large (ッ->ﾂ, ャ->ﾔ), ー->-, ・->., legal-entity words replaced by the bank abbreviation with the position rule (株式会社 at the start 'ｶ)', in the middle '(ｶ)', at the end '(ｶ'). Accepts kana (hiragana or katakana, full or half width), Latin letters and digits, and legal-entity words in kanji or spelled out (カブシキガイシャ). It does NOT read other kanji: pass the reading. Returns ok, zengin (half-width), display (full-width), length (voiced kana count 2), entities, changes, errors, warnings (code, message in English and Japanese). 振込名義を全銀の形に整える。
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Name as kana reading, e.g. '株式会社 ニッポンショウジ' | |
| max_length | No | Warn above this many half-width chars (default 30, 0 = off) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description adds real context beyond that: it discloses the return shape (ok, zengin, display, length, entities, changes, errors, warnings), the meaning of 'length' as a voiced-kana count, and that warnings/errors carry English and Japanese messages. It does not cover truncation behavior against max_length, which is slightly relevant for a mutation-free but warning-emitting 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 purpose is front-loaded in the opening clause and every sentence carries transformation or I/O detail. It is a long run-on paragraph with example-level rules (ッ->ﾂ) that are dense but still earn their place as expectation-setting; a bulleted structure would have improved scanability.
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?
With only two parameters and no output schema, the description carries the return-value burden itself and does so by listing every response field plus the entity/change/warning vocabulary. Nothing an agent needs in order to call it correctly or interpret the result is missing.
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 coverage is 100%, so the baseline is 3; the description earns above baseline by specifying exactly which input scripts are accepted (hiragana/katakana in full or half width, Latin, digits) and that kanji legal-entity words must be spelled out. max_length is left entirely to the schema, which is acceptable given full 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 states a specific verb and resource ('Turn a payee or payer name into the form Japanese banks accept in transfers (Zengin)') and enumerates the exact transformations. It never names the siblings zengin_name_match or zengin_name_check, so an agent must infer that this is the conversion tool rather than the comparison or validation one.
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?
It gives one important usage constraint ('It does NOT read other kanji: pass the reading'), which tells the caller what input it cannot handle. However, there is no explicit guidance on when to choose this over zengin_name_match or zengin_name_check, so tool selection is only implied by the verb 'format'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Decide whether a payer name on a bank statement (half-width, abbreviated) and a customer name (kana reading) are the same, ignoring entity abbreviations, spaces, punctuation, small/large kana and width. Returns match, name_match, key_a, key_b, entity_a, entity_b, entity_type_differs (e.g. ﾕ) vs 株式会社), errors.
| Name | Required | Description | Default |
|---|---|---|---|
| a | Yes | ||
| b | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description discloses important matching behavior: abbreviations, spaces, punctuation, small/large kana, and width are ignored. It also lists return fields and mentions entity_type_differs with an example, though it does not discuss limitations such as false positives or ordering constraints.
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 front-loaded with the core decision task and then lists relevant return fields. It is compact and mostly free of waste, though the return-field list is dense and somewhat schema-like.
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?
For a two-string matching tool with no output schema, the description covers the matching rules, intended reconciliation context, and return fields. The main remaining gaps are explicit parameter mapping and guidance on sibling tools.
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 0%, and the description does not explicitly map parameters a and b to the payer name and customer name. It does describe the two conceptual name types and normalization semantics, which helps infer meaning, but the parameter mapping remains implicit.
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 states a specific verb and decision task: deciding whether two names are the same for payment reconciliation. It clearly describes the compared resources as a bank-statement payer name and a customer kana name, though it does not explicitly distinguish itself from the sibling format/check tools 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?
It gives a clear context for use: matching a bank statement payer name against a customer name for payment reconciliation. It does not explicitly state when to use this instead of zengin_name_format or zengin_name_check, nor does it provide exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0zengin_name_checkzengin_name_formatzengin_name_matchScored across 3 tools
Each tool targets a distinct action on Zengin names: matching two names, formatting a name into Zengin form, and validating an existing Zengin name. The boundaries between format (produce) and check (validate) are clear from the descriptions, so an agent can select the right tool without ambiguity.
All three tools follow the same predictable pattern: a shared `zengin_name_` prefix plus a distinct action verb (`match`, `format`, `check`). There is no mixing of conventions or vague verbs.
Three tools are well-scoped for a narrow domain focused on Japanese Zengin name handling. Each tool covers a distinct operation and none feels redundant or missing for the stated purpose.
The surface covers the core lifecycle: match payer/customer names, format names to Zengin standards, and validate Zengin names from files. Together these operations form a complete workflow for the domain without obvious gaps.
Japan data tools for AI agents: calendar (rokuyo), address, name splitting, corporate number lookup
Exact Japanese text & date tools: char count, business days with JP holidays, era, tax, units.
Normalize and romanize Japanese addresses, look up postal codes, count Japanese business days.
500+ deterministic tools for AI agents: math, conversion, validation, hashing, encoding, date/time.
