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 키

구성

저장소를 로컬 컴퓨터에 복제합니다.

지엑스피1

설치

저장소를 복제한 후에는 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 개체에 추가할 수 있습니다.

클로드 데스크탑

Claude Desktop MCP 클라이언트와 함께 WeatherXM PRO 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. 컴퓨터에 커서를 설치하세요.

  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 서버를 사용하여 쿼리를 실행할 수 있습니다.

도커 이미지

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