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., "@OpenWeather MCP Server what's the weather and air quality like in New York?"
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 integrates OpenWeather API with Claude, enabling real-time weather information, forecasts, and air quality data directly in your conversations.
🌤️ Current Weather: Get real-time weather conditions for any city
📅 5-Day Forecast: Detailed weather forecasts with 3-hour intervals
📍 Coordinate-Based Search: Get weather data using latitude and longitude
🌍 Air Quality Index: Check pollution levels and air quality data
🌡️ Detailed Metrics: Temperature, humidity, wind speed, visibility, and more
Related MCP server: weather-mcp-server
Node.js v18 or higher
Claude Desktop
OpenWeather API key (free tier available)
Sign up at OpenWeather
Navigate to "My API keys" in your account
Copy your API key (note: new keys take ~2 hours to activate)
# Clone the repository
git clone https://github.com/MadhurToshniwal/OpenWeather-MCP-server.git
cd OpenWeather-MCP-server
# Install dependencies
npm install
# Build the project
npm run buildEdit your Claude Desktop configuration file:
Windows: %APPDATA%\Claude\claude_desktop_config.json
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Add this configuration:
{
"mcpServers": {
"openweather": {
"command": "node",
"args": [
"/absolute/path/to/openweather-mcp-server/dist/index.js"
],
"env": {
"OPENWEATHER_API_KEY": "your_api_key_here"
}
}
}
}Important for Windows users: Use double backslashes in paths:
"args": ["C:\\Users\\YourName\\Desktop\\openweather-mcp-server\\dist\\index.js"]Completely quit and restart Claude Desktop for changes to take effect.
Once configured, you can ask Claude:
"What's the weather in Tokyo?"
"Give me a 5-day forecast for London"
"What's the weather at coordinates 40.7128, -74.0060?"
"Check the air quality in Beijing"
"Compare weather between Mumbai and Delhi"
get_current_weatherGet current weather conditions for a specific city.
Parameters:
city (required): City name
country_code (optional): 2-letter country code (e.g., "US", "GB")
get_forecastGet 5-day weather forecast with 3-hour intervals.
Parameters:
city (required): City name
country_code (optional): 2-letter country code
get_weather_by_coordinatesGet current weather by geographic coordinates.
Parameters:
latitude (required): Latitude coordinate
longitude (required): Longitude coordinate
get_air_pollutionGet air quality data for specific coordinates.
Parameters:
latitude (required): Latitude coordinate
longitude (required): Longitude coordinate
The free tier of OpenWeather API includes:
1,000 API calls per day
60 calls per minute
Current weather data
5-day forecast
Air pollution data
openweather-mcp-server/
├── src/
│ └── index.ts # Main server implementation
├── dist/ # Compiled JavaScript (generated)
├── .env # Environment variables (not in repo)
├── package.json
├── tsconfig.json
└── README.md# Build the project
npm run build
# Run in development mode
npm startTypeScript: Type-safe development
Model Context Protocol (MCP): Claude integration standard
OpenWeather API: Weather data provider
Axios: HTTP client for API requests
Ensure your API key is correctly set in the configuration
New API keys take up to 2 hours to activate after signup
Verify the path in claude_desktop_config.json is correct
Restart Claude Desktop completely
Check that the project is built (dist folder exists)
Run npm install to install dependencies
Ensure Node.js version is 18 or higher
MIT
Madhur Toshniwal
📧 madhurtoshniwal03@gmail.com
OpenWeather API for weather data
Anthropic for the Model Context Protocol
Claude Desktop for AI integration
Built for campus placement showcase | Demonstrates API integration, TypeScript, and modern development practices
Get air quality data for specific coordinates
| Name | Required | Description | Default |
|---|---|---|---|
| latitude | Yes | Latitude coordinate | |
| longitude | Yes | Longitude coordinate |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states the purpose but does not disclose any behavioral traits such as data sources, update frequency, or whether it is read-only (though inferred from name).
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, direct sentence with no wasted words. It is concise but could be slightly more informative.
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 simplicity (2 parameters, no output schema), the description is adequate but minimal. It does not explain what the output contains (e.g., AQI, pollutants).
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 coverage is 100%, so parameters are already described. The description adds no additional meaning beyond 'specific coordinates'.
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 action (get) and resource (air quality data), and specifies the scope (specific coordinates). However, it does not differentiate from sibling tools like get_current_weather, which may also take coordinates.
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?
No guidance on when to use this tool versus alternatives like get_weather_by_coordinates or get_current_weather. No prerequisites or limitations are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get current weather conditions for a specific city. Returns temperature, humidity, wind speed, weather description, and more.
| Name | Required | Description | Default |
|---|---|---|---|
| city | Yes | City name (e.g., 'London', 'New York', 'Tokyo') | |
| country_code | No | Optional 2-letter country code (e.g., 'US', 'GB', 'IN') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Lists return values (temperature, humidity, etc.) without annotations. Lacks side-effect info but appropriate for a harmless read operation.
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?
Single sentence, front-loaded with purpose, no redundant words.
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?
For a simple read tool with no output schema, description sufficiently conveys behavior and expected inputs.
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 covers both parameters fully (100%). Description adds no extra meaning beyond restating 'city'.
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?
Clearly states 'current weather conditions' for a 'specific city', distinguishing from siblings like 'get_forecast' or 'get_weather_by_coordinates'.
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?
Implied usage: when current conditions for a city are needed. No explicit when-not or alternatives, but sufficient for simple tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get 5-day weather forecast with 3-hour intervals for a specific city
| Name | Required | Description | Default |
|---|---|---|---|
| city | Yes | City name (e.g., 'London', 'New York', 'Tokyo') | |
| country_code | No | Optional 2-letter country code (e.g., 'US', 'GB', 'IN') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description discloses the forecast duration (5-day) and interval (3-hour), which is key behavioral context. However, it omits details like data source, error handling, or whether historical data is included.
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, focused sentence with no redundant words. It efficiently conveys the tool's 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 no output schema, the description provides essential structure (5-day, 3-hour intervals). However, it could be more complete by mentioning typical response fields (e.g., temperature, humidity). Still adequate for a simple tool.
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?
Both parameters (city, country_code) are described in the schema with 100% coverage. The description adds no new semantic meaning beyond 'for a specific city', which restates the city parameter. Baseline 3 applies.
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', the resource 'weather forecast', and specifies the time range (5-day) and interval (3-hour) for a specific city, effectively distinguishing it from sibling tools like get_current_weather.
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?
While the description implies use for city-based forecasts, it lacks explicit guidance on when to use this tool over alternatives (e.g., get_weather_by_coordinates) and does not mention any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get current weather by geographic coordinates (latitude and longitude)
| Name | Required | Description | Default |
|---|---|---|---|
| latitude | Yes | Latitude coordinate | |
| longitude | Yes | Longitude coordinate |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description adds no behavioral context beyond the purpose, missing details on error handling, rate limits, or data freshness.
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?
Single sentence is front-loaded and concise, though it could be slightly expanded to be more informative without losing brevity.
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?
No output schema exists, and the description does not explain what data is returned (e.g., temperature, humidity), making it incomplete for agent understanding.
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?
Input schema coverage is 100%, with clear parameter descriptions; the description adds no additional semantic detail beyond what the schema provides.
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 it gets current weather using geographic coordinates, distinguishing it from siblings like get_air_pollution or get_forecast.
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 use when coordinates are available, but lacks explicit guidance on when not to use it or alternatives for city-based queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Most tools target distinct data (current, forecast, air pollution), but both get_current_weather and get_weather_by_coordinates return current conditions, differing only by input. Descriptions clarify the difference, so confusion is low but possible.
All tools follow a consistent 'get_<something>' pattern with snake_case. The naming is predictable and easily understood.
4 tools is a reasonable count for a weather server covering current, forecast, and air quality. It feels slightly light but not inadequate.
The set covers essential weather queries (current, forecast, air pollution) but lacks alerts, historical data, or UV index. Minor gaps, but core functionality is present.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Current weather and forecasts for any coordinates, backed b… — paid per call (x402/credits), 1 tools
Get current weather for any city and create images from your prompts. Streamline planning, reports…
Provide real-time and forecast weather information for locations in the United States using natura…
Global weather via Open-Meteo: forecast, ERA5 archive, marine, air quality, geocoding, elevation.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/MadhurToshniwal/OpenWeather-MCP-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server