Skip to main content
Glama
enesjakozh
WeatherXM

WeatherXM Pro MCP Server

Official
by WeatherXM
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

WeatherXM PRO MCP サーバー

WeatherXM PRO API を MCP ツールとして公開する MCP サーバー実装。クライアントは MCP プロトコルを通じて気象観測所のデータ、観測、予報にアクセスできるようになります。

特徴

  • 場所の近くの駅を取得する（緯度、経度、半径）

  • 境界ボックス内のステーションを取得します（最小/最大緯度と経度）

  • 利用可能なすべてのステーションを取得する

  • 特定の観測所の最新の観測情報を取得する

  • 特定の日付の観測所の過去の観測データを取得する

  • 地域名でH3セルを検索

  • 特定のH3セル内のステーションを取得する

  • 特定の H3 セルの天気予報（毎日または毎時）を取得します

  • 観測所と変数のハイパーローカル予報を取得する

  • ステーションと変数の予測パフォーマンス（FACT）を取得します

  • 駅の予測ランキング（FACT）を取得する

Related MCP server: Weather MCP Server

前提条件

  • Node.jsとnpmがインストールされている

  • 有効なWeatherXM PRO APIキー

構成

リポジトリをローカル マシンにクローンします。

git clone https://github.com/WeatherXM/weatherxm-pro-mcp.git

インストール

リポジトリのクローンを作成した後、MCP サーバーを実行する前に依存関係をインストールしてプロジェクトをビルドする必要があります。

npm install
npm run build

MCP クライアントのサーバー構成

これは、Claude Desktop、Cursor、Windsurf Editor、VSCode などの MCP クライアントや、RooCode や Cline などのプラグインに共通する構成です。

{
  "mcpServers": {
    "weatherxm-pro": {
      "command": "npx",
      "args": [
        "-y",
        "path to mcp"
      ],
      "env": {
        "WEATHERXMPRO_API_KEY": "your-api-key"
      }
    }
  }
}

"path to mcp" MCP サーバーまたはパッケージ名への実際のパスに置き換え、 "your-api-key" WeatherXM PRO API キーに置き換えます。

注: クライアントで他の MCP サーバーを使用している場合は、それを既存のmcpServersオブジェクトに追加できます。

クロードデスクトップ

WeatherXM PRO MCP サーバーを Claude Desktop MCP クライアントで使用するには、以下の手順に従います。

  1. 次の場所にある MCP 設定ファイルを編集します。

    ~/Library/Application Support/Claude/claude_desktop_config.json

  2. mcpServersオブジェクトの下に WeatherXM PRO MCP サーバー構成を追加します。

  3. 変更を適用するには、Claude Desktop を再起動します。

  4. Claude Desktop のサーバーを使用して、WeatherXM PRO MCP サーバーでクエリを実行できるようになりました。

カーソル

Cursor で WeatherXM PRO MCP サーバーを使用するには、以下の手順に従います。

  1. マシンにCursorをインストールします。

  2. カーソルで、[カーソル] > [カーソル設定] > [MCP] > [新しいグローバル MCP サーバーの追加] に移動します。

  3. MCP クライアントのサーバー構成セクションと同じ構成を指定します。

  4. 設定を保存します。

  5. MCP サーバー リストに追加されたサーバーとして weatherxm-pro が表示されます。

  6. Cursor で WeatherXM PRO MCP サーバーを使用してクエリを実行できるようになりました。

ウィンドサーフィンエディター

Windsurf Editorで WeatherXM PRO MCP サーバーを使用するには、以下の手順に従います。

  1. マシンに Windsurf Editor をインストールします。

  2. コマンドパレット > Windsurf MCP 構成パネルまたは Windsurf - 設定 > 詳細 > カスケード > モデルコンテキストプロトコル (MCP) サーバーに移動します。

  3. 「サーバーの追加」をクリックし、次に「カスタム サーバーの追加」をクリックします。

  4. MCP クライアントのサーバー構成セクションから WeatherXM PRO MCP サーバー構成を追加します。

  5. 設定を保存します。

  6. MCP サーバー リストに追加されたサーバーとして weatherxm-pro が表示されます。

  7. Windsurf Editor で WeatherXM PRO MCP サーバーを使用してクエリを実行できるようになりました。

Dockerイメージ

MCP サーバーは Docker コンテナとして構築および実行できます。

建てる

docker build -t weatherxm-pro-mcp .

走る

docker run -d -p 3000:3000 -e WEATHERXMPRO_API_KEY="your-api-key" -e PORT=3000 weatherxm-pro-mcp

