Skip to main content
Glama
enesjakozh
WeatherXM

WeatherXM Pro MCP Server

Official
by WeatherXM
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

Servidor WeatherXM PRO MCP

Una implementación de servidor MCP que expone las API de WeatherXM PRO como herramientas MCP, lo que permite a los clientes acceder a datos, observaciones y pronósticos de la estación meteorológica a través del protocolo MCP.

Características

  • Obtener estaciones cercanas a una ubicación (latitud, longitud, radio)

  • Obtener estaciones dentro de un cuadro delimitador (latitud y longitud mínima/máxima)

  • Obtenga todas las estaciones disponibles

  • Obtenga la última observación para una estación específica

  • Obtener observaciones históricas de una estación en una fecha específica

  • Búsqueda de células H3 por nombre de región

  • Obtener estaciones en una celda H3 específica

  • Obtenga el pronóstico del tiempo (diario o por hora) para una celda H3 específica

  • Obtenga un pronóstico hiperlocal para una estación y una variable

  • Obtener el rendimiento del pronóstico (FACT) para una estación y una variable

  • Obtener la clasificación de pronóstico (FACT) para una estación

Related MCP server: Weather MCP Server

Prerrequisitos

  • Node.js y npm instalados

  • Una clave API válida de WeatherXM PRO

Configuración

Clona el repositorio en tu máquina local.

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

Instalación

Después de clonar el repositorio, debe instalar las dependencias y compilar el proyecto antes de ejecutar el servidor MCP.

npm install
npm run build

Configuración del servidor para clientes MCP

Esta es la configuración común para clientes MCP como Claude Desktop, Cursor, Windsurf Editor, VSCode y complementos como RooCode y Cline.

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

Reemplace "path to mcp" con la ruta real al servidor MCP o el nombre del paquete, y "your-api-key" con su clave API de WeatherXM PRO.

Nota: Si tiene otros servidores MCP en uso en el cliente, puede agregarlos al objeto mcpServers existente.

Escritorio de Claude

Siga los pasos a continuación para utilizar el servidor WeatherXM PRO MCP con el cliente Claude Desktop MCP:

  1. Edite el archivo de configuración de MCP ubicado en:

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

  2. Agregue la configuración del servidor WeatherXM PRO MCP bajo el objeto mcpServers .

  3. Reinicie Claude Desktop para aplicar los cambios.

  4. Ahora puede utilizar el servidor en Claude Desktop para ejecutar consultas en el servidor WeatherXM PRO MCP.

Cursor

Siga los pasos a continuación para utilizar el servidor WeatherXM PRO MCP con Cursor:

  1. Instale Cursor en su máquina.

  2. En Cursor, vaya a Cursor > Configuración del cursor > MCP > Agregar un nuevo servidor MCP global.

  3. Especifique la misma configuración que en la sección Configuración del servidor para clientes MCP.

  4. Guardar la configuración.

  5. Verá weatherxm-pro como un servidor agregado en la lista de servidores MCP.

  6. Ahora puede utilizar el servidor WeatherXM PRO MCP en Cursor para ejecutar consultas.

Editor de windsurf

Siga los pasos a continuación para utilizar el servidor WeatherXM PRO MCP con Windsurf Editor :

  1. Instale Windsurf Editor en su máquina.

  2. Vaya a Paleta de comandos > Panel de configuración MCP de Windsurf o Windsurf - Configuración > Avanzado > Cascada > Servidores de protocolo de contexto de modelo (MCP).

  3. Haga clic en Agregar servidor y luego en Agregar servidor personalizado.

  4. Agregue la configuración del servidor WeatherXM PRO MCP desde la sección Configuración del servidor para clientes MCP.

  5. Guardar la configuración.

  6. Verá weatherxm-pro como un servidor agregado en la lista de servidores MCP.

  7. Ahora puede utilizar el servidor WeatherXM PRO MCP en Windsurf Editor para ejecutar consultas.

Imagen de Docker

El servidor MCP se puede construir y ejecutar como un contenedor Docker.

Construir

docker build -t weatherxm-pro-mcp .

Correr

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

Reemplace "your-api-key" con su clave API de WeatherXM PRO real.

Consejos para la solución de problemas

  • Asegúrese de que la ruta al repositorio de su servidor MCP sea correcta en la configuración.

  • Verifique que su clave API de WeatherXM PRO esté configurada correctamente.

  • Compruebe que la configuración del cliente MCP coincida con la configuración del servidor.

  • Revise los registros para ver si hay errores o advertencias que puedan indicar problemas con el servidor MCP.

Licencia

Licencia 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.
    -