e-Stat MCP

get_stats_data

Read-only

Retrieve statistical data from Japan's e-Stat government API using a table ID. Apply optional filters for region, time, and categories to narrow results.

Instructions

統計データを取得する.

Input Schema

TableJSON Schema

Name	Required	Description
`limit`	No	取得件数（デフォルト100件）
`cdarea`	No	地域コード（絞り込み用）
`cdtime`	No	時間軸コード（絞り込み用）
`cdcat01`	No	分類事項01のコード（絞り込み用）
`cdcat02`	No	分類事項02のコード（絞り込み用）
`cdcat03`	No	分類事項03のコード（絞り込み用）
`lvcat01`	No
`lvcat02`	No
`lvcat03`	No
`lvcat04`	No
`lvcat05`	No
`lvcat06`	No
`lvcat07`	No
`lvcat08`	No
`lvcat09`	No
`lvcat10`	No
`lvcat11`	No
`lvcat12`	No
`lvcat13`	No
`lvcat14`	No
`lvcat15`	No
`cnt_get_flg`	No	件数取得フラグ（Trueで有効）
`stats_data_id`	Yes	統計表ID
`start_position`	No	データ取得開始位置
`section_header_flg`	No	セクションヘッダ出力フラグ（Trueで出力、Falseで非出力）

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed14 schema fields changedv0.4.0Aug 25, 2026
- addedInput schema / additionalProperties
```
Added value: +false
```
- addedInput schema / properties / cdarea / description
```
Added value: +"地域コード（絞り込み用）"
```
- addedInput schema / properties / cdcat01 / description
```
Added value: +"分類事項01のコード（絞り込み用）"
```
- addedInput schema / properties / cdcat02 / description
```
Added value: +"分類事項02のコード（絞り込み用）"
```
- addedInput schema / properties / cdcat03 / description
```
Added value: +"分類事項03のコード（絞り込み用）"
```
- addedInput schema / properties / cdtime / description
```
Added value: +"時間軸コード（絞り込み用）"
```
- addedInput schema / properties / cnt_get_flg / description
```
Added value: +"件数取得フラグ（Trueで有効）"
```
- addedInput schema / properties / limit / description
```
Added value: +"取得件数（デフォルト100件）"
```
- addedInput schema / properties / section_header_flg / anyOf
```
Added value: +[
+  {
+    "type": "boolean"
+  },
+  {
+    "type": "null"
+  }
+]
```
- changedInput schema / properties / section_header_flg / default
```
Previous value: -falseNew value: +null
```
- addedInput schema / properties / section_header_flg / description
```
Added value: +"セクションヘッダ出力フラグ（Trueで出力、Falseで非出力）"
```
- removedInput schema / properties / section_header_flg / type
```
Removed value: -"boolean"
```
- addedInput schema / properties / start_position / description
```
Added value: +"データ取得開始位置"
```
- addedInput schema / properties / stats_data_id / description
```
Added value: +"統計表ID"
```
First observedDec 8, 2025

TDQS

C2/5.0

Behavior2/5

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

The annotations already declare readOnlyHint=true, so the description does not need to restate safety. However, the description adds no behavioral context beyond that, such as whether results are paginated, the format of the response, or the meaning of the many filter parameters. Given the annotations cover safety, the bar is lower, but the description still provides zero additional behavioral information.

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

Conciseness2/5

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

The description is a single short sentence, which is concise in length, but it is under-specified, not appropriately concise. It lacks any structured information about parameters, usage, or response behavior. Front-loading is irrelevant since there is nothing substantive to front-load.

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?

This tool has 25 parameters, an output schema, and complex filtering options, yet the description is a bare statement. It completely fails to convey essential information like what the tool returns, how to use the filter codes, the meaning of flags like cnt_get_flg or section_header_flg, and how this tool differs from siblings. Given the complexity, this is grossly incomplete.

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

Parameters1/5

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

With only 40% schema description coverage, the description is expected to compensate for the many undocumented parameters (especially the 15 lvcat parameters). It does not mention any parameter semantics at all. The description gives no clues about how codes like cdarea, cdtime, or lvcat01 should be formatted or used. This is a severe gap.

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 '統計データを取得する' (get statistical data) states a verb and a vague resource, but it does not clarify exactly what kind of statistical data (e.g., a specific data table vs. metadata vs. lists). It is not a tautology, but it fails to distinguish this tool from siblings like get_stats_list, get_stats_fields, or get_stats_data_csv, which likely have distinct purposes.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus the many sibling tools. There is no mention of typical use cases, required prerequisites, or how to choose between get_stats_data, get_stats_data_csv, or get_stats_data_bulk. The description is purely a one-line statement with no context.

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

Deploy Server