MCP server and CLI for the Japanese government e-Stat API 3.0
Server has 13 tools with complete JSON schemas and type definitions. All tools have descriptions (10-50 chars, mostly short). Tool annotations (readOnlyHint) are applied to 12/13 tools. However, descriptions are uniformly terse (e.g., '統計表情報を検索する.' = 'Search for statistical table information.'), providing minimal context for LLM selection. Parameter descriptions are present but generic ('分類事項01のコード(絞り込み用)' = 'Classification item 01 code (for filtering)') without explaining when/why to use them. No output schemas documented. Error handling is absent from visible code. Naming is verb-first and clear (get_*, search_*, post_*), following conventions well. Composition is reasonable, tools are single-purpose and chainable (search → get_meta_info → get_stats_data). No secrets exposed as parameters (API key via E_STAT_APP_ID env var). Overall: solid structural foundation, but descriptions lack LLM-optimization depth and output schemas are undocumented.
データカタログ情報を取得する.
データカタログ情報をCSVで取得する.
データセットを参照する.
統計表のメタ情報を取得する.
統計表のメタ情報をCSVで取得する.
統計データを取得する.
複数の統計表/データセットから統計データを一括取得する.
Descriptions are uniformly terse (10-50 chars) and lack LLM-optimization context. E.g., '統計表情報を検索する.' provides no guidance on when to use get_stats_list vs search_stats_by_keyword, or what the output structure is. Baseline for A+ tools is 50-200 chars with WHEN/WHY/WHAT guidance.
Parameter descriptions are generic and lack format/constraint guidance. E.g., 'cdcat01' is described as '分類事項01のコード(絞り込み用)' (Classification item 01 code for filtering) with no hint of valid format, length, or examples. Rubric requires 'The project key (2-10 uppercase letters, e.g. PROJ)' level detail.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 55 | 2025-06-18+ | v2 |
統計データをCSVで取得する.
統計分野コード一覧を返す.
統計表情報を検索する.
統計表情報をCSVで取得する.
データセットを登録する.
キーワードで統計表を検索する.
Output schemas are not documented in tool definitions. LLMs cannot plan downstream calls or extract fields without knowing what get_stats_list returns. Rubric baseline: 100% of A+ tools have documented return types.
No error handling guidance visible in tool definitions. If an API call fails (invalid stats_data_id, rate limit, network error), there is no recovery hint for the LLM. Rubric requires: 'User not found. Try search_users() with a partial name.' level guidance.
Duplicate tools for JSON vs CSV output (get_stats_list + get_stats_list_csv, get_meta_info + get_meta_info_csv, etc.). This forces LLMs to reason about format choice, wasting tokens. Better: single tool with optional 'format' enum parameter (json|csv).