Weather MCP Server
Click on "Deploy 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., "@Weather MCP Serverwhat's the forecast for New York City 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.
Weather MCP Server
This project implements a Model Context Protocol (MCP) server that provides real-time weather forecasts and alerts. It is built using the Python MCP SDK and the National Weather Service (NWS) API. The server fetches data (forecasts, alerts, observations, etc.) from the NWS API and exposes them as MCP tools that AI assistants (e.g. Claude) can call. In short, it allows you to ask Claude questions like “What are the weather alerts in CA?” or “What’s the forecast for 37.77, -122.42?”, and the server will return up-to-date information.
Prerequisites
Python 3.11 or higher. The Python MCP SDK requires a recent Python version.
uv package manager. This lightweight tool manages Python dependencies and can run scripts. (Install it via
curl -LsSf https://astral.sh/uv/install.sh | shon macOS/Linux or using PowerShell on Windows, or viapipx install uv.)MCP Python SDK and HTTP library. We'll install these with
uvbelow.
Related MCP server: Weather MCP Server
Setup / Installation
Clone the repository (or download the code):
git clone https://github.com/Danii2020/weather-mcp.git cd weatherInstall dependencies with
uv. In the project directory, run:uv add mcp[cli] httpxThis installs the Python MCP SDK (
mcp[cli]) and an HTTP client (httpx) used by the server.(Optional) If your project includes a
pyproject.tomlor other dependencies, you can install them similarly. But the above command covers the core libraries needed.
Running the Server
Start the weather MCP server by running:
uv run weather.pyThis will launch the server (using uv to manage the environment). The terminal will print status messages. Keep this process running to serve requests.
Note: If you run into issues, make sure you have activated the correct Python environment and that
uvis in your PATH.
Configuring Claude for Desktop
To let Claude for Desktop use this weather server, you must add it as an MCP server in Claude’s config.
Platform support: Claude Desktop is available for macOS and Windows only (Linux is not supported).
Config file location: Find or create the file:
macOS:
~/Library/Application Support/Claude/claude_desktop_config.jsonWindows:
%APPDATA%\Claude\claude_desktop_config.json
Open
claude_desktop_config.jsonin a text editor. Add an entry under"mcpServers"for the weather tool. For example:{ "mcpServers": { "weather": { "command": "/full/path/to/uv", "args": ["run", "weather.py"], "cwd": "/full/path/to/weather" } } }Replace
/full/path/to/uvwith the absolute path of theuvexecutable. You can find this by runningwhich uvon macOS or Linux, orwhere uvon Windows.Replace
/full/path/to/weatherwith the full path to theweatherproject directory on your machine.
Save the file and restart Claude for Desktop. In Claude, open the Developer settings and ensure the “weather” server appears under available MCP servers. You can now select it in your conversation.
Usage Examples
Once the server is running and Claude is configured, you can ask Claude to use the weather tools. For example:
Weather Alerts: Ask “What are the current weather alerts in CA?” (the server’s
get_alertstool will fetch alerts from NWS).Forecast: Ask “What’s the 5-day forecast for latitude 47.6, longitude -122.3?” (the server’s
get_forecasttool will retrieve the forecast).
Claude will display the results returned by the server. You can experiment with different state codes or coordinates as needed.
Video Tutorial
For a step-by-step walkthrough, watch the author’s YouTube tutorial “Learn MCP from Scratch and Build an MCP Server with Python!” at https://youtu.be/Pu5Q2dDwR9w. The video shows how to set up uv, code the server, and connect it to Claude Desktop.
Available Tools
2 toolsget_alertsD
| Name | Required | Description | Default |
|---|---|---|---|
| state | Yes |
TDQS
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.
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.
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.
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.
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.
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_forecastD
| Name | Required | Description | Default |
|---|---|---|---|
| latitude | Yes | ||
| longitude | Yes |
TDQS
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.
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.
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.
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.
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.
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.
2 tool updates
- First observed
get_alerts - First observed
get_forecast
TDQS
Scored across 2 tools
The two tools have clearly distinct purposes: get_alerts retrieves weather alerts or warnings, while get_forecast provides weather predictions. There is no overlap in functionality, making it easy for an agent to choose the correct tool based on the need for current alerts versus future forecasts.
Both tools follow a consistent verb_noun pattern with 'get_' as the prefix, ensuring predictability and readability. The naming is uniform across the set, with no deviations in style or convention, which aids in tool identification and usage.
With only two tools, the server feels thin for a weather domain that typically includes more operations like current conditions, historical data, or location-based queries. While the tools cover alerts and forecasts, the scope is limited, potentially hindering comprehensive weather-related tasks.
The tool set is severely incomplete for a weather server, missing core functionalities such as getting current conditions, searching locations, or accessing historical data. Agents will face significant gaps when trying to perform common weather-related workflows, leading to potential failures or workarounds.
Maintenance
Related MCP Connectors
Provide real-time and forecast weather information for locations in the United States using natura…
Get US weather forecasts, active alerts, and current observations.
US weather & geo for AI agents: forecasts, alerts, earthquakes, elevation, geocoding. No keys.
US weather & geo for AI agents: forecasts, alerts, earthquakes, elevation, geocoding. No keys.
Related MCP Servers
- FlicenseBqualityDmaintenanceIntegrates the US National Weather Service API with Claude Desktop to provide real-time weather conditions, forecasts, and detailed weather metrics for any US location through natural language queries.21-
- FlicenseBqualityDmaintenanceProvides real-time US weather alerts and forecasts by integrating with the National Weather Service API. It enables AI assistants to fetch state-specific alerts and detailed local forecasts using geographic coordinates.21-
- AlicenseNot gradedqualityDmaintenanceEnables Claude to access real-time weather data and alerts, including forecasts and severe weather warnings, by providing tools like get-forecast and get-alerts.55 npm18GPL 3.0
- FlicenseDqualityDmaintenanceProvides weather alerts and forecasts via the National Weather Service API, enabling Claude to answer weather-related queries.2-