Enables deployment of the MCP server as a Cloudflare Workers endpoint for remote access.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@tokyo-opendata-mcp search for evacuation center datasets"
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.
東京都オープンデータを AI が正しく扱えるようにする MCP サーバー。
単なる API プロキシではない。実データを調査して判明した「AI が誤解する罠」を、 ツールの応答に組み込んで返す。
東京都は 9,642 データセット・71,451 の API を公開しているが、AI から見ると 3 つの壁がある。
壁 | 実測 | このMCPの対応 |
検索が同義語を吸収しない | 「避難」で 96 件、「避難所」で 937 件（広い語ほど少ない逆転） | 表記ゆれを自動展開して並列に横断検索し統合 |
更新日が信用できない |
| 鮮度の誤認を警告し、本文から実際の基準日を抽出 |
API化＝クレンジングではない | 元CSVの空行がそのまま返る（先頭ページが空行のAPIも実在する） | 空行をスキップして要求件数まで読み進め、正確な |
Related MCP server: e-Stat MCP server
ツール | 説明 |
| 日常語で検索。行政用語への表記ゆれを自動展開 |
| 提供元・メンテナー・更新頻度・鮮度の警告 |
| 実データの行を取得（空行スキップ＋安全なページ送り） |
| CSV/Excel リソース一覧 |
$ get_dataset("t000003d0000000093")
title: 東京都防災マップ 避難所・避難場所一覧データ
maintainer: 東京都総務局総合防災部防災計画課 | 更新頻度: 不定期
metadata_modified: 2025-12-12T10:04:13
⚠️ warnings:
- metadata_modified が 2025-12-12 ですが、これはカタログ全体の一括移行日です
（全9,642件中7,118件が同日）。実データの鮮度ではありません。
- 本文に基準日の記載があります:「令和3年4月1日基準」。これが実際のデータ基準日です。更新日だけを見た AI は「2025年の最新データ」と誤認する。このMCPは2021年基準であることを伝える。
npm install && npm run buildClaude Code / Claude Desktop の設定に追加する:
{
"mcpServers": {
"tokyo-opendata": {
"command": "node",
"args": ["/absolute/path/to/tokyo-opendata-mcp/dist/stdio.js"]
}
}
}同じツール定義を Streamable HTTP で公開できる。
npx wrangler deployエンドポイントは https://<your-worker>.workers.dev/mcp（ヘルスチェックは /health）。
4層構成。層1〜3は fetch モックと InMemoryTransport によりネットワーク不要で、追加依存もない（node:test 標準ランナー）。
層 | 対象 | コマンド | ネットワーク |
1 | ロジック（同義語展開・空行スキップ・鮮度警告・リトライ） |
| 不要 |
2 | MCPプロトコル（ツール公開・zodバリデーション・isError） |
| 不要 |
3 | Remoteトランスポート（ |
| 不要 |
4 | 実データE2E（都のAPIに対する assert 付き検証） |
| 必要 |
検証している主な罠:
空行がページ境界をまたいでも要求件数まで読み進める／全ページ空行でも MAX_PAGES で必ず停止する
next_offset によるページ送りで行の重複・読み飛ばしが起きない
5xx は1回だけリトライし、4xx はリトライしない
検索変種の一部失敗は握りつぶさず note で通知される
バリデーション違反（-32602）はツールハンドラ実行前に拒否される
src/
tokyo.ts 東京都APIアクセス層（fetchのみ。Node/Workers 両対応）
tools.ts MCPツール定義（stdio と Remote で共有）
stdio.ts ローカル用エントリ
worker.ts Cloudflare Workers 用エントリ
test/
smoke.mjs 実データに対するE2Eテスト索引データ: tokyo-opendata-api-index — 5,611データセットの項目定義（CC BY 4.0）
東京都オープンデータカタログ: https://catalog.data.metro.tokyo.lg.jp/
MIT（コード）。取得されるデータは東京都オープンデータカタログの CC BY 4.0 に従う。 出典表示が必要である — 出典：東京都オープンデータカタログサイト
本リポジトリは東京都とは無関係の第三者による非公式なものである。
データセットIDから、提供元・メンテナー・更新頻度・リソース一覧を取得します。カタログの更新日は一括移行日である場合があるため、鮮度を誤認しないよう警告を付けて返します。
| Name | Required | Description | Default |
|---|---|---|---|
| dataset_id | Yes | データセットID（例: t000003d0000000093） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that catalog update date may be a batch migration date, returning a warning to prevent misjudgment of freshness.
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?
Two sentences, front-loaded with purpose, then behavioral warning. No wasted words.
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?
Given single parameter, no output schema, and no annotations, description covers what it returns and a key behavioral nuance. Could mention it is a read operation, but implied.
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% for the only parameter (dataset_id). Description adds an example but no new semantics beyond the schema description.
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?
Description clearly states verb (取得) and resource (dataset details: provider, maintainer, update frequency, resource list). Distinguishes from siblings 'search_datasets' and 'list_dataset_resources' by showing it provides full details for a specific ID.
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?
Implicitly indicates when to use: with a dataset ID to retrieve details. Sibling names provide context, but no explicit when-not or alternative conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
データセットに含まれるCSV/Excelリソースと、データ取得のためのヒントを返します。
| Name | Required | Description | Default |
|---|---|---|---|
| dataset_id | Yes | データセットID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It indicates the tool returns resources and hints, but does not disclose potential side effects, permissions, rate limits, or whether the list is exhaustive. Basic transparency, but lacks deeper behavioral context.
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?
Single sentence is concise and clear, but could be more structured (e.g., separating resource types and hints). No wasted words.
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?
Given the tool has one parameter, no output schema, and no annotations, the description adequately covers the purpose and output. Could be improved by specifying if resource IDs or names are returned, but it is sufficient for a simple list tool.
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% with dataset_id described. The description adds meaning beyond the schema by stating that the tool returns CSV/Excel resources and data acquisition hints, clarifying the output scope.
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?
The description clearly states 'データセットに含まれるCSV/Excelリソースと、データ取得のためのヒントを返します' which specifies the verb (返す/return), resource (CSV/Excel resources in dataset), and distinguishes it from siblings search_datasets and get_dataset by focusing on listing resources within a dataset.
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?
The description implies usage when you need to know the resources in a dataset, but does not explicitly state when to use or not use this tool versus siblings, nor provide context or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
東京都オープンデータカタログ（9,642データセット）を検索します。カタログの検索は同義語も表記ゆれも吸収しない（「避難」では937件中96件しかヒットしない）ため、このツールは複数の表記に自動展開して検索し、結果を統合します。
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | 返す最大件数 | |
| query | Yes | 検索したい内容。日常語でよい（例: 避難所, トイレ, こども） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the tool automatically expands queries to multiple notations and integrates results, which is a key behavioral trait beyond a simple search. It does not mention return format or pagination.
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?
Two sentences, front-loaded with purpose, immediate rationale in second sentence. No filler or redundant 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?
Considering no output schema, the description covers input semantics and behavioral traits well. Lacks details on result format or pagination, but adequate for a search tool with simple parameters.
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%. The description adds value for the query parameter by explaining that everyday language is acceptable and gives examples, which supplements the schema's description. For limit, the schema already provides sufficient detail.
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?
The description clearly states the tool searches the Tokyo Open Data Catalog (9,642 datasets) and distinguishes from sibling tools like get_dataset and list_dataset_resources by emphasizing its search capability with synonym expansion.
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?
The description explains that the native catalog search does not handle synonyms, so this tool is specifically useful for broader searches. It implicitly guides when to use this tool, though it doesn't explicitly mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool serves a distinct purpose: searching datasets, retrieving dataset metadata, and listing resources within a dataset. There is no overlap.
All tools use a consistent snake_case verb_noun pattern (search_datasets, get_dataset, list_dataset_resources), making their actions predictable.
Three tools are well-scoped for a focused server on Tokyo open data metadata. Each tool adds clear value without redundancy.
The tool set covers search, metadata retrieval, and resource listing, but lacks a direct tool to download or query the actual data files, relying on hints instead.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
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).
Hosted MCP server for live public-data APIs and Skills for AI agents.
MCP server that lets AI assistants use all OneSchema features exposed via the public API.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/bitpackman/tokyo-opendata-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
