Skip to main content
Glama
enesjakozh
WeatherXM

WeatherXM Pro MCP Server

Official
by WeatherXM
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

WeatherXM PRO MCP 服务器

MCP 服务器实现将 WeatherXM PRO API 作为 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 客户端的服务器配置

这是 MCP 客户端（例如 Claude Desktop、Cursor、Windsurf Editor、VSCode）以及插件（例如 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 服务器上运行查询。

光标

按照以下步骤将 WeatherXM PRO MCP 服务器与 Cursor 一起使用：

  1. 在您的机器上安装Cursor 。

  2. 在 Cursor 中，转到 Cursor > Cursor 设置 > MCP > 添加新的全局 MCP 服务器。

  3. 指定与 MCP 客户端的服务器配置部分相同的配置。

  4. 保存配置。

  5. 您将在 MCP 服务器列表中看到 weatherxm-pro 作为已添加的服务器。

  6. 您现在可以使用 Cursor 中的 WeatherXM PRO MCP 服务器来运行查询。

风帆冲浪编辑

按照以下步骤将 WeatherXM PRO MCP 服务器与Windsurf Editor一起使用：

  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

用您的实际 WeatherXM PRO API 密钥替换"your-api-key" 。

故障排除提示

  • 确保配置中 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.
    -