"your-api-key"を実際の WeatherXM PRO API キーに置き換えます。

トラブルシューティングのヒント

  • 構成内の MCP サーバー リポジトリへのパスが正しいことを確認します。

  • WeatherXM PRO API キーが正しく設定されていることを確認します。

  • MCP クライアント構成がサーバー設定と一致していることを確認します。

  • MCP サーバーの問題を示す可能性のあるエラーや警告がないかログを確認してください。

ライセンス

MITライセンス

Available Tools

8 tools
get_all_stationsD
ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

D1/5.0
Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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?

Tool has no description.

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?

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

get_forecast_for_cellD
ParametersJSON Schema
NameRequiredDescriptionDefault
forecast_cell_indexYesThe H3 index of the cell to get forecast for
forecast_fromYesThe first day for which to get forecast data (YYYY-MM-DD)
forecast_includeYesTypes of forecast to include
forecast_toYesThe last day for which to get forecast data (YYYY-MM-DD)

TDQS

D1/5.0
Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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?

Tool has no description.

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?

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

get_historical_observationsD
ParametersJSON Schema
NameRequiredDescriptionDefault
dateYesDate (YYYY-MM-DD) for historical observations
station_idYesThe unique identifier of the station

TDQS

D1/5.0
Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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?

Tool has no description.

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?

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

get_latest_observationD
ParametersJSON Schema
NameRequiredDescriptionDefault
station_idYesThe unique identifier of the station

TDQS

D1/5.0
Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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?

Tool has no description.

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?

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

get_stations_boundsD
ParametersJSON Schema
NameRequiredDescriptionDefault
max_latYesMaximum latitude of the bounding box
max_lonYesMaximum longitude of the bounding box
min_latYesMinimum latitude of the bounding box
min_lonYesMinimum longitude of the bounding box

TDQS

D1/5.0
Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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?

Tool has no description.

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?

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

get_stations_in_cellD
ParametersJSON Schema
NameRequiredDescriptionDefault
cell_indexYesThe H3 index of the cell to return stations for

TDQS

D1/5.0
Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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?

Tool has no description.

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?

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

get_stations_nearD
ParametersJSON Schema
NameRequiredDescriptionDefault
latYesLatitude of the center of the area
lonYesLongitude of the center of the area
radiusYesRadius in meters for which stations are queried

TDQS

D1/5.0
Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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?

Tool has no description.

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?

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

search_cells_in_regionD
ParametersJSON Schema
NameRequiredDescriptionDefault
region_queryYesThe name of the region to search for cells

TDQS

D1/5.0
Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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?

Tool has no description.

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?

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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. 8 tool updatesv1.0.0
    • First observedget_all_stations
    • First observedget_forecast_for_cell
    • First observedget_historical_observations
    • First observedget_latest_observation
    • First observedget_stations_bounds
    • First observedget_stations_in_cell
    • First observedget_stations_near
    • First observedsearch_cells_in_region
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

C2/5.0

Scored across 8 tools

Disambiguation4/5

Most tools have clearly distinct purposes focused on different aspects of weather data retrieval (stations, forecasts, observations, cells), though get_stations_in_cell and get_stations_near could potentially overlap in some use cases. The lack of descriptions creates some uncertainty, but the naming suggests reasonable separation.

Naming Consistency5/5

All tools follow a perfect verb_noun pattern with consistent snake_case naming throughout. Every tool starts with 'get_' or 'search_' followed by a clear object, creating excellent predictability and readability.

Tool Count5/5

With 8 tools, this server is well-scoped for a weather data service. The count allows comprehensive coverage of station management, forecasting, and observation retrieval without becoming overwhelming or redundant.

Completeness3/5

The server covers core weather data retrieval operations well (stations, forecasts, observations), but lacks any write/update capabilities that might be expected for a 'Pro' service. There are also no tools for managing user preferences, alerts, or more advanced analytics, creating some workflow gaps.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • MCP Server

    Sandeep-Petwal
    A
    license
    Not graded
    quality
    D
    maintenance
    This MCP server provides tools like weather lookup and follows the Model Context Protocol for tool calling, resource sharing, and prompt templates.
    284 npm
    MIT

  • weather-mcp-server

    raviraval79
    A
    license
    Not graded
    quality
    D
    maintenance
    An MCP server that wraps the Open-Meteo API to provide current weather, forecasts, and historical data for any location without requiring an API key.
    MIT

  • mcp-poc

    BhavanG
    F
    license
    Not graded
    quality
    D
    maintenance
    A proof-of-concept MCP server that provides weather information using the Open-Meteo API, with tools for greeting, getting weather by coordinates, and by location name.
    -