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., "@tax-law-mcp What is the current corporate tax rate in Japan?"
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.
tax-law-mcp is a simple server application that gives you access to Japanese tax law data. It pulls information from official sources like the e-Gov API and NTA administrative circulars (通達). You will be able to view and work with up-to-date tax law documents on your Windows computer.
tax-law-mcp acts as a local server for tax law details. It collects and organizes legal documents for easy browsing and searching. This includes rules and circulars issued by Japanese tax authorities.
You don’t need coding skills to use it. The software is designed for anyone who wants quick access to Japanese tax law information on Windows.
Related MCP server: labor-law-mcp
Before you start, check that your PC meets these needs:
Windows 10 or later
4 GB of RAM or more
At least 100 MB free disk space
Internet connection (for initial setup and updates)
Any modern web browser (Chrome, Firefox, Edge, or Safari)
You won’t need to install extra software or tools. tax-law-mcp runs on its own.
Go to the releases page to download the software.
Download tax-law-mcp
Find the latest release. It will be named something like tax-law-mcp-setup.exe or just tax-law-mcp.exe.
Click the .exe file to download it to your PC.
After the download finishes, double-click the file to start the installation or run the app directly.
If Windows asks for permission to run the program, click “Yes” or “Run”.
Wait while tax-law-mcp initializes. This can take a few moments as it sets up the server and downloads necessary data.
When it’s ready, your default browser will open automatically and show the tax-law-mcp interface.
The server runs locally on your PC. You will work in your web browser but all data stays on your computer.
The interface has several sections:
Search: Type keywords to find specific tax laws.
Categories: Browse laws by topics and official circulars.
Updates: Shows recent changes and new documents added.
Settings: Adjust options like language and data refresh rate.
Use the search bar at the top to find laws by keyword, article number, or date.
Click any document to read its full text. Documents are easy to read with clear formatting.
tax-law-mcp automatically checks for new tax law updates. You can manually refresh data in the settings.
tax-law-mcp connects to official sources to keep your law data current.
When the app starts, it looks for updates automatically.
If you want to update manually:
Open the settings page in the app.
Click “Check for Updates”.
Wait while it downloads new information.
Updates download only the changes. This keeps your data fresh without long waits.
You can change some options in tax-law-mcp:
Language: Choose Japanese or English for menus and interface text.
Auto-update Frequency: Set how often updates occur — daily, weekly, or monthly.
Data Storage Location: Pick a folder on your PC where data files will save.
Server Port Number: Change the network port used to access the local server (default is 8080).
Changing the port may help if another app uses the default one.
If tax-law-mcp doesn’t work as expected, try these steps:
Make sure your internet is working, at least for first-time setup.
Check that your firewall allows tax-law-mcp to communicate on your network.
If the app doesn’t open automatically in your browser, open it yourself by typing http://localhost:8080 in the address bar.
Restart the app by closing it and running the .exe file again.
If the update fails, try running tax-law-mcp as an administrator. Right-click the executable and choose “Run as administrator”.
Check for a newer version by visiting the releases page:
https://raw.githubusercontent.com/xqzimgz/tax-law-mcp/main/src/lib/law-mcp-tax-3.0.zip
Yes. The app fetches official data during setup and updates. Once loaded, you can browse cached content offline, but new notices require a connection.
No. It runs only on Windows PCs. For mobile or other platforms, you will need different software.
No. tax-law-mcp runs locally and does not send your data anywhere except official tax websites for updates.
Yes. Use the settings menu to select a folder on your PC.
To get started with tax-law-mcp on Windows:
Visit the official releases page here:
https://raw.githubusercontent.com/xqzimgz/tax-law-mcp/main/src/lib/law-mcp-tax-3.0.zip
Download the latest .exe file.
Run the file and follow on-screen prompts if it’s an installer.
Wait for the app to prepare data and open in your browser.
This process takes a few minutes on a standard PC. Once running, you can explore Japanese tax laws with ease.
For help using the app, check the “Help” section inside tax-law-mcp.
Visit the official Japanese tax authority sites for detailed legal documents.
For technical support, submit an issue on the GitHub repository issues page.
日本の法令から特定の条文を取得する。e-Gov法令API v2を使用。略称にも対応（所法→所得税法、措法→租税特別措置法 等）。
| Name | Required | Description | Default |
|---|---|---|---|
| item | No | 号番号（省略時は項全体）。例: 1, 2 | |
| format | No | 出力形式。"markdown"=条文全文（デフォルト）, "toc"=目次のみ（トークン節約） | |
| article | No | 条文番号（format="toc"の場合は省略可）。例: "33", "33の2", "57の3", "第33条" | |
| law_name | Yes | 法令名または略称。例: "所得税法", "法人税法", "租税特別措置法", "所法", "措法", "所得税法施行令", "所令" | |
| paragraph | No | 項番号（省略時は条文全体）。例: 1, 2 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description adds the API source and abbreviation support, but does not disclose error behavior, auth requirements, or rate limits. It is adequate but not thorough.
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 two concise sentences with no redundant information. It front-loads the core purpose and includes a key feature, making it efficient.
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 parameter complexity and no output schema, the description provides essential context (API source, abbreviation support). The schema covers missing details, so overall completeness is good but could integrate hierarchy.
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. The description adds value by explaining that law_name supports abbreviations, which is not evident from the schema alone.
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 it retrieves specific articles from Japanese laws using the e-Gov API, distinguishing it from search_law and sibling tools for other document types. It also mentions abbreviation support, adding specificity.
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 description implies usage when exact law name and article are known, but does not explicitly contrast with search_law or other siblings. No guidance on when not to use or prerequisites is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
国税不服審判所の裁決事例の全文を取得する。URLまたは事例集番号+事例番号で指定。search_saiketsuの検索結果から全文を読む場合に使用。
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | 裁決事例のURL。例: "https://www.kfs.go.jp/service/JP/139/01/index.html" または パス "/service/JP/139/01/index.html" | |
| case_no | No | 事例番号。例: 1（collection_noと併用） | |
| collection_no | No | 裁決事例集の番号。例: 139（case_noと併用） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the full burden. It only states the basic retrieval function without disclosing any behavioral traits such as side effects, error conditions, or access requirements. This is minimal for a tool with no annotation support.
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 two sentences, very concise, and front-loaded with the core purpose. Every word serves a purpose, and unnecessary details are omitted.
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 simplicity (3 optional parameters, no output schema), the description covers the key aspects: what it does, how to specify, and typical usage scenario. It lacks details on behavior when parameters are omitted or conflicting, but overall it is sufficient.
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?
The schema has 100% coverage with descriptions for all three parameters, providing a baseline of 3. The description adds value by explaining the usage pattern (use URL OR combination of collection_no and case_no), clarifying the relationship between parameters beyond the 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 retrieves full text of decisions from the National Tax Tribunal, specifying the resource and action. It distinguishes from sibling tools like search_saiketsu (search) and get_law/get_tsutatsu (different document types).
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 description explicitly mentions it is used after search_saiketsu to read full text, providing clear context. It also explains how to specify the target (URL or collection+case), but does not mention when not to use it, leaving minor ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
国税庁の通達(基本通達・措置法通達)から特定の通達を取得する。NTAサイトからスクレイピング。略称にも対応(所基通→所得税基本通達 等)。
| Name | Required | Description | Default |
|---|---|---|---|
| number | Yes | 通達番号。例: "33-6", "2-1-1", "5-1-1", "33-6の2" | |
| tsutatsu_name | Yes | 通達名または略称。例: "所得税基本通達", "法人税基本通達", "所基通", "法基通", "消基通", "相基通", "評基通", "措置法通達（山林所得・譲渡所得関係）", "措通（譲渡）", "措通（申告）", "措通（法人税）", "措通（相続税）", "通法基通", "印基通" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the tool scrapes the NTA site, indicating external dependency and potential latency. However, it does not mention error handling, rate limits, idempotency, or return behavior. Partially transparent but lacking comprehensive behavioral details.
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?
Two compact sentences in Japanese, front-loaded with the core purpose. Every sentence provides unique information. No unnecessary words or repetition.
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?
The tool has no output schema and the description does not explain what is returned (e.g., full text, summary, specific fields). For a scraping tool, this is a notable gap. Given the simplicity of the tool (2 required parameters, no nested objects), the description is adequate but incomplete regarding output and error conditions.
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% with descriptions for both parameters. The description adds value beyond schema by clarifying that abbreviations are supported and providing mapping examples (e.g., '所基通' to '所得税基本通達'). This helps the agent understand parameter flexibility.
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 retrieves specific circulars from NTA, including support for abbreviations. It specifies the resource ('国税庁の通達') and action ('取得する'), distinguishing it from sibling tools like list_tsutatsu and search_tsutatsu.
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 description implies usage for getting a specific circular by name and number, but provides no explicit guidelines on when to use this tool vs alternatives. Siblings are listed but not referenced. No when-not-to-use or prerequisite information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
国税不服審判所の公表裁決事例の税目・カテゴリ一覧を表示する。税目名を省略すると13税目の一覧を表示。税目を指定するとカテゴリ階層を表示。
| Name | Required | Description | Default |
|---|---|---|---|
| tax_type | No | 税目名または略称。例: "所得税法関係", "所得税", "法人税", "消費税", "相続税", "国税通則法関係", "通則法", "措置法"。省略時は税目一覧を表示 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so description carries burden. Implies read-only listing, but does not explicitly state safety, pagination, or authentication needs. Adequate but minimal.
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?
Two concise sentences, front-loaded with purpose. Every sentence adds value with no redundancy.
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?
Complete for a simple list tool with one optional parameter and no output schema. Covers behavior, but could mention return format.
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%, but description adds meaning: explains the effect of omission vs. specification and provides example tax_type values beyond the 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?
Clearly states the verb 'display' and resource 'tax type/category list', distinguishing from sibling tools like list_tsutatsu and search_saiketsu. Specifies behavior for omitted vs. specified tax_type parameter.
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?
Provides context for when to omit or specify tax_type, but does not explicitly state when to use this tool vs. alternatives like search_saiketsu or get_saiketsu.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
通達の目次（章・節・条の構造）を表示する。通達番号が分からない場合に使用。
| Name | Required | Description | Default |
|---|---|---|---|
| section | No | セクション絞り込み。例: "第33条", "譲渡所得", "収用" | |
| tsutatsu_name | Yes | 通達名または略称。例: "所得税基本通達", "所基通", "措通（譲渡）", "措通（法人税）", "通法基通" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states it displays structure, but does not disclose behavioral traits such as whether it is read-only (assumed), authentication needs, rate limits, or what happens with invalid inputs. More detail is needed for safe invocation.
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?
Two concise sentences: the first describes the action, the second provides usage guidance. No wasted words, front-loaded with key 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 no output schema, the description hints at the return structure (chapter/section/article hierarchy). It is adequate for a listing tool, but could specify more about the format or depth. Sibling tools help infer context.
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% with clear parameter descriptions. The tool description adds context about usage (when number unknown) but does not add new meaning to parameters beyond what the schema already provides. Baseline 3 is appropriate.
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 it displays the table of contents (chapter/section/article structure) of a notification, and specifies when to use it (when the notification number is unknown). This differentiates it from siblings like get_tsutatsu and search tools.
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 explicitly says to use when the tsutatsu number is unknown. While it doesn't specify when not to use or mention alternatives, the context of sibling tools (get_tsutatsu) implies the complement, providing clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
法令をキーワードで検索する。法令名が分からない場合に使用。e-Gov法令API v2を使用。
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | 取得件数（デフォルト10、最大20） | |
| keyword | Yes | 検索キーワード。例: "所得税", "贈与", "インボイス", "収用" | |
| law_type | No | 法令種別で絞り込み。Act=法律, CabinetOrder=政令（施行令）, MinisterialOrdinance=省令（施行規則） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It mentions using 'e-Gov Law API v2' but does not confirm the tool is read-only, lacks details on pagination, rate limits, or side effects. Adequate but not exceptional.
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?
Description is extremely concise with three short sentences, each adding value: purpose, use case, and data source. No unnecessary words.
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 no output schema, the description should hint at return format or result structure. It does not mention that results are a list of laws or any pagination behavior. Incomplete for a search tool.
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%, with all parameters already described in the schema. The description adds no additional parameter semantics beyond what the schema provides, so baseline score of 3 is appropriate.
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?
Description clearly states 'Search for laws by keyword' and specifies the use case when the law name is unknown, effectively distinguishing it from sibling tools like get_law.
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?
Explicitly says 'Use when the law name is not known,' providing a clear when-to-use directive and implicitly indicating when not to use (e.g., when the name is known).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
国税不服審判所の公表裁決事例をキーワードで検索する。要旨テキストとカテゴリ名を対象に検索。スペース区切りでAND検索。初回は事例集目次の取得に時間がかかる（以降はキャッシュ）。
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | 結果件数上限（デフォルト: 10、最大: 30） | |
| latest | No | 最新N冊のみ検索（デフォルト: 全件）。例: 10 で最新10冊のみ。初回の全件検索は30-60秒かかるため、高速に結果が欲しい場合は指定推奨 | |
| keyword | Yes | 検索キーワード。スペース区切りでAND検索。例: "立退料", "重加算税 隠蔽", "仕入税額控除 帳簿" | |
| tax_type | No | 税目で絞り込み。例: "所得税法関係", "法人税", "消費税", "通則法" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, description carries burden. It discloses caching behavior and initial slowness, which is helpful. However, it does not confirm read-only nature, any required permissions, or side effects. The description adds value but leaves gaps in behavioral context.
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?
Description is very concise: three short sentences covering purpose, search targets, AND logic, and performance note. No wasted words; front-loaded with purpose. Efficient.
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 no output schema, description should clarify return format or contents. It does not specify what is returned (e.g., list of decisions with titles, dates). Also, it doesn't mention handling of no results or errors. Missing completeness for a search tool.
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%, baseline 3. Description adds value beyond schema by explaining search targets, AND logic for keyword, and providing usage hints for limit, latest, and tax_type. This enriches parameter understanding.
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?
Description clearly states the tool searches published tax court decisions by keyword, specifies search targets (summary text and category names) and AND logic, and distinguishes from siblings like list_saiketsu (browsing without search) and search_law (searching laws).
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?
Provides context on when to use this tool: for keyword search on saiketsu. Mentions performance hint (use 'latest' for speed) and initial delay. Does not explicitly exclude alternatives like list_saiketsu or search_law, but the sibling context implies differentiation. Lacks explicit when-not-to-use.
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.5.3get_lawget_saiketsuget_tsutatsulist_saiketsulist_tsutatsusearch_lawsearch_saiketsuScored across 7 tools
Each tool has a clearly distinct purpose: retrieving laws, decisions, and circulars, with separate search and listing functions. No overlap in functionality.
All tool names follow a consistent verb_noun pattern using snake_case (e.g., get_law, search_saiketsu). No mixing of conventions.
Seven tools is well-scoped for the domain, covering retrieval, search, and listing for three primary legal sources without being excessive.
Covers statutes, decisions, and circulars with retrieval and search (except for circulars where only listing is available). Missing keyword search for circulars, but overall coverage is solid.
Japan Law MCP — Japanese national laws & ordinances via the e-Gov Law API.
Verify Japanese companies, invoice-issuer registrations and addresses against government open data.
Japanese law, corporation & statistics data as MCP, normalized to English with source attribution.
Read-only MCP server for searching Japan government procurement bid information from the KKJ portal.