Built as a Node.js application using ES modules for weather data retrieval and processing
Distributed and managed as an npm package with standard installation and build processes
Implemented with full TypeScript support providing type-safe weather data structures and comprehensive interfaces for API responses
Uses Zod schema validation to ensure data integrity and type safety for weather API responses and parameters
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@MCP Weather Server what's the weather like in Tokyo this weekend?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) server that provides detailed weather information for any city using the Open-Meteo API.
🌤️ Real-time weather data for any city worldwide
📅 7-day weather forecast with daily temperatures and precipitation
🌬️ Air quality information including European Air Quality Index
📍 Automatic geocoding - just provide a city name
🌡️ Current conditions including temperature, humidity, and precipitation
📊 Hourly forecast for the next 24 hours
🌅 Sunrise and sunset times for planning outdoor activities
🎯 Human-readable weather descriptions instead of raw codes
⚡ Robust error handling with retry logic and timeouts
🛡️ Type-safe with full TypeScript support
🎨 Structured JSON output for easy programmatic access
Related MCP server: Weather MCP Server
npm installnpm run devnpm startnpm run buildYou can test the weather server using the MCP Inspector, a GUI tool for testing MCP servers.
npx -y @modelcontextprotocol/inspectorIn the MCP Inspector settings:
Command: npx
Arguments: tsx main.ts
Once connected, you can test all three tools:
get-weather: Get current weather conditions and hourly forecast
Select the get-weather tool from the available tools list
Enter a city name (e.g., "New York", "London", "Tokyo")
Click "Call Tool" to see current weather data
get-forecast: Get 7-day weather forecast
Select the get-forecast tool from the available tools list
Enter a city name
Click "Call Tool" to see 7-day forecast with daily temperatures and sunrise/sunset times
get-air-quality: Get air pollution data
Select the get-air-quality tool from the available tools list
Enter a city name
Click "Call Tool" to see air quality index and pollutant levels
The inspector will display the JSON response with all the structured data for each tool.
The server provides three tools for comprehensive weather and air quality information:
get-weatherGet detailed current weather information for any city.
Parameters:
city (string, required): The name of the city to get weather for
Examples: "New York", "London", "Tokyo", "Paris"
get-forecastGet 7-day weather forecast for any city.
Parameters:
city (string, required): The name of the city to get forecast for
Examples: "New York", "London", "Tokyo", "Paris"
get-air-qualityGet air pollution data for any city.
Parameters:
city (string, required): The name of the city to get air quality for
Examples: "New York", "London", "Tokyo", "Paris"
get-weather OutputReturns structured JSON data with current conditions and hourly forecast:
{
"location": {
"name": "New York",
"fullName": "New York, New York, United States",
"latitude": 40.7128,
"longitude": -74.006,
"country": "United States",
"admin1": "New York"
},
"current": {
"time": "2024-01-15T14:30:00",
"formattedTime": "2:30 PM",
"temperature": 22.5,
"formattedTemperature": "22.5°C",
"feelsLike": 24.1,
"formattedFeelsLike": "24.1°C",
"humidity": 65,
"precipitation": 0,
"formattedPrecipitation": "No precipitation",
"weatherCode": 2,
"weatherDescription": "Partly cloudy"
},
"hourly": [
{
"time": "2024-01-15T15:00:00",
"formattedTime": "3:00 PM",
"temperature": 22.8,
"formattedTemperature": "22.8°C",
"precipitation": 0,
"formattedPrecipitation": "No precipitation"
}
],
"raw": {
// Original Open-Meteo API response for compatibility
}
}get-forecast OutputReturns 7-day forecast with daily temperatures, precipitation, and sunrise/sunset times:
{
"location": {
"name": "New York",
"fullName": "New York, New York, United States",
"latitude": 40.7128,
"longitude": -74.006,
"country": "United States",
"admin1": "New York"
},
"daily": [
{
"date": "2024-01-15",
"formattedDate": "Monday, Jan 15",
"maxTemperature": 25.2,
"formattedMaxTemperature": "25.2°C",
"minTemperature": 18.5,
"formattedMinTemperature": "18.5°C",
"precipitation": 2.1,
"formattedPrecipitation": "2.1mm",
"weatherCode": 3,
"weatherDescription": "Overcast",
"sunrise": "2024-01-15T07:15:00",
"formattedSunrise": "7:15 AM",
"sunset": "2024-01-15T16:45:00",
"formattedSunset": "4:45 PM"
}
],
"raw": {
// Original Open-Meteo API response for compatibility
}
}get-air-quality OutputReturns air pollution data with European Air Quality Index and pollutant levels:
{
"location": {
"name": "New York",
"fullName": "New York, New York, United States",
"latitude": 40.7128,
"longitude": -74.006,
"country": "United States",
"admin1": "New York"
},
"current": {
"time": "2024-01-15T14:30:00",
"formattedTime": "2:30 PM",
"europeanAqi": 35,
"aqiLevel": "Fair",
"aqiDescription": "Air quality is acceptable",
"pm25": 28,
"pm10": 42,
"no2": 45,
"o3": 32,
"so2": 8
},
"hourly": [
{
"time": "2024-01-15T15:00:00",
"formattedTime": "3:00 PM",
"europeanAqi": 38,
"aqiLevel": "Fair",
"pm25": 30,
"pm10": 45,
"no2": 48,
"o3": 35,
"so2": 9
}
],
"raw": {
// Original Open-Meteo API response for compatibility
}
}Replaced raw API JSON with structured, processed weather data
Added both raw values and formatted strings for flexibility
Included location details with coordinates and full names
Provided hourly forecast in a structured array format
Maintained backward compatibility with original API response
Implemented retry logic with exponential backoff
Added request timeouts to prevent hanging requests
Better error messages for different failure scenarios
Graceful handling of city not found errors
Added comprehensive TypeScript interfaces for all API responses
Proper type checking for geocoding and weather data
Better IntelliSense support and compile-time error detection
Centralized configuration object for easy maintenance
Configurable timeouts, retry counts, and API endpoints
Easy to modify settings without touching core logic
Request timeout handling (10 seconds)
Automatic retry for failed requests (up to 3 attempts)
Proper URL encoding for city names
Abort controller for request cancellation
Weather code mapping to human-readable descriptions
Proper formatting for temperatures, precipitation, and times
Location name formatting with state/province when available
Timezone-aware time formatting
Separated concerns into utility functions
Clear function naming and documentation
Modular design for easy testing and maintenance
Consistent error handling patterns
Framework: Model Context Protocol (MCP) SDK
Language: TypeScript
APIs: Open-Meteo (geocoding and weather)
Transport: StdioServerTransport
Validation: Zod schema validation
Runtime: Node.js with ES modules
The server handles various error scenarios:
City not found: Returns a helpful message with spelling suggestions
Network errors: Retries up to 3 times with exponential backoff
API errors: Provides user-friendly error messages
Timeout errors: Aborts requests after 10 seconds
ISC
Get air pollution data for any city including European Air Quality Index and pollutant levels
| Name | Required | Description | Default |
|---|---|---|---|
| city | Yes | The name of the city to get air quality information for (e.g., 'New York', 'London', 'Tokyo') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states what data is returned but doesn't cover critical aspects like rate limits, authentication needs, error handling, or data sources. For a tool with no annotations, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose. Every word earns its place, with no wasted text. It's appropriately sized for a simple tool with one parameter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 parameter, no output schema, no annotations), the description is minimally adequate. It covers the purpose but lacks usage guidelines and behavioral details. Without annotations or output schema, it should do more to compensate, but the simplicity keeps it from being completely inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the city parameter well-documented in the schema. The description adds no additional parameter information beyond implying city scope. This meets the baseline of 3 since the schema does the heavy lifting, but the description doesn't compensate with extra context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource 'air pollution data', specifying it includes 'European Air Quality Index and pollutant levels'. It distinguishes from sibling tools (get-forecast, get-weather) by focusing on pollution rather than weather. However, it doesn't explicitly mention the sibling differentiation, keeping it at 4 rather than 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like get-forecast or get-weather. It mentions 'any city' but doesn't specify limitations or prerequisites, such as city availability or data freshness. This leaves the agent without clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get 7-day weather forecast for any city including daily temperatures, precipitation, and sunrise/sunset times
| Name | Required | Description | Default |
|---|---|---|---|
| city | Yes | The name of the city to get forecast information for (e.g., 'New York', 'London', 'Tokyo') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions what data is returned but doesn't disclose behavioral traits like rate limits, authentication requirements, error conditions, or whether this is a read-only operation. The description is functional but lacks operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose and includes all essential details without waste. Every element (duration, resource, data scope) earns its place, making it optimally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (1 parameter, no output schema, no annotations), the description covers the basic purpose and data scope adequately. However, it lacks details about behavioral aspects and doesn't help differentiate from sibling tools, making it minimally complete but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the city parameter well-documented in the schema. The description adds no additional parameter semantics beyond what's already in the schema, so it meets the baseline score of 3 for high schema coverage without adding value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Get 7-day weather forecast'), the resource ('for any city'), and the scope of data returned ('including daily temperatures, precipitation, and sunrise/sunset times'). It distinguishes from sibling tools by specifying forecast data rather than current weather or air quality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context ('for any city') but doesn't explicitly state when to use this tool versus the sibling tools get-weather and get-air-quality. No guidance is provided about alternatives or exclusions, leaving the agent to infer based on the data types mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed weather information for any city including current conditions and hourly forecast
| Name | Required | Description | Default |
|---|---|---|---|
| city | Yes | The name of the city to get weather information for (e.g., 'New York', 'London', 'Tokyo') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves weather information but doesn't mention any behavioral traits such as rate limits, authentication needs, data sources, error handling, or whether it's a read-only operation. This leaves significant gaps for an AI agent to understand how to use it effectively.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, consisting of a single, efficient sentence that directly states the tool's purpose without unnecessary details. Every word earns its place, making it easy for an AI agent to quickly grasp the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a weather tool with no annotations and no output schema, the description is incomplete. It lacks information on behavioral aspects (e.g., rate limits, errors), output format, and differentiation from siblings. While the schema covers the input well, the overall context for safe and effective use is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'city' parameter well-documented in the schema itself. The description adds no additional meaning beyond what the schema provides, as it doesn't elaborate on parameter usage or constraints. According to the rules, with high schema coverage (>80%), the baseline is 3 even without param info in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Get') and resource ('detailed weather information'), specifying it includes current conditions and hourly forecast. However, it doesn't explicitly differentiate from sibling tools like 'get-air-quality' or 'get-forecast', which likely provide related but distinct weather data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions 'detailed weather information' but doesn't clarify if this is for general use, real-time data, or how it compares to siblings like 'get-air-quality' (which might focus on pollution) or 'get-forecast' (which could be broader or longer-term).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
get-air-qualityget-forecastget-weatherThe tools are mostly distinct with clear purposes: air quality, 7-day forecast, and current weather. However, get-weather and get-forecast could be confused as both provide weather data, though their scopes differ (current/hourly vs. 7-day). Descriptions help clarify this overlap.
All tool names follow a consistent verb_noun pattern with get- prefix and hyphenated nouns (get-air-quality, get-forecast, get-weather). This predictable naming makes it easy for agents to understand and select tools.
Three tools are reasonable for a weather server, covering key aspects like current conditions, forecasts, and air quality. It's slightly lean but well-scoped, with each tool serving a distinct function without unnecessary bloat.
The toolset covers core weather domain needs: current weather, forecasts, and air quality. Minor gaps might include historical data or alerts, but agents can work effectively with these tools for most common weather queries.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Global weather via Open-Meteo: forecast, ERA5 archive, marine, air quality, geocoding, elevation.
Free, keyless real-time weather and 7-day forecasts for any city worldwide.
Real-time weather conditions and multi-day forecasts via Open-Meteo — free, no API key required
Free, keyless real-time air quality (US AQI plus PM2.5, PM10, ozone, NO2, SO2, CO) for any city.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/dimonets/mcp-weather-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server