Skip to main content
Glama
adrianR84

Weather-Open-Meteo-MCP

by adrianR84
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Remote

MCP Weather Server

A Model Context Protocol (MCP) server that provides hourly and daily weather forecasts using the Open-Meteo API.

Acknowledgment

This project is a fork of the original MCP Weather Server by Tim Luka Horstmann. The original version used AccuWeather API, and this fork has been migrated to use Open-Meteo API to provide free weather data access without API keys.

Related MCP server: Weather MCP Server

NPM Package

Available on npm as weather-open-meteo-mcp.

Quick Start

No API key required! Open-Meteo provides free access to weather data for non-commercial use.

Simply run the MCP Weather server directly with:

npx -y weather-open-meteo-mcp

Or, for HTTP/REST access via supergateway:

npx -y supergateway --stdio "npx -y weather-open-meteo-mcp" \
  --port 4004 \
  --baseUrl http://127.0.0.1:4004 \
  --ssePath /messages \
  --messagePath /message \
  --cors "*"

MCP Server Config Example

For integration with Claude Desktop or other MCP-compatible clients, add this to your config (e.g. claude_desktop_config.json):

{
  "mcpServers": {
    "weather": {
      "command": "npx",
      "args": ["-y", "weather-open-meteo-mcp"]
    }
  }
}

Overview

This MCP server allows large language models (like Claude) to access real-time weather data. When integrated with an LLM, it enables the model to:

  • Fetch accurate, up-to-date weather forecasts

  • Provide hourly weather data for the next 12 hours

  • Access daily weather forecasts for up to 15 days

  • Display data in both metric (°C) and imperial (°F) units

  • View temperature, conditions, precipitation information, and other weather details

Available Tools

Hourly Weather Forecast

  • Tool name: weather-get_hourly

  • Provides hourly forecasts for the next 12 hours

  • Parameters:

    • location (required): City or location name

    • units (optional): "metric" (Celsius, default) or "imperial" (Fahrenheit)

Daily Weather Forecast

  • Tool name: weather-get_daily

  • Provides daily forecasts for up to 15 days

  • Parameters:

    • location (required): City or location name

    • days (optional): Number of forecast days (1, 5, 10, or 15; default is 5)

    • units (optional): "metric" (Celsius, default) or "imperial" (Fahrenheit)

Prerequisites

  • Node.js ≥18

  • pnpm (recommended) or npm

Setup

  1. Clone this repository:

    git clone https://github.com/adrianR84/Weather-Open-Meteo-MCP.git
cd mcp-weather

  2. Install dependencies:

    Using pnpm (recommended):

    pnpm install

    Or using npm:

    npm install

  3. Build the project:

    npm run build

Usage with Claude Desktop

  1. Configure Claude Desktop to use this MCP server:

    • Open Claude Desktop

    • Go to Settings > Developer > Edit Config

    • Add the following to your claude_desktop_config.json:

    {
  "mcpServers": {
    "weather": {
      "command": "npx",
      "args": ["-y", "weather-open-meteo-mcp"]
    }
  }
}

  2. Restart Claude Desktop

  3. In a new conversation, enable the MCP server by clicking the plug icon and selecting "weather"

  4. Now you can ask Claude for weather forecasts, such as:

    • "What's the hourly weather forecast for New York City?"

    • "Give me the 5-day forecast for London."

    • "What will the weather be like in Tokyo this week in Fahrenheit?"

    • "Will it rain in San Francisco tomorrow?"

Development

  • Install dev dependencies: pnpm install

  • Lint your code: pnpm run lint

  • Build: pnpm run build

  • Run tests: pnpm test

  • Start in dev mode: pnpm run dev

(You can also use npm instead of pnpm if preferred)

Contributing

Contributions are welcome! Please feel free to submit a Pull Request to adrianR84/Weather-Open-Meteo-MCP.

Future Enhancements

We're always looking to improve the MCP Weather Server. Here are some features we're considering for future releases:

  • Extended Hourly Forecasts: Beyond 12 hours, e.g., 24 or 48 hours.

  • Weather Alerts: Integration with severe weather alerts.

  • Location Autocomplete: Enhanced location searching with autocomplete suggestions.

  • Historical Weather Data: Access to past weather conditions.

If you have ideas for other features, feel free to open an issue!

License

This project is licensed under the MIT License - see the LICENSE file for details.

Available Tools

2 tools
weather-get_dailyA

Get daily weather forecast for up to 15 days

ParametersJSON Schema
NameRequiredDescriptionDefault
daysNoNumber of days to forecast (1, 5, 10, or 15). Default is 5.
unitsNoTemperature unit system (metric for Celsius, imperial for Fahrenheit). Default is metric.
locationYesThe city or location for which to retrieve the weather forecast.

