e-Stat MCP

get_stats_list

Read-only

Search Japanese government statistical tables by keyword, code, field, or year. Retrieve metadata for available statistics from the e-Stat API.

Instructions

統計表情報を検索する.

Input Schema

TableJSON Schema

Name	Required	Description
`limit`	No	取得件数（デフォルト10件、最大100件）
`gov_code`	No	政府機関コード
`open_years`	No	公開年（YYYY形式、範囲指定はYYYY-YYYY）
`stats_code`	No	政府統計コード（5桁または8桁）
`search_word`	No	検索キーワード（統計表名、調査名など）
`stats_field`	No	統計分野コード（2桁）
`survey_years`	No	調査年（YYYY形式、範囲指定はYYYY-YYYY）
`updated_date`	No	更新日（YYYY-MM-DD）
`start_position`	No	データ取得開始位置
`stats_name_list`	No	調査・集計の種類

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed11 schema fields changedv0.4.0Aug 25, 2026
- addedInput schema / additionalProperties
```
Added value: +false
```
- addedInput schema / properties / gov_code / description
```
Added value: +"政府機関コード"
```
- addedInput schema / properties / limit / description
```
Added value: +"取得件数（デフォルト10件、最大100件）"
```
- addedInput schema / properties / open_years / description
```
Added value: +"公開年（YYYY形式、範囲指定はYYYY-YYYY）"
```
- addedInput schema / properties / search_word / description
```
Added value: +"検索キーワード（統計表名、調査名など）"
```
- addedInput schema / properties / start_position / description
```
Added value: +"データ取得開始位置"
```
- addedInput schema / properties / stats_code / description
```
Added value: +"政府統計コード（5桁または8桁）"
```
- addedInput schema / properties / stats_field / description
```
Added value: +"統計分野コード（2桁）"
```
- addedInput schema / properties / stats_name_list / description
```
Added value: +"調査・集計の種類"
```
- addedInput schema / properties / survey_years / description
```
Added value: +"調査年（YYYY形式、範囲指定はYYYY-YYYY）"
```
- addedInput schema / properties / updated_date / description
```
Added value: +"更新日（YYYY-MM-DD）"
```
First observedDec 8, 2025

TDQS

C2.2/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The readOnlyHint annotation covers safety, but the description adds no behavioral context such as pagination, result limits, or what happens with no filters. For a tool with 10 parameters, this is minimal disclosure beyond the annotation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, short sentence, which is concise and front-loaded. However, it is so sparse that it lacks substantive utility, though conciseness itself is not penalized heavily.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (10 parameters) and the large sibling set, the description is far from complete. It provides no examples, no output description (though output schema exists), and no guidance on which parameters are commonly used together, making it inadequate for an agent to call this correctly without further discovery.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so parameters are fully documented in the schema. The description adds no additional meaning about parameter usage or relationships, but does not need to compensate since the schema is complete. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('検索する' / search) and resource ('統計表情報' / statistical table information), making its basic purpose clear. However, it does not differentiate from siblings like search_stats_by_keyword or get_stats_list_csv, leaving ambiguity about which search tool to select.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to use this tool versus alternatives. With 12 siblings including get_stats_list_csv, get_stats_data, and search_stats_by_keyword, the description provides no selection criteria or context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server