MCP server & REST API for Japanese tax law — e-Gov API, NTA 通達, KFS 裁決事例
The server defines 7 tools for accessing Japanese tax law data (laws, ordinances, rulings, case precedents). Tool names are verb-prefixed and appropriately specific. Input schemas are visible and mostly complete with types and descriptions. However, output schemas are NOT documented anywhere in the source code, descriptions lack LLM-optimization depth (many are Japanese-only, some lack actionable guidance), and error handling recovery paths are not specified. The server implements domain-appropriate functionality but falls short of production-grade tool definition standards.
条文取得 - 法令の特定の条文を取得する。法令名と条文番号を指定して、法令全文から特定の条文を抽出する。
裁決全文取得 - 国税不服審判所の裁決事例の全文を取得する。
通達取得 - 国税庁の通達(通牒)を番号で取得する。NTA通達原文を取得。
税目・カテゴリ一覧 - 国税不服審判所の裁決事例の税目およびカテゴリ階層を取得する。
通達目次表示 - 通達の全体目次またはセクション別目次を表示する。
法令キーワード検索 - 法令名またはキーワードで法令を検索する。e-Gov API v2 を使用。
裁決事例キーワード検索 - 国税不服審判所の公表裁決事例をキーワードで検索する。
No output schemas documented for any tool. Tools return data but LLMs cannot predict field names, types, or structure of responses. This violates pattern:tool and forces agents to infer response shape.
Tool descriptions are primarily in Japanese; English descriptions are minimal or missing. For LLM agents expecting English text, this creates interpretation ambiguity. Example: get_tsutatsu description is entirely Japanese '通達取得 - 国税庁の通達(通牒)を番号で取得する。NTA通達原文を取得。' with no English equivalent.
No error recovery guidance in descriptions. Tools call external APIs (e-Gov API v2, NTA scraping, KFS scraping) but descriptions do not indicate what to do if a lookup fails, if a law doesn't exist, or if external services are unreachable. Pattern:recovery-guide absent.
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 52 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 46 | - | v1 |
Parameter descriptions lack actionable constraints. Example: 'article' param in get_law has description '条文番号(例: 1, 33, 33_2, 第33条)。format=toc / format=suppl 指定時を除き必須。', in Japanese, contains example values (which LLMs tend to reuse literally), and lacks formal validation rules (e.g., regex pattern, min/max length).
Optional pagination support unclear. search_law and search_saiketsu accept 'limit' but no 'offset', 'page', or 'next_cursor' parameters visible. For tools returning lists of items, pattern:paginated-result requires explicit pagination to prevent context window overflow.
Tool composition assumes specific usage sequences. get_law requires 'law_name' and 'article', but users may not know the law_name (should call search_law first). Descriptions do not guide this dependency. Pattern:tool-chain guidance missing.
Inconsistent parameter naming across tools. get_saiketsu accepts 'url', 'collection_no', or 'case_no' (three mutually exclusive forms), but descriptions do not clarify which should be preferred, whether all three work equally, or what happens if multiple are provided.