Skip to main content
Glama
yukit7s

Tokyo WBGT MCP Server

by yukit7s
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Tokyo WBGT MCP Server

東京都のWBGT（暑さ指数）予測データを取得するModel Context Protocol (MCP) サーバーです。環境省の公式データを使用して、東京都内の複数観測地点からWBGT予測値と実測値を提供します。

🌡️ 機能

利用可能なツール

  1. get_tokyo_wbgt_forecast

    • 指定した東京都内観測地点のWBGT予測値を取得

    • 対応地点: tokyo, hachioji, fuchu, nerima, ome, ogochi, edogawa

  2. get_all_tokyo_locations

    • 東京都内の全WBGT観測地点の予測値を一括取得

  3. get_tokyo_realtime_data

    • 東京都の実測WBGT値を取得（実測地点のみ）

    • 指定した年月のデータを取得可能

📍 観測地点

地点名

地点番号

実測データ

東京（小石川植物園）

44132

✅

八王子

44112

❌

府中

44116

❌

練馬

44071

❌

青梅

44056

❌

小河内

44046

❌

江戸川臨海

44136

❌

Related MCP server: JMA Data MCP

🚀 インストール

# 依存関係をインストール
npm install

# TypeScriptをビルド
npm run build

💻 使用方法

MCPクライアントでの設定

Claude Desktop等のMCPクライアントの設定ファイルに以下を追加：

{
  "mcpServers": {
    "tokyo-wbgt": {
      "command": "node",
      "args": ["path/to/tokyo-wbgt-mcp-server/build/index.js"]
    }
  }
}

スタンドアロン実行

# プロダクション実行
npm start

# 開発モード
npm run dev

📊 データソース

  • 予測データ: 環境省熱中症予防情報サイト

    • URL: https://www.wbgt.env.go.jp/prev15WG/dl/

  • 実測データ: 環境省実測地点データ

    • URL: https://www.wbgt.env.go.jp/mntr/dl/

🌡️ WBGT（暑さ指数）について

WBGTは気温、湿度、輻射熱を考慮した熱中症予防のための指標です。

🚦 危険度レベル

レベル

温度範囲

状態

対応

🟢 安全

< 21°C

通常の活動が可能

-

🟡 注意

21-25°C

積極的な水分補給

こまめな水分補給

🟠 警戒

25-28°C

積極的な休憩・水分補給

定期的な休憩と塩分補給

🔴 厳重警戒

28-31°C

激しい運動は中止

運動の中断を検討

🟣 危険

≥ 31°C

運動は原則中止

すべての運動を中止

📋 レスポンス例

予測データ

{
  "locationId": "44132",
  "locationName": "東京（小石川植物園）",
  "prefecture": "東京都",
  "updateTime": "2025/06/23 19:25",
  "forecasts": [
    {
      "datetime": "2025/06/23 21:00",
      "wbgt": 24.0,
      "status": "注意"
    },
    {
      "datetime": "2025/06/24 00:00",
      "wbgt": 25.0,
      "status": "警戒"
    }
  ]
}

実測データ

{
  "location": "東京（実測地点）",
  "prefecture": "東京都",
  "data": [
    {
      "datetime": "2025/6/23 17:00",
      "wbgt": 24.5,
      "status": "注意"
    }
  ]
}

🔧 開発

プロジェクト構造

src/
├── index.ts          # メインサーバークラス
├── types.ts          # TypeScript型定義
├── constants.ts      # 定数・設定値
├── utils.ts          # ユーティリティ関数
└── wbgt-service.ts   # WBGTデータ取得サービス

必要な依存関係

  • Node.js 18+

  • TypeScript 5+

  • @modelcontextprotocol/sdk

開発コマンド

# 開発環境での実行
npm run dev

# ビルド
npm run build

# プロダクション実行
npm start

⚠️ 注意事項

  • データは環境省の公式システムから取得されるため、サーバーのメンテナンス時には利用できない場合があります

  • 実測データは東京地点（小石川植物園）のみ提供されます

  • 予測データは1時間毎に更新されます

  • 実測データは毎正時に更新されます

📜 ライセンス

MIT License

📚 データ利用について

このサーバーが使用するWBGTデータは環境省熱中症予防情報サイトから取得されます。データの利用については環境省の利用規約に従ってください。

🤝 貢献

プルリクエストやイシューの報告を歓迎します。バグ報告や機能要望がありましたらお気軽にお知らせください。

Available Tools

3 tools
get_all_tokyo_locationsB

東京都内の全WBGT観測地点の予測値を一括取得します

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

B3.2/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves predicted values in bulk, implying a read-only operation, but doesn't cover aspects like rate limits, authentication needs, data freshness, or error handling. For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.

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, efficient sentence in Japanese that front-loads the key information: it specifies the resource (all Tokyo WBGT observation points), the data type (predicted values), and the action (bulk retrieval). There is no wasted text, making it highly concise and well-structured.

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?

Given the tool's complexity (simple retrieval with no parameters) and lack of annotations or output schema, the description is minimally adequate. It covers the basic purpose but misses behavioral details like response format or limitations. Without an output schema, it should ideally hint at return values, but the simplicity of the tool keeps it from being severely incomplete.

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?

