How do I use oyama-opendata-mcp?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@oyama-opendata-mcp Show me the population trend for Oyama City" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

oyama-opendata-mcp

by bishi-eava

Overview Schema Source Related Servers Discussions Admin

TypeScript

Hybrid

oyama-opendata-mcp

小山市オープンデータを 読取専用 で提供する MCP（Model Context Protocol）サーバ。 Code for Oyama プロジェクト。

ユーザーは Claude などの AI クライアントからこの MCP に接続し、「小山市の人口推移をグラフ化して」のような依頼で公開データを活用できます。 MCP 側は構造化データ（JSON）を返すだけで、可視化・分析は AI クライアント側が行います。

公開エンドポイント（稼働中）

https://mcps.code4oyama.org/opendata/

Claude（デスクトップ/web）のカスタムコネクタに上記URLを登録すれば、誰でも利用できます。公開版の実装とデプロイ手順は php/README.md を参照（さくらのレンタルサーバ + PHP）。ローカルで stdio 接続する場合は下記セットアップを参照。

Related MCP server: e-Stat MCP server

提供ツール（すべて参照系・書込み不可）

ツール	説明
`list_datasets`	提供中のデータセット一覧（収録月・行数を含む）
`list_areas`	絞り込みに使える地区名・地域名(大字町丁)の一覧
`get_population`	大字町丁別の総人口・男女別人口・世帯数（月次）。`fromYearMonth`/`toYearMonth`・`district`・`area` で絞り込み、`level`(area/district/city) で集計粒度を選択
`get_age_distribution`	5歳階級×男女別の年齢構成（人口ピラミッド用）。`yearMonth`（未指定で最新月）・`district`（未指定で市全体合算）
`get_metadata`	出典・ライセンス(CC BY)・帰属表示・収録月

データセットは2種類:

population … 大字町丁別の人口・世帯数（月次・2015〜2026の約2.5万行）
population_by_age … 地区別の5歳階級×男女の年齢構成（人口ピラミッド）

データ粒度は 月次 × 大字町丁別。level: "city" で市全体の人口推移、level: "district" で地区別、既定の area で町丁別の時系列が得られる。

セットアップ

npm install
npm run build

ローカル利用（stdio）

Claude Desktop などの設定例:

{
  "mcpServers": {
    "oyama-opendata": {
      "command": "node",
      "args": ["/絶対パス/oyama-opendata-mcp/dist/stdio.js"]
    }
  }
}

開発時は npm run dev。

リモート公開（Streamable HTTP）

npm run start:http   # http://localhost:3000/mcp  (PORT で変更可)

ステートレス構成なので Cloudflare Workers / Render / Fly.io などに載せやすく、利用者はエンドポイント URL を登録するだけで使えます。

データ更新（取り込み時に統合）

月次CSVは1ファイル1か月。これを取り込み時に1つの正規化JSON(data/population.json)へ畳み込む。現在 2015-01〜2026-06 の137か月・約2.5万行 を収録。

小山市オープンデータ（人口・世帯 → 大字町丁名別世帯数人口統計）から月次CSVをダウンロード
data/raw/ に置く（複数月まとめてOK）
統合を実行:

npm run update-data

data/raw/*.csv を全部読み、単一の時系列JSONを再生成する。年代によりフォーマットが混在するため、取り込み時に自動判別する:

エンコーディング: UTF-8 / Shift-JIS を自動判定
スキーマ: 標準系（地区名,地域名,総人口,男性,女性,世帯数／年月はファイル名）と旧系（基準年月日,行政区コード,大字町丁名,合計,男,女,世帯数／年月は基準年月日列、地区名なし）を吸収
桁区切り: "1,399" のような引用符付き数値にも対応
年齢別ファイル（5歳階級×男女）は別スキーマのため取り込み時にスキップ（ログ出力）

注: 旧系ファイルには地区名(district)が無いため、2022年以前の行は level: "district" 集計に含まれない。level: "city"（市全体）と area（町丁別）は全期間で利用可能。

ライセンス・出典

コード: MIT
データ: 小山市オープンデータ（CC BY 4.0）。出典表示「出典：小山市オープンデータ」
ポータル: https://www.city.oyama.tochigi.jp/opendata.php

Available Tools

5 tools

get_age_distribution年齢構成（人口ピラミッド）A

5歳階級×男女別の人口構成を返す。yearMonth未指定なら最新月、district指定で地区別、未指定で市全体に合算。人口ピラミッドの描画に使える。

ParametersJSON Schema

Name	Required	Description	Default
`district`	No	地区名で絞り込み（未指定なら市全体）
`yearMonth`	No	対象年月（未指定なら最新月）

TDQS

A4.5/5.0

Behavior4/5

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

No annotations provided, so description carries full burden. It explains aggregation logic and defaults, but does not mention read-only nature, rate limits, or response format.

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

Conciseness5/5

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

Two concise sentences with front-loaded main purpose. Every sentence adds value with no wasted words.

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

Completeness5/5

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

With 2 optional parameters, no output schema, and no annotations, the description fully covers the tool's behavior and usage context.

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

Parameters4/5

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

Schema coverage is 100%, but description adds meaningful context about defaults and aggregation behavior beyond the schema descriptions.

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

Purpose5/5

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

Description clearly states it returns population composition by 5-year age groups and gender, distinguishing it from sibling tools like get_population and list_areas.

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

Usage Guidelines4/5

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

Explicitly describes default behavior for optional parameters (latest month if yearMonth unspecified, district aggregation vs. city-wide) and mentions use case for population pyramid drawing. Does not mention when not to use or compare to alternatives.

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

get_metadata出典・ライセンス情報A

データの出典・ライセンス(CC BY)・帰属表示・収録月を返す。datasetId指定で特定データセットに絞れる。

ParametersJSON Schema

Name	Required	Description	Default
`datasetId`	No	データセットID（例: population）

TDQS

A4/5.0

Behavior3/5

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

With no annotations, the description carries full burden. It mentions what data is returned but does not discuss authorizations, rate limits, or side effects. Since it is a read operation, the basic purpose is clear, but deeper behavior is omitted.

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

Conciseness5/5

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

Two sentences, no wasted words. Front-loaded with the main purpose and then the optional filter. Highly efficient.

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

Completeness4/5

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

Given the simplicity (one optional param, no output schema, no annotations), the description covers the essential purpose and filter capability. It lacks output format details but is adequate for a straightforward metadata retrieval tool.

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 coverage is 100% with one parameter (datasetId) already described in the schema. The description restates that datasetId filters, adding no new semantic value beyond the schema.

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

Purpose5/5

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

The description clearly states the tool returns data source, license, attribution, and month. It specifies the verb 'returns' and the resource 'metadata'. It also implicitly distinguishes from siblings which are population/area/dataset list tools.

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

Usage Guidelines4/5

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

The description explains that datasetId can filter to a specific dataset, giving clear context for when to use the optional parameter. However, it does not provide explicit when-not-to-use guidance or compare with sibling tools.

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

get_population人口・世帯数（月次・町丁別）A

小山市の大字町丁別の総人口・男女別人口・世帯数を返す。期間(fromYearMonth/toYearMonth)・地区(district)・地域(area)で絞り込み、levelで集計粒度を選べる（area=町丁別 / district=地区別 / city=市全体）。人口推移のグラフ化はクライアント側で行う想定。

ParametersJSON Schema

Name	Required	Description
`area`	No	地域名(大字町丁)で絞り込み（例: 若木町１丁目）
`level`	No	集計粒度。既定は area（町丁別）
`district`	No	地区名で絞り込み（例: 小山）
`toYearMonth`	No	終了年月（含む）
`fromYearMonth`	No	開始年月（含む）

TDQS

A4.2/5.0

Behavior3/5

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

No annotations provided, so description bears full burden. It indicates the tool is read-only (returns data) and mentions client-side graph creation, but lacks details on authentication, rate limits, or side effects. Given the tool's nature, the disclosure is adequate but not comprehensive.

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

Conciseness5/5

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

Description is concise (3 sentences), front-loaded with purpose, and includes all key usage details without redundancy. Every sentence contributes meaningful information.

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

Completeness4/5

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

With no output schema, the description explains what data is returned (population, household counts) but not the format. Given the 100% schema coverage and clear parameter descriptions, it is mostly complete; lacking output structure is a minor gap.

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

Parameters4/5

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

Schema covers all 5 parameters with descriptions, but the description adds value by explaining level values ('area=町丁別 / district=地区別 / city=市全体') and implicitly clarifying how area and district serve as filters.

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

Purpose5/5

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

Description explicitly states it returns population and household counts by town for Oyama City, with filtering options. Clearly distinguishes from sibling tools like get_age_distribution and list_areas, which serve different purposes.

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

Usage Guidelines4/5

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

Describes filtering parameters (period, district, area, level) and aggregation granularity, providing context for when to use different levels. However, it does not explicitly state when to prefer this tool over alternatives like get_age_distribution.

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

list_areas地区・地域一覧A

絞り込みに使える地区名(地区名)と地域名(大字町丁)の一覧を返す。

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.7/5.0

Behavior2/5

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

No annotations are provided, and the description does not disclose behavioral traits such as read-only nature, rate limits, or side effects. It only states the return value, leaving potential concerns unaddressed.

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

Conciseness5/5

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

The description is a single sentence that immediately conveys the core purpose with no redundant information. It is appropriately sized and front-loaded.

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

Completeness4/5

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

Given no parameters and no output schema, the description is relatively complete for a simple list tool. However, it could specify whether the list is combined or separate and hint at return format, but it is adequate for the context.

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

Parameters5/5

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

With zero parameters and 100% schema coverage, the description adds meaningful context by explaining that the listed names are for filtering. Baseline for 0 params is 4, and this exceeds it.

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

Purpose4/5

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

The description clearly states it returns a list of district and area names for filtering, specifying the resource and its purpose. It is distinct from sibling tools like 'list_datasets' which list datasets, not areas.

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

Usage Guidelines3/5

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

The description implies usage when filtering is needed but provides no explicit guidance on when not to use it or alternatives. No exclusions or prerequisites are mentioned.

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

list_datasetsデータセット一覧A

提供中のデータセット一覧（収録月・行数を含む）を返す。

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.1/5.0

Behavior4/5

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

The description discloses that the tool returns a list with month and row count, implying a read-only operation. Since no annotations are provided, the description carries the full burden, and it adequately conveys the basic behavioral traits for a simple list tool.

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

Conciseness5/5

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

The description is a single sentence that is efficient and front-loaded with the key action and resource. No unnecessary words.

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

Completeness3/5

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

The description explains the return content but lacks information on ordering, pagination, or whether it returns identifiers beyond the list. Given no output schema, more detail on the structure would improve completeness.

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

Parameters4/5

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

With zero parameters and 100% schema coverage (trivially), the description does not need to add parameter information. The baseline for no parameters is 4, and the description meets that.

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

Purpose5/5

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

The description clearly states the tool returns a list of currently provided datasets with specific fields (month recorded and row count). It distinguishes from siblings which focus on specific data queries.

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

Usage Guidelines3/5

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

No explicit guidance on when to use this tool versus alternatives. While the purpose is clear, there is no mention of prerequisites or contexts where other tools would be preferable.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

5 tool updatesv0.1.0Jul 8, 2026
- First observedget_age_distribution
- First observedget_metadata
- First observedget_population
- First observedlist_areas
- First observedlist_datasets

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.2/5.0

Scored 2026-07-08 09:15 across 5 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: get_age_distribution returns age pyramids, get_population returns population counts, get_metadata returns source information, list_areas returns filtering options, and list_datasets returns available datasets. No overlap in functionality.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern using underscores: get_* for data retrieval and list_* for enumerations. The naming is predictable and readable.

Tool Count5/5

With 5 tools, the set is well-scoped for an open data MCP focused on population demographics. Each tool serves a necessary role without redundancy or unnecessary complexity.

Completeness4/5

The tool surface covers core operations: listing datasets and areas, retrieving age distribution and population data, and accessing metadata. Minor gaps exist (e.g., no direct tool for household composition), but the main query needs are addressed.

Maintenance

ActivityStale

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

geojp
io.github.55tarkun
MCP server for Japan geodata: cadastral lot numbers (chiban) and reverse geocoding, for AI agents.
Location Services Open Data Government Data
1
JP Bids AOAuth
io.github.sugukurukabe
Read-only MCP server for searching Japan government procurement bid information from the KKJ portal.
Government Data Search
2
ORANO MCP Server
io.github.infotik
Read-only MCP server exposing a user ORANO library to their own AI agent.
Note Taking Knowledge & Memory Search
1
operant-mcp A
io.github.saagpatel
Read-only MCP server for the OPERANT AI operating-agent calibration benchmark.
Autonomous Agents Agent Orchestration Testing & QA Tools
52

Related MCP Servers

estat-mcp
ajtgjmdjp
A
license
Not graded
quality
B
maintenance
MCP server for Japan's e-Stat (Government Statistics Portal). Search statistical datasets, retrieve data tables, and access metadata from official Japanese government statistics.
Updated 23 days ago (2026-08-23 08:23 UTC)
9
Apache 2.0
e-Stat MCP server
Government Data Open Data Research & Data
cygkichi
A
license
B
quality
F
maintenance
MCP server for accessing Japanese government statistics portal 'e-Stat' API, enabling language models to search and retrieve statistical data.
Updated a year ago (2025-04-19 15:45 UTC)
5
20
MIT
houjin-bangou-api-mcp
Government Data Search
yamayued
A
license
B
quality
D
maintenance
MCP server for the Japan National Tax Agency Corporate Number API, enabling corporate number lookup and search via local AI clients.
Updated 6 months ago (2026-03-13 04:22 UTC)
3
1
MIT
city-data-mcpofficial
Government Data Open Data
zencity-product
F
license
A
quality
D
maintenance
An MCP server that gives Claude deep access to US public data -- demographics, economics, crime, employment, weather, housing, transit, schools, budgets, and more across 30+ cities for government intelligence workflows.
Updated 5 months ago (2026-04-19 06:52 UTC)
28
-

oyama-opendata-mcp

公開エンドポイント（稼働中）

提供ツール（すべて参照系・書込み不可）

セットアップ

ローカル利用（stdio）

リモート公開（Streamable HTTP）

データ更新（取り込み時に統合）

ライセンス・出典

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

city-data-mcpofficial