Summary: japan-data-mcp connects AI agents to 155 normalized Japanese government open datasets, letting you discover, inspect, search, and analytically query them via MCP tools.
Discover datasets (list_japan_datasets): keyword-search the 155-dataset catalog (English or Japanese) for dataset IDs, titles, record counts, and coverage years.
Inspect schemas (describe_japan_dataset): get exact columns, data types, historical time range, source ministry, and a sanitized sample record.
Fetch filtered records (search_japan_official_data): single-table lookups filtered by prefecture (romaji/kanji), 5-digit JIS municipality code, 13-digit corporate number, or free-text keyword, combined with AND.
Run cross-dataset analytics (execute_japan_megabank_sql): read-only DuckDB SELECT queries over 10.16M+ records with GROUP BY, SUM/AVG, and multi-table JOINs (requires MEGA tier or local DB).
Browse B2B bundles (list_flagship_b2b_bundles): 5 enterprise all-in-one ZIP packages with dataset counts, records, JPY pricing, discounts, and invoice availability.
Covered domains: procurement (GEPS), corporate tax registry, land valuation, healthcare/senior care, demographics & municipal finance, and GHG emissions.
Safe by design: all tools are read-only, idempotent, non-destructive; access via RapidAPI key (free BASIC tier up to MEGA).
Connects to the Japan Official Data Megabank API on RapidAPI, enabling AI agents to search, describe, and query Japanese public open datasets (procurement, corporate registry, land valuation, healthcare, demographics, GHG emissions) through RapidAPI endpoints.
japan-data-mcp)
Model Context Protocol (MCP) Server for Japanese Public Open Data (maintained independently by Japan Open Data Lab).
Connect Claude Desktop, Cursor, Windsurf, Cline, and LangChain agents directly to clean, standardized Japanese government open data.
Add the following to your Claude Desktop configuration file:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"japan-data-mcp": {
"command": "python",
"args": ["-m", "server"],
"env": {
"RAPIDAPI_KEY": "YOUR_RAPIDAPI_KEY_HERE"
}
}
}
}Add to .cursor/mcp.json:
{
"mcpServers": {
"japan-data-mcp": {
"command": "python server.py",
"env": {
"RAPIDAPI_KEY": "YOUR_RAPIDAPI_KEY_HERE"
}
}
}
}Related MCP server: ontario-data-mcp
Tool Name | Parameters | Description |
|
| Search and list across 155 normalized Japanese public datasets in English or Japanese. |
|
| Inspect schema definitions, historical time-series range, primary sources, and sample rows. |
|
| Fast targeted search filtered by English/Japanese prefecture name, 5-digit JIS code, or 13-digit Corporate ID. |
|
| Execute multi-table in-memory analytical DuckDB SQL queries across datasets (MEGA tier / local). |
Once connected, your AI assistant can execute prompts like:
"Using search_japan_official_data, find the top 5 central government tender awards in procurement related to AI or cloud infrastructure."
"Look up Tokyo's Minato-ku and Shibuya-ku in demographics and compare their per capita taxable income and aging rate."
"Use execute_japan_megabank_sql to calculate the total public procurement amount won by company with corporate_number '1010001008844'."
"Find all hospitals with more than 300 beds in Osaka from medical."
Government Procurement (GEPS): 2020โ2026 Nationwide central ministry contract awards (100% electronic disclosure archive).
Corporate Tax Registry: Nationwide registered commercial entities (13-digit NTA key, zero PII).
Land Valuation Benchmark (MLIT): 1983โ2026 (44-year archive) official land price points.
Healthcare & Senior Care: 220,000+ hospitals/clinics and 250,000+ nursing care welfare facilities.
Demographics & Public Finance: All 1,741 Japanese municipalities (taxable income, population, aging).
GHG Emissions: Mandatory industrial emission disclosures from Ministry of the Environment.
This MCP server connects to the live Japan Official Data Megabank API on RapidAPI.
BASIC Tier: Free ($0/mo, 50 requests/mo) for testing and development.
PRO / ULTRA / MEGA Tiers: High-volume quotas, 40+ year archives, and direct multi-table DuckDB SQL execution.
Get your API key at: RapidAPI Hub
๐ Interactive Google Colab Recipe (3 Minutes): Query sample Parquet datasets in browser via DuckDB.
๐ Python SDK & Starter Kit: Official client library and automated cross-domain analytics.
๐ค Hugging Face Showcase Dataset: Free downloadable Parquet samples across 7 major domains.
Independent Project: This MCP server is developed and maintained independently by Japan Open Data Lab.
Not Government Affiliated: This project is not endorsed by, operated by, or affiliated with the Government of Japan or any public ministry.
Source Attribution: All underlying public domain/CC BY data is cited with full attribution to original government ministries pursuant to the Government of Japan Standard Terms of Use (Version 2.0).
MCP Server Code: MIT License
Source Data: Government of Japan Standard Terms of Use v2.0 (CC BY 4.0 compatible).
Maintained by: Japan Open Data Lab (japan.opendata.lab@gmail.com)
Retrieve the exact column schema, data types, historical coverage range, primary government ministry source, and a representative sample record (including English 'prefecture_en' and 'city_en') for a single dataset. WHEN TO USE: Call this after 'list_japan_datasets' and before 'execute_japan_megabank_sql' or 'search_japan_official_data' to verify exact column names and data formats. WHEN NOT TO USE: Do not use this to search or filter multiple records (use 'search_japan_official_data' for filtered rows or 'execute_japan_megabank_sql' for aggregations).
| Name | Required | Description | Default |
|---|---|---|---|
| dataset_id | Yes | Exact dataset identifier obtained from 'list_japan_datasets' (lowercase snake_case, e.g., 'demographics', 'procurement', 'medical', 'renewable_energy', 'companies'). |
| Name | Required | Description |
|---|---|---|
| schema | No | Mapping of column names to their data types and formats. |
| dataset_id | No | The inspected dataset identifier. |
| sample_record | No | A single sanitized sample row demonstrating actual field values. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds useful behavioral context about what is returned (column schema, types, historical range, ministry source, sample record including prefecture_en/city_en), but says nothing about auth, rate limits, or failure modes.
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?
Front-loaded purpose followed by clearly labeled WHEN TO USE / WHEN NOT TO USE sections. Every sentence carries routing or content information with no filler.
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?
An output schema exists so return values need not be explained, yet the description still previews the payload and fully routes the agent in a 1-param, single-sibling-cluster tool. Nothing needed to call it correctly is missing.
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 description coverage is 100% and the single dataset_id param is fully documented in the schema, including the snake_case format and examples. The description adds only the 'single dataset' scope, so baseline 3 applies.
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?
States a specific verb (Retrieve) and resource (column schema, data types, coverage, sample record for a single dataset). It clearly distinguishes itself from search/filter and aggregation siblings by scoping to one dataset's metadata.
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?
Explicit WHEN TO USE (after list_japan_datasets, before execute/search to verify column names and formats) and WHEN NOT TO USE (not for searching/filtering rows or aggregations) with the exact sibling alternatives named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute a read-only DuckDB SQL SELECT query across all 155 mounted datasets (10.16M+ records). Enables complex aggregations (COUNT, SUM, AVG, GROUP BY) and multi-table JOINs using 'municipality_code' (5-digit JIS code) or 'corporate_number' (13-digit ID). Enforces AST validation (single SELECT only, max 10,000 rows). PREREQUISITE: Requires a MEGA tier subscription on RapidAPI or local database access; always call 'describe_japan_dataset' first to confirm table and column names. WHEN NOT TO USE: Do not use for simple single-table keyword or prefecture lookups (use 'search_japan_official_data' instead, which works on all tiers including BASIC) or for browsing available tables (use 'list_japan_datasets').
| Name | Required | Description | Default |
|---|---|---|---|
| sql | Yes | Single read-only DuckDB SQL SELECT statement. DDL/DML statements are rejected. Always include a LIMIT clause (e.g., 'SELECT prefecture_en, COUNT(*) AS cnt FROM medical GROUP BY 1 ORDER BY 2 DESC LIMIT 10'). |
| Name | Required | Description |
|---|---|---|
| rows | No | List of result row objects mapped by column name. |
| columns | No | Ordered list of column names in the query result. |
| row_count | No | Number of result rows returned by the SQL query. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so the bar is lower, yet the description adds real operational context beyond them: AST validation, single-SELECT enforcement, a 10,000-row cap, and an auth/tier prerequisite. These are constraints an agent cannot infer from the annotations or schema.
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?
Dense but front-loaded, with the core purpose first and labeled PREREQUISITE / WHEN NOT TO USE sections that scan well. It is on the long side and packs several facts per sentence, but each sentence carries distinct, actionable 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?
For a one-parameter, high-complexity query tool with an output schema already defined, this covers everything an agent needs: capability scope, join keys, row/statement limits, tier prerequisite, and sibling routing. No return-value explanation is required given the output schema.
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 the baseline is 3, but the description adds genuine meaning the schema lacks: the join keys 'municipality_code' (5-digit JIS) and 'corporate_number' (13-digit ID) and the read-only SELECT-only constraint. It stops short of documenting the LIMIT/validation interaction in detail, keeping it at 4.
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?
States a specific verb and resource ('Execute a read-only DuckDB SQL SELECT query') plus concrete scope (155 mounted datasets, 10.16M+ records) and capability envelope (aggregations, JOINs). It also distinguishes itself from siblings by naming search_japan_official_data and list_japan_datasets as the tools for other jobs.
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 routes the agent: a labeled PREREQUISITE block (MEGA tier or local DB, call describe_japan_dataset first) and a labeled WHEN NOT TO USE block that names two alternatives and the conditions selecting them. Nothing about when to pick this tool is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the 5 Flagship Enterprise All-in-One Data Bundles (BUNDLE-01 Real Estate, BUNDLE-02 Government Procurement, BUNDLE-03 Healthcare, BUNDLE-04 Renewable Energy/GX, BUNDLE-05 Municipal Finance/Resilience) with included dataset counts, total records, JPY pricing, discount rates, and qualified B2B invoice availability. WHEN TO USE: Use only when the user asks about bulk downloadable ZIP packages, enterprise pricing, or B2B invoice options. WHEN NOT TO USE: Do not use for listing individual API datasets (use 'list_japan_datasets') or querying actual data records (use 'search_japan_official_data').
| Name | Required | Description | Default |
|---|---|---|---|
| bundle_code | No | Optional exact bundle identifier from 'BUNDLE-01' to 'BUNDLE-05' (case-insensitive). If omitted, returns all 5 flagship bundles. |
| Name | Required | Description |
|---|---|---|
| total | No | Number of flagship bundles returned. |
| bundles | No | List of bundle metadata objects with bundle_code, title, datasets_included, records, and price_jpy. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description still adds real context by disclosing the bounded result set (exactly 5 bundles) and the field content returned (dataset counts, total records, JPY pricing, discount rates, B2B invoice availability). It omits pagination/rate-limit behavior, but the bounded cardinality removes most ambiguity.
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 opening sentence is front-loaded with the core scope, and the WHEN TO USE / WHEN NOT TO USE blocks are tightly structured and immediately scannable. The inline enumeration of all five bundle names is somewhat verbose, but it doubles as valid-value disambiguation rather than filler.
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?
For a one-parameter, read-only list tool with an output schema present, the description need not explain return structure. Between the scope statement, the usage routing, and the annotated safety profile, an agent has everything required to select and invoke it correctly.
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 description coverage is 100% and the single optional bundle_code parameter is fully documented in the schema, including the BUNDLE-01..BUNDLE-05 range and case-insensitivity. The description's enumeration of the five bundles reinforces the valid values but adds no syntax or semantics beyond what the schema already provides, so baseline 3 applies.
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?
States a specific verb and resource ('List the 5 Flagship Enterprise All-in-One Data Bundles') and enumerates the exact bundle codes and names, so an agent knows precisely what comes back. It also explicitly names the sibling tools it is not (list_japan_datasets, search_japan_official_data), making it trivially distinguishable from them.
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?
Contains explicit WHEN TO USE ('bulk downloadable ZIP packages, enterprise pricing, or B2B invoice options') and WHEN NOT TO USE clauses that route the agent to two named alternatives with their respective conditions. Nothing about selection is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Discover and list available dataset IDs, titles, record counts, and coverage years across all 155 official Japanese datasets in Japan Official Data Megabank (demographics, real_estate, procurement, companies, medical, renewable_energy, grid_capacity, etc.). WHEN TO USE: Call this tool first when you do not know the exact 'dataset_id' to query. NEXT STEP: Pass a discovered 'dataset_id' to 'describe_japan_dataset' to inspect columns, or directly to 'search_japan_official_data' to fetch rows. WHEN NOT TO USE: Do not use this tool to fetch actual data rows (use 'search_japan_official_data' instead) or B2B bulk product bundles (use 'list_flagship_b2b_bundles').
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of dataset catalog entries to return (1 to 155, default: 25). | |
| query | No | Optional case-insensitive keyword filter in English or Japanese to match dataset IDs or titles (e.g., 'procurement', 'hospital', 'solar', 'ๅ ฅๆญ', 'ๅป็'). If omitted, returns the top catalog entries. |
| Name | Required | Description |
|---|---|---|
| total | No | Total number of datasets available in the catalog. |
| datasets | No | List of matching dataset metadata objects containing dataset_id, title_en, records, and coverage. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered and the bar is lower. The description adds genuine context beyond them: the catalog returns metadata only (no rows), spans all 155 official datasets, and the coverage domains it indexes. It stops short of describing pagination/truncation behavior of the limit cap or how the default of 25 is chosen.
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 label-per-function structure (purpose, WHEN TO USE, NEXT STEP, WHEN NOT TO USE) is front-loaded and scannable, and the parenthetical domain list is informative rather than padding. It runs long, but each clause carries routing or scope information that an agent uses.
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?
With an output schema present the return fields need not be explained, and annotations carry the safety profile, so the description's job is routing and scope โ both fully delivered. Nothing an agent needs to select or invoke this catalog tool is missing.
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 description coverage is 100%, so both parameters (limit, query) are already documented in the schema, including the 1-155 range, default and bilingual keyword examples. The description adds no interpretation beyond the schema, so the baseline 3 applies.
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?
Opens with a specific verb and resource ('Discover and list available dataset IDs, titles, record counts, and coverage years') and scopes it precisely to the 155 datasets in the Megabank, even enumerating the covered domains. An agent can immediately distinguish this catalog tool from describe_/search_/SQL siblings.
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?
Explicit WHEN TO USE ('call this tool first when you do not know the exact dataset_id'), a NEXT STEP routing to describe_japan_dataset or search_japan_official_data, and a WHEN NOT TO USE that names both the row-fetching sibling and list_flagship_b2b_bundles. When/when-not/alternative routing is fully specified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch and filter actual data records from a single dataset using standardized parameters (prefecture name, 5-digit JIS municipality code, 13-digit corporate number, or free-text keyword). Multiple filters are combined using logical AND. WHEN TO USE: Use for fast, single-table record lookups and filtered sampling once you know the 'dataset_id'. WHEN NOT TO USE: Do not use for discovering dataset IDs (use 'list_japan_datasets'), inspecting column schemas (use 'describe_japan_dataset'), or performing cross-table JOINs and GROUP BY aggregations (use 'execute_japan_megabank_sql').
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Optional case-insensitive free-text substring search across company names, facility names, address fields, or contract titles (e.g., 'Cloud', 'Hospital'). | |
| limit | No | Maximum number of matching records to return (1 to 100, default: 10). | |
| dataset_id | Yes | Target dataset ID obtained from 'list_japan_datasets' (e.g., 'demographics', 'procurement', 'medical', 'companies', 'real_estate'). | |
| prefecture | No | Optional prefecture filter in English romaji or Japanese kanji (e.g., 'Tokyo', 'Osaka', 'Hokkaido', 'ๆฑไบฌ้ฝ'). Case-insensitive. | |
| corporate_number | No | Optional exact 13-digit Japan National Tax Agency corporate number string (e.g., '1000012010019') or 10-digit US SEC CIK. | |
| municipality_code | No | Optional 5-digit JIS municipality code string with leading zero preserved (e.g., '13101' for Chiyoda-ku, '01101' for Sapporo). |
| Name | Required | Description |
|---|---|---|
| count | No | Number of records returned or matched. |
| records | No | Array of normalized record objects matching the filter criteria. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the safety profile (readOnly, idempotent, non-destructive, closed-world), lowering the burden. The description adds genuine behavioral context beyond that: filters combine with logical AND and the operation is single-table and 'fast'. It stops short of discussing pagination or result shape.
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?
Front-loaded with the core action, then cleanly partitioned into labeled WHEN TO USE / WHEN NOT TO USE clauses. Every sentence earns its place 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?
An output schema exists, so return values need not be described. For a filtered single-dataset lookup, the description covers scope, filter semantics, and routing to all relevant alternatives. Nothing needed to call it correctly is missing.
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 the baseline is 3. The description enumerates the filter types (prefecture, 5-digit JIS code, 13-digit corporate number, keyword) but adds no format or edge-case detail beyond what the schema already documents.
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?
States a specific verb and resource ('Fetch and filter actual data records from a single dataset') and immediately scopes it to single-table work, explicitly contrasting with cross-table SQL and metadata tools. An agent can distinguish it from every sibling by name alone.
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 explicit WHEN TO USE and WHEN NOT TO USE sections, naming the exact alternative for each excluded case ('list_japan_datasets', 'describe_japan_dataset', 'execute_japan_megabank_sql'). The selecting condition ('once you know the dataset_id') is spelled out.
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.
v1.0.4describe_japan_dataset5 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / properties / dataset_id / descriptionPrevious value: -"Dataset identifier (e.g. 'demographics', 'procurement', 'medical', 'renewable_energy', 'companies')."New value: +"Exact dataset identifier obtained from 'list_japan_datasets' (lowercase snake_case, e.g., 'demographics', 'procurement', 'medical', 'renewable_energy', 'companies')."Output schema / properties / dataset_id / descriptionAdded value: +"The inspected dataset identifier."Output schema / properties / sample_record / descriptionAdded value: +"A single sanitized sample row demonstrating actual field values."Output schema / properties / schema / descriptionAdded value: +"Mapping of column names to their data types and formats."execute_japan_megabank_sql5 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / properties / sql / descriptionPrevious value: -"Read-only SQL SELECT query (e.g., SELECT prefecture, count(*) AS cnt FROM medical GROUP BY 1 ORDER BY 2 DESC LIMIT 10)."New value: +"Single read-only DuckDB SQL SELECT statement. DDL/DML statements are rejected. Always include a LIMIT clause (e.g., 'SELECT prefecture_en, COUNT(*) AS cnt FROM medical GROUP BY 1 ORDER BY 2 DESC LIMIT 10')."Output schema / properties / columns / descriptionAdded value: +"Ordered list of column names in the query result."Output schema / properties / row_count / descriptionAdded value: +"Number of result rows returned by the SQL query."Output schema / properties / rows / descriptionAdded value: +"List of result row objects mapped by column name."list_flagship_b2b_bundles4 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / properties / bundle_code / descriptionPrevious value: -"Optional bundle code filter (e.g., 'BUNDLE-01' through 'BUNDLE-05')."New value: +"Optional exact bundle identifier from 'BUNDLE-01' to 'BUNDLE-05' (case-insensitive). If omitted, returns all 5 flagship bundles."Output schema / properties / bundles / descriptionAdded value: +"List of bundle metadata objects with bundle_code, title, datasets_included, records, and price_jpy."Output schema / properties / total / descriptionAdded value: +"Number of flagship bundles returned."list_japan_datasets7 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / properties / limit / descriptionPrevious value: -"Maximum number of datasets to return (default: 25, max: 155)."New value: +"Maximum number of dataset catalog entries to return (1 to 155, default: 25)."Input schema / properties / limit / maximumAdded value: +155Input schema / properties / limit / minimumAdded value: +1Input schema / properties / query / descriptionPrevious value: -"Optional keyword in English or Japanese (e.g. 'procurement', 'hospital', 'solar', 'ๅ
ฅๆญ', 'ๅป็')."New value: +"Optional case-insensitive keyword filter in English or Japanese to match dataset IDs or titles (e.g., 'procurement', 'hospital', 'solar', 'ๅ
ฅๆญ', 'ๅป็'). If omitted, returns the top catalog entries."Output schema / properties / datasets / descriptionAdded value: +"List of matching dataset metadata objects containing dataset_id, title_en, records, and coverage."Output schema / properties / total / descriptionAdded value: +"Total number of datasets available in the catalog."search_japan_official_data11 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / properties / corporate_number / descriptionPrevious value: -"13-digit Japan National Tax Agency corporate number (or 10-digit US SEC CIK)."New value: +"Optional exact 13-digit Japan National Tax Agency corporate number string (e.g., '1000012010019') or 10-digit US SEC CIK."Input schema / properties / dataset_id / descriptionPrevious value: -"Target dataset ID (e.g., 'demographics', 'procurement', 'medical', 'companies', 'real_estate')."New value: +"Target dataset ID obtained from 'list_japan_datasets' (e.g., 'demographics', 'procurement', 'medical', 'companies', 'real_estate')."Input schema / properties / limit / descriptionPrevious value: -"Number of records to return (default: 10, max: 100)."New value: +"Maximum number of matching records to return (1 to 100, default: 10)."Input schema / properties / limit / maximumAdded value: +100Input schema / properties / limit / minimumAdded value: +1Input schema / properties / municipality_code / descriptionPrevious value: -"5-digit JIS municipality code with leading zero preserved (e.g., '13101', '01101')."New value: +"Optional 5-digit JIS municipality code string with leading zero preserved (e.g., '13101' for Chiyoda-ku, '01101' for Sapporo)."Input schema / properties / prefecture / descriptionPrevious value: -"Prefecture name in English or Japanese (e.g., 'Tokyo', 'Osaka', 'Hokkaido', 'ๆฑไบฌ้ฝ')."New value: +"Optional prefecture filter in English romaji or Japanese kanji (e.g., 'Tokyo', 'Osaka', 'Hokkaido', 'ๆฑไบฌ้ฝ'). Case-insensitive."Input schema / properties / q / descriptionPrevious value: -"Free-text search keyword (company name, facility name, contract title, etc.)."New value: +"Optional case-insensitive free-text substring search across company names, facility names, address fields, or contract titles (e.g., 'Cloud', 'Hospital')."Output schema / properties / count / descriptionAdded value: +"Number of records returned or matched."Output schema / properties / records / descriptionAdded value: +"Array of normalized record objects matching the filter criteria."v1.0.2list_flagship_b2b_bundles1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "bundles": {
+ "items": {
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "total": {
+ "type": "integer"
+ }
+ },
+ "type": "object"
+}v0.1.0describe_japan_datasetexecute_japan_megabank_sqllist_flagship_b2b_bundleslist_japan_datasetssearch_japan_official_dataScored across 5 tools
Each tool has a clearly distinct role (discover datasets, inspect schema, fetch rows, run SQL, list B2B bundles), and descriptions explicitly cross-reference WHEN NOT TO USE. The only mild overlap is between search_japan_official_data and execute_japan_megabank_sql, since both retrieve records, but the simple-lookup vs JOIN/aggregation boundary is well delineated.
All names follow a consistent snake_case verb_noun pattern (list_*, describe_*, search_*, execute_*). Minor inconsistency in the domain qualifier used (japan, japan_official, japan_megabank, flagship_b2b) and singular/plural switch between describe_japan_dataset and list_japan_datasets, but the convention is still predictable.
Five tools is well-scoped for a data-discovery-and-query server, and each earns its place covering a distinct stage of the workflow. No redundant or trivial tools, and nothing feels artificially padded.
The read-only lifecycle is well covered: discover datasets, inspect schema, fetch rows, run cross-table SQL, plus a B2B bundle listing. The main gap is the absence of an export/download or bundle-purchase action, but for a read-only query surface the coverage is essentially complete.
MCP server for Japan geodata: cadastral lot numbers (chiban) and reverse geocoding, for AI agents.
An MCP server that audits the fairness of construction and renovation estimates in Japan. Provides fair-price ranges, overcharge detection, and verifiable unit-cost data based on JCCDB (65,520 items across 402 categories, CC BY 4.0, DOI-backed).
Query, join, profile, clean and convert CSV/JSON/Parquet with server-side DuckDB over MCP.
Japanese law, corporation & statistics data as MCP, normalized to English with source attribution.