This server does not currently have a deployable release on Glama. Follow the repository's setup instructions to install and configure it for your MCP client, including any required credentials and local dependencies.
Bango API の公式 MCP サーバーです。Claude・Cursor などの AI アシスタントに話しかけるだけで、日本の会社の法人番号・所在地・インボイス（適格請求書発行事業者）の登録状況を調べられます。
あなた：「サンプル商事って大阪の会社の法人番号わかる？」
AI ：bango_find_company で候補を探し、所在地とインボイスの登録状況まで答えます
あなた：「この請求書の T1180301018771、去年の10月1日時点で有効だった？」
AI ：bango_check_invoice でその日付時点の有効性を確認します
あなた：「この取引先リスト30社に法人番号を付けて」
AI ：bango_match_companies でまとめて名寄せし、確実な一致と要確認を分けて返しますツール | 使う場面 | 消費する枠 |
| 会社名（表記ゆれOK）から法人を探す。都道府県・郵便番号で絞り込み可 | API 1回 |
| 法人番号（13桁）か T番号から、正式名称・所在地・閉鎖の有無・インボイス登録状況を見る | API 1回 |
| T番号が有効か確かめる。最大20件まとめて、日付指定（その日時点）も可 | 1件につき API 1回 |
| 会社名の一覧（最大50件）に法人番号をまとめて付ける（名寄せ） | 名寄せ 1件につき1行 |
「株式会社／㈱」「全角／半角」「ハイフン入りの番号」などは自動で吸収します。
候補が複数あるときは、AI が勝手に1社に決めずにあなたへ確認するよう設計しています。
すべて読み取り専用です。データの変更や外部への送信は行いません。
Related MCP server: mcp-gbizinfo
bango-api.jp/signup で登録し、ダッシュボード で APIキーを発行します。Free プランは月500回まで、名寄せは月50件まで使えます（料金）。
Node.js 20 以上が必要です。
Claude Code
claude mcp add bango -e BANGO_API_KEY=あなたのAPIキー -- npx -y bango-mcpClaude Desktop（設定 → 開発者 → 設定を編集 で claude_desktop_config.json を開く）
{
"mcpServers": {
"bango": {
"command": "npx",
"args": ["-y", "bango-mcp"],
"env": { "BANGO_API_KEY": "あなたのAPIキー" }
}
}
}Cursor（~/.cursor/mcp.json またはプロジェクトの .cursor/mcp.json）
{
"mcpServers": {
"bango": {
"command": "npx",
"args": ["-y", "bango-mcp"],
"env": { "BANGO_API_KEY": "あなたのAPIキー" }
}
}
}VS Code・Windsurf など他の MCP クライアントも、同じ npx -y bango-mcp と環境変数 BANGO_API_KEY で動きます。
「トヨタ自動車の法人番号と本社所在地を教えて」
「T1180301018771 は今も有効？」
「この5社がインボイス登録しているか一覧にして：…」
「スプレッドシートの取引先名に法人番号を付けたい。要確認のものは候補も出して」
環境変数 | 必須 | 説明 |
| ○ | Bango API の APIキー |
| 接続先の上書き（既定 |
国税庁法人番号システム Web-API 機能および国税庁適格請求書発行事業者公表システム Web-API 機能を利用して取得した情報をもとに、Bango API が編集・加工して提供しています。内容は国税庁によって保証されたものではありません。
npm install
npm test # ユニットテスト（実際のAPIは呼びません）
npm run build # dist/ に出力
BANGO_API_KEY=... npx @modelcontextprotocol/inspector node dist/index.js # 手元で動作確認不具合や要望は Issues へ。お問い合わせ: support@bango-api.jp
Official MCP server for Bango API. It lets AI assistants identify Japanese companies by name (fuzzy matching) and look up corporate numbers (法人番号), addresses and qualified-invoice (T-number) registration status.
Tools: bango_find_company, bango_get_company, bango_check_invoice, bango_match_companies (all read-only).
claude mcp add bango -e BANGO_API_KEY=your_key -- npx -y bango-mcpGet a free API key at https://bango-api.jp/signup. License: MIT.
Check whether invoice registration numbers (適格請求書発行事業者の登録番号, T + 13 digits) are valid, for one or many numbers at once (up to 20). Typical use: verifying the T-number printed on an invoice or receipt before claiming input tax credit (仕入税額控除). Without date, checks validity as of today (JST) and also returns the registered name so the user can compare it with the invoice. With date (e.g. the invoice issue date), checks validity on that date; the name is not returned in that mode. A number with only 13 digits is treated as a T-number. Invalid or unknown numbers are reported per item and do not fail the whole call. Uses 1 API request per number.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | この日付時点で有効だったかを判定する（YYYY-MM-DD、2024/10/1 なども可）。省略時は今日 | |
| registration_numbers | Yes | 確認したい登録番号の配列（1〜20件）。例: ["T1180301018771"] |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive and openWorld, so safety is covered. The description nevertheless adds real value beyond them: per-item failures do not fail the whole call, the registered name is returned only in the no-`date` mode, and it costs 1 API request per number. Slightly short of 5 only because the exact response shape is not sketched.
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?
Roughly four sentences, front-loaded with the core purpose and format, then the use case, then the mode split, then failure and cost semantics. Every sentence carries information an agent needs to call it correctly; nothing is padding.
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 no output schema, the description still conveys the return behavior that matters (per-item results, registered name present only without `date`). Combined with the 100%-covered input schema and the safety annotations, an agent has everything needed to invoke and interpret the call.
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 baseline is 3, but the description goes beyond the schema by explaining that a bare 13-digit number is accepted as a T-number and that omitting `date` changes both the evaluation date (today, JST) and the returned fields. That is genuine semantic enrichment rather than repetition.
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 and resource ('check whether invoice registration numbers ... are valid') plus the exact format (T + 13 digits) and batch scope (up to 20). An agent can immediately distinguish this validation tool from the sibling company-lookup tools (bango_get_company, bango_match_companies).
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?
Gives an explicit typical use case (verifying the T-number before claiming input tax credit) and, crucially, tells the agent how to choose between the two modes: omit `date` for today's validity plus the registered name, or supply `date` for point-in-time validity with no name. There is no meaningful alternative tool, so no exclusion clause is needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find Japanese companies (法人) by name and return candidate corporate numbers (法人番号). Use this when the user gives a company name instead of a number, e.g. 「トヨタ自動車」「㈱サンプル 大阪」「sample shoji」. Name variants are absorbed automatically (株式会社/㈱/(株), full-width/half-width, spaces), so pass the name as the user wrote it; do not guess a 13-digit number. Narrow with prefecture when the user mentions a place. Results are ranked by score (0-1). If several candidates look plausible, ask the user which one they mean (show name and prefecture) instead of picking one. Then call bango_get_company with the chosen corporate_number for address and invoice status. Each call uses 1 API request from the user's Bango API quota.
| Name | Required | Description | Default |
|---|---|---|---|
| exact | No | true にすると表記ゆれを吸収したうえでの完全一致だけを返す。既定は部分一致（false） | |
| limit | No | 返す候補の数（1〜20、既定5） | |
| post_code | No | 郵便番号（7桁、ハイフン可）で絞り込む | |
| prefecture | No | 都道府県で絞り込む。「大阪」「大阪府」「27」「osaka」のどれでも可 | |
| company_name | Yes | 会社名（一部でも可）。例: 「サンプル商事」「株式会社サンプル」 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive/openWorld, and the description adds real behavioral context on top: normalization behavior (株式会社/㈱/(株), full-width/half-width, spaces are absorbed), score-based ranking from 0-1, and a per-call quota cost of 1 API request. The quota note and ambiguity protocol are things no annotation conveys.
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?
Front-loaded with purpose, then usage, then the handoff to bango_get_company, with no filler sentences. It is dense with multiple clauses (normalization, ranking, disambiguation, quota) but every sentence carries operational value.
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, yet the description tells the agent what comes back (ranked candidates with name/prefecture and corporate numbers) and what to do next. For a read-only search tool with five fully documented parameters, nothing needed for correct invocation 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 extra by telling the agent how to fill company_name (pass the name as the user wrote it, variants are absorbed automatically) and when to apply prefecture. It does not add anything beyond the schema for exact, limit, or post_code.
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 and resource ("Find Japanese companies (法人) by name") plus the return type (candidate corporate numbers). It is clearly distinguished from the sibling bango_get_company, which is named later as the by-number lookup step.
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?
Gives an explicit trigger (user supplies a name instead of a number) with concrete examples, an explicit prohibition (do not guess a 13-digit number), a refinement rule (narrow with prefecture), and a follow-up routing rule (call bango_get_company with the chosen corporate_number). It also specifies what to do with ambiguous results — ask the user instead of picking.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up one Japanese company or invoice issuer by its corporate number (法人番号, 13 digits) or invoice registration number (登録番号, 'T' + 13 digits). Hyphens, spaces and full-width digits are accepted, e.g. 「T1-1803-0101-8771」. Returns official name, kana, address, whether the company is still active (閉鎖の有無), and its invoice registration status (有効/失効/登録取消/未登録). T-numbers of sole proprietors (個人事業主) also work, but personal address is returned only if the person chose to publish it. If you only have a company name, call bango_find_company first. Uses 1 API request.
| Name | Required | Description | Default |
|---|---|---|---|
| number | Yes | 法人番号（13桁）またはインボイス登録番号（T+13桁） | |
| response_format | No | concise（既定）は要点だけ。detailed はAPIの全項目（英語名、変更履歴など）も含める |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent and non-destructive behaviour, yet the description still adds real value: input normalization rules (hyphens, spaces, full-width digits), the exact fields returned, active/closed status, and the four possible invoice registration states. It also discloses sole-proprietor behaviour and the cost ('uses 1 API request'), which is useful quota context an agent cannot get from annotations.
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 identity of the tool and accepted input formats, and each sentence carries distinct information (formats, returns, sole-proprietor caveat, fallback sibling, cost). It is dense with Japanese parentheticals, but nothing is genuinely redundant.
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 no output schema, the description compensates by enumerating the returned fields and the possible invoice status values. For a two-parameter read tool with full annotation coverage, an agent has everything needed to call it correctly and interpret the result.
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, but the description goes further by showing a concrete formatted example and confirming that punctuation and full-width characters are tolerated — details the schema does not state. It does not explain the response_format parameter, though the schema documents that adequately.
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 names a specific verb (look up) and resource (one Japanese company or invoice issuer) and states the two exact key formats it accepts. It is readily distinguishable from bango_find_company, which it explicitly identifies as the name-based alternative.
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 clearly states the input condition (you have a corporate number or T-number) and explicitly redirects to bango_find_company when only a company name is available. It does not clarify its relationship to bango_check_invoice, which also deals with invoice registration status, leaving one sibling overlap unresolved.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Match a list of company names (e.g. a customer list, sales list, or vendor master from a spreadsheet) to corporate numbers in one go (名寄せ). Each row gets a confidence: 'confident' (safe to use), 'review' (several close candidates; show them to the user), or 'unmatched'. Pass up to 50 names per call; adding a prefecture per row improves accuracy. The job usually finishes within seconds. If it is still running when this tool returns, call it again with the returned job_id (and no companies) to fetch the result; do not resubmit the list. Uses batch-row quota (Free plan: 50 rows per month). For a single company, bango_find_company is cheaper.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | No | 前回の呼び出しで返った job_id。結果の取得だけを行う | |
| companies | No | 会社名の配列（1〜50件）。文字列か {name, prefecture} の形 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive, so the description is free to add the operationally important details the annotations cannot express: asynchronous job completion within seconds, the poll-don't-resubmit rule, and quota consumption (batch-row quota, 50 rows/month on Free). It even explains the three confidence outcomes, which governs how the agent should act on results.
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?
Front-loaded with the purpose and immediately followed by the confidence vocabulary and the polling rule; every sentence carries information. It is a dense single paragraph that could be broken into bullets, but there is no filler to cut.
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 no output schema, the description still covers the result shape (per-row confidence levels and their meaning) and the retrieval flow. Combined with annotations and a fully documented schema, nothing an agent needs to call this correctly 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 baseline is 3, but the description adds real semantics beyond it: the 50-item cap, why prefecture is worth supplying, and critically that job_id is used with no companies to fetch an existing result — a mutual-exclusion rule the schema does not state.
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 and resource (match company names to corporate numbers in bulk, 名寄せ) and scopes the input source (customer/sales list, vendor master). It also distinguishes itself from bango_find_company by naming the single-company case, so an agent can pick the right tool without opening either schema.
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?
Gives explicit operating rules: up to 50 names per call, per-row prefecture improves accuracy, use bango_find_company for a single company, and when the job is still running call again with job_id only and do not resubmit. Alternatives and the when-not condition are both named.
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.
bango_check_invoicebango_find_companybango_get_companybango_match_companiesThis server cannot be deployed
Score is being calculated.
Verify Japanese companies, invoice-issuer registrations and addresses against government open data.
Search Japanese corporations and verify invoice numbers using official National Tax Agency data.
Japan data tools for AI agents: calendar (rokuyo), address, name splitting, corporate number lookup
Search Japanese company credit, financials, subsidies, and procurement via AI agents.