The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description adds no parameter information, which is appropriate here. Baseline is 4 for tools with zero parameters, as there's nothing to compensate for.

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 the tool's purpose: '一括取得します' (retrieves in bulk) for '東京都内の全WBGT観測地点の予測値' (predicted values for all WBGT observation points in Tokyo). It specifies both the action (retrieve) and resource (WBGT observation point predictions), though it doesn't explicitly differentiate from sibling tools like 'get_tokyo_realtime_data' or 'get_tokyo_wbgt_forecast' beyond the 'all locations' scope.

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 alternatives. The description mentions 'all locations' and 'predictions,' but it doesn't specify contexts, prerequisites, or exclusions relative to sibling tools like 'get_tokyo_realtime_data' (which might fetch real-time data) or 'get_tokyo_wbgt_forecast' (which could be for forecasts).

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

get_tokyo_realtime_dataC

東京都の実測WBGT値を取得します（実測地点のみ）

ParametersJSON Schema
NameRequiredDescriptionDefault
yearNo年（4桁）
monthNo月（1-12）

TDQS

C2.9/5.0
Behavior2/5

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

No annotations are provided, so the description carries full burden. It states what data is retrieved but doesn't disclose behavioral traits like whether this is a read-only operation, what permissions might be needed, rate limits, response format, or error conditions. For a data retrieval tool with no annotations, this is insufficient.

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?

Single sentence in Japanese that's front-loaded with the core purpose. No wasted words or redundant information. Appropriately sized for a simple data retrieval tool.

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

Completeness2/5

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

For a data retrieval tool with no annotations and no output schema, the description is incomplete. It doesn't explain what format the WBGT data returns in, what time granularity (hourly/daily), whether it includes location details, or how to interpret the values. The schema covers parameters well, but overall context is lacking.

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 the schema already documents both parameters (year and month) with descriptions, constraints, and defaults. The description doesn't add any parameter-specific information beyond what's in the schema, maintaining the baseline score.

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 the verb ('取得します' - get/retrieve) and resource ('東京都の実測WBGT値' - Tokyo's measured WBGT values), and specifies scope ('実測地点のみ' - measured locations only). It doesn't explicitly differentiate from sibling tools, but the focus on '実測' (measured) versus 'forecast' in one sibling provides some implicit distinction.

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 explicit guidance on when to use this tool versus alternatives like 'get_tokyo_wbgt_forecast' or 'get_all_tokyo_locations'. The description mentions '実測地点のみ' which implies measured data only, but doesn't state when to choose measured over forecast data or location listings.

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

get_tokyo_wbgt_forecastC

東京都のWBGT（暑さ指数）予測値を取得します

ParametersJSON Schema
NameRequiredDescriptionDefault
locationNo東京都内の観測地点（tokyo, hachioji, fuchu, nerima, ome, ogochi, edogawa）tokyo

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. It only states what the tool does (retrieves forecast data) without mentioning any behavioral traits like rate limits, authentication requirements, data freshness, or response format. For a data retrieval tool with zero annotation coverage, this is inadequate.

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, efficient sentence in Japanese that directly states the tool's purpose without any unnecessary words. It's appropriately sized and front-loaded with the core functionality.

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

Completeness2/5

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

Given no annotations and no output schema, the description is incomplete. It doesn't explain what format the forecast data returns, what time periods it covers, or any limitations. For a forecast retrieval tool, users need to know what kind of data to expect beyond just 'WBGT forecast values'.

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?

The description adds no parameter information beyond what's already in the schema (which has 100% coverage). The schema fully documents the single 'location' parameter with its enum values and default. The description doesn't provide additional context about parameter usage or meaning, so it meets the baseline for high schema coverage.

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 the tool's purpose: '東京都のWBGT（暑さ指数）予測値を取得します' (Get WBGT forecast values for Tokyo). It specifies the verb (取得/retrieve) and resource (WBGT forecast for Tokyo), but doesn't distinguish it from sibling tools like 'get_tokyo_realtime_data' which might provide current rather than forecast data.

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?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'get_all_tokyo_locations' or 'get_tokyo_realtime_data', nor does it explain when forecast data is preferable to real-time data or location listings.

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.

  1. 3 tool updatesv1.0.0
    • First observedget_all_tokyo_locations
    • First observedget_tokyo_realtime_data
    • First observedget_tokyo_wbgt_forecast
Deploy Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.5/5.0

Scored across 3 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: get_all_tokyo_locations retrieves predicted values for all observation points, get_tokyo_realtime_data gets measured values for actual observation points only, and get_tokyo_wbgt_forecast obtains forecast values. There is no overlap or ambiguity between these three functions.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern with 'get_' prefix and descriptive suffixes (all_tokyo_locations, tokyo_realtime_data, tokyo_wbgt_forecast). The naming is perfectly uniform and predictable throughout the set.

Tool Count5/5

Three tools is well-scoped for a Tokyo WBGT server focused on location data, real-time measurements, and forecasts. Each tool earns its place without redundancy, and the count is appropriate for the apparent domain scope.

Completeness4/5

The tools cover the core WBGT data retrieval needs (locations, real-time, forecasts) for Tokyo, with no obvious dead ends. A minor gap might be historical data or alerts, but agents can work effectively with the provided surface for typical weather/heat index queries.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • Japanese Weather MCP

    tsukiyama85
    A
    license
    Not graded
    quality
    D
    maintenance
    Provides weather information for 110 cities across Japan with natural language support for location names in kanji, hiragana, and katakana. Retrieves current weather conditions and forecasts using OpenMeteo API through MCP-compliant tools.
    1
    MIT

  • MCP-Weather

    Takatoshi-Miura
    F
    license
    Not graded
    quality
    C
    maintenance
    Enables retrieval of weather information for major cities across Japan using the Japan Meteorological Agency API. Supports weather overviews, precipitation probability, and wind speed data with both local and remote OAuth 2.0 authenticated deployment options.
    7
    -