TDQS

A3.8/5.0
Behavior3/5

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

There are no annotations, so the description carries the behavioral transparency burden. It communicates a read-only forecast lookup via 'Get' and adds the 15-day maximum, but it does not disclose response shape, potential errors, timezone behavior, or whether any authentication is needed. For a simple read operation this is acceptable but not thorough.

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 sentence with no wasted words. It front-loads the verb and resource and immediately gives the key constraint of 15 days.

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

Completeness4/5

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

For a simple weather lookup with three fully documented parameters, the description is largely complete and an agent can invoke the tool correctly. The only notable gap is that there is no output schema and the description does not hint at the shape of the returned forecast payload.

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%: location, days, and units are all clearly documented in the input schema. The description adds no additional parameter meaning, which is acceptable because the structured schema already handles the documentation fully.

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

Purpose5/5

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

The description explicitly states the action ('Get'), the resource ('daily weather forecast'), and the scope ('up to 15 days'). This clearly distinguishes it from the sibling tool weather-get_hourly without requiring any additional inference.

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

Usage Guidelines3/5

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

The word 'daily' and the tool name imply that this is for day-level forecasts rather than hourly ones, which is useful context. However, the description does not explicitly state when to use this tool versus weather-get_hourly or provide any exclusion criteria.

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

weather-get_hourlyA

Get hourly weather forecast for the next 12 hours

ParametersJSON Schema
NameRequiredDescriptionDefault
unitsNoTemperature unit system (metric for Celsius, imperial for Fahrenheit). Default is metric.
locationYesThe city or location for which to retrieve the weather forecast.

TDQS

A3.8/5.0
Behavior3/5

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

With no annotations, the description carries the full burden of behavioral disclosure. It states the scope (hourly, next 12 hours) and implies a read-only operation, but does not mention return format, error behavior, or data source limitations. It is adequate but not rich.

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 concise sentence with no filler. It front-loads the core action and scope, making it easy for an agent to process quickly.

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

Completeness4/5

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

For a simple two-parameter tool, the description is largely complete: it states the forecast type, granularity, and time window. It does not describe the return payload, but no output schema exists and the tool's purpose is straightforward enough that an agent can infer expected weather data fields.

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 both parameters are already documented in the schema. The description adds no additional parameter-level details beyond what the schema provides, so the baseline score of 3 applies.

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

Purpose5/5

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

The description uses a specific verb ('Get') and resource ('hourly weather forecast') with a clear time bound ('next 12 hours'). This clearly distinguishes it from the sibling tool weather-get_daily, which is for daily forecasts.

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

Usage Guidelines3/5

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

The time range and 'hourly' granularity imply when to use this tool, but the description never explicitly names the alternative or states when to choose it instead. The guidance is present by inference, not direct instruction.

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. Dates show when Glama detected each change.

  1. 2 tool updatesv0.1.0
    • First observedweather-get_daily
    • First observedweather-get_hourly
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.9/5.0
Disambiguation5/5

The two tools are clearly separated by forecast granularity: one provides hourly data for the next 12 hours, the other provides daily data for up to 15 days. There is no meaningful overlap or ambiguity between them.

Naming Consistency5/5

Both tool names follow the same weather-get_{period} pattern, using the same verb and a consistent naming style. The only differences are the period suffixes, hourly and daily, making the pattern predictable and clear.

Tool Count3/5

Two tools is at the low end and feels thin for a weather server, though the pair does cover the two main forecast modes. The count is borderline rather than clearly insufficient.

Completeness3/5

The server covers hourly and daily forecasts, but lacks obvious weather-related capabilities such as current conditions, location search, or weather alerts. These are notable gaps that could force agents to work around the limited surface.

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • Weather MCP Server

    gmailhasan
    A
    license
    Not graded
    quality
    D
    maintenance
    Provides current weather data and hourly forecasts for any location worldwide using the Open-Meteo API, accessible through HTTP transport without requiring an API key.
    21
    MIT

  • Weather MCP Server

    skyloevil
    A
    license
    Not graded
    quality
    D
    maintenance
    Provides weather data including current conditions, daily forecasts up to 16 days, and hourly forecasts up to 7 days, using the free Open-Meteo API with no API key required.
    1
    MIT

  • mcp-weather-plus

    atomlong
    F
    license
    Not graded
    quality
    D
    maintenance
    Provides real-time weather forecasts, air quality data, and timezone information via Open-Meteo API, with no API key required.
    -

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/adrianR84/Weather-Open-Meteo-MCP'

If you have feedback or need assistance with the MCP directory API, please join our Discord server