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 Server what are the current weather alerts for California?"
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 weather information using the National Weather Service API. This server exposes tools for getting weather forecasts and alerts for US locations.
🌤️ Weather Forecasts: Get detailed weather forecasts for any US location using latitude/longitude coordinates
🚨 Weather Alerts: Retrieve active weather alerts for any US state
🔌 MCP Integration: Works seamlessly with Claude for Desktop and other MCP-compatible clients
📡 Real-time Data: Fetches live data from the National Weather Service API
Related MCP server: Weather MCP Server
get-forecastGet weather forecast for a specific location.
Parameters:
latitude (float): Latitude of the location (-90 to 90)
longitude (float): Longitude of the location (-180 to 180)
Example usage:
"What's the weather forecast for San Francisco?" (Claude will use coordinates ~37.7749, -122.4194)
"Give me the weather forecast for latitude 47.6062, longitude -122.3321" (Seattle)
get-alertsGet active weather alerts for a US state.
Parameters:
state (string): Two-letter US state code (e.g., "CA", "NY", "TX")
Example usage:
"What are the active weather alerts in California?"
"Are there any weather warnings in Texas?"
Python 3.10 or higher
uv package manager
Access to the internet (for NWS API calls)
Install uv (if not already installed):
# macOS/Linux
curl -LsSf https://astral.sh/uv/install.sh | sh
# Windows
powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"Clone or navigate to the project directory:
cd weatherInstall dependencies:
uv syncTo test the server directly:
uv run weather.pyThe server will start and listen on standard input/output. You can test it using the MCP inspector or other MCP clients.
Install Claude for Desktop from claude.ai/download
Configure Claude for Desktop by editing the configuration file:
macOS/Linux:
code ~/Library/Application\ Support/Claude/claude_desktop_config.jsonWindows:
code $env:AppData\Claude\claude_desktop_config.jsonAdd the weather server configuration:
macOS/Linux:
{
"mcpServers": {
"weather": {
"command": "uv",
"args": [
"--directory",
"/ABSOLUTE/PATH/TO/YOUR/weather",
"run",
"weather.py"
]
}
}
}Windows:
{
"mcpServers": {
"weather": {
"command": "uv",
"args": [
"--directory",
"C:\\ABSOLUTE\\PATH\\TO\\YOUR\\weather",
"run",
"weather.py"
]
}
}
}Restart Claude for Desktop completely
Verify the integration by looking for the "Search and tools" icon in Claude for Desktop
Once configured with Claude for Desktop, you can ask questions like:
"What's the weather forecast for Sacramento?"
"Give me the weather forecast for New York City"
"What are the active weather alerts in Florida?"
"Are there any severe weather warnings in Texas?"
"What's the weather like at coordinates 40.7128, -74.0060?" (NYC)
This server uses the National Weather Service API (api.weather.gov), which:
Provides free access to US weather data
Requires no API key
Returns data in JSON format
Only covers US locations
weather/
├── main.py # Entry point (if needed)
├── weather.py # Main MCP server implementation
├── pyproject.toml # Project configuration and dependencies
├── uv.lock # Dependency lock file
└── README.md # This fileCheck the configuration file syntax - Ensure valid JSON
Verify the absolute path - Use full paths, not relative ones
Check Claude's logs:
# macOS/Linux
tail -f ~/Library/Logs/Claude/mcp*.log
# Windows
# Check logs in %AppData%\Claude\logs\Restart Claude for Desktop completely
Verify the server runs standalone:
uv run weather.pyCheck for rate limiting - The NWS API has rate limits
Ensure coordinates are for US locations - The NWS API only covers the US
Check internet connectivity - Server needs to reach api.weather.gov
"Failed to retrieve grid point data": Usually means coordinates are outside the US
"No active alerts for this state": Not an error - just means no current alerts
"Unable to fetch forecast data": Network issue or invalid coordinates
To add new weather-related tools:
Add the tool using the @mcp.tool() decorator
Implement the async function with proper type hints
Add error handling and validation
Test with uv run weather.py
Key dependencies (managed by uv):
mcp: Model Context Protocol SDK
httpx: HTTP client for API requests
fastmcp: Simplified MCP server framework
This project is part of the Model Context Protocol ecosystem. Check individual dependencies for their licenses.
Feel free to submit issues and pull requests to improve the weather server functionality.
Get weather alerts for a US state.
Args: state: Two-letter US state code (e.g. CA, NY)
| Name | Required | Description | Default |
|---|---|---|---|
| state | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. 'Get' implies a read-only operation, but the description does not explicitly state side-effect-free behavior or any caveats about alert types or data source. It is not misleading, but it adds minimal behavioral context beyond what the name implies.
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 extremely concise, with a front-loaded purpose statement followed by a compact Args block. Every sentence earns its place and there is no filler.
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?
With a single well-documented parameter, an output schema, and no siblings, the description plus schema fully covers what an agent needs to invoke the tool correctly. No missing context for this simple operation.
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 0%, yet the description fully compensates by specifying the parameter format ('Two-letter US state code') and providing concrete examples ('CA, NY'). This adds real meaning beyond the raw schema type string.
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 states a specific verb ('Get'), a clear resource ('weather alerts'), and a clear scope ('US state'). It is unambiguous and leaves no doubt about what the tool does, even without siblings to differentiate from.
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?
There are no sibling tools, so explicit routing guidance is unnecessary. The description clearly implies usage: when you need weather alerts for a US state. It lacks explicit exclusions, but nothing is misleading or missing for a tool of this simplicity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get weather forecast for a location.
Args: latitude: Latitude of the location longitude: Longitude of the location
| Name | Required | Description | Default |
|---|---|---|---|
| latitude | Yes | ||
| longitude | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must carry behavioral context. It only says 'get' a forecast and gives no indication of units, time range, coordinate format, or whether this is a read-only operation. Nothing contradicts annotations, but little is disclosed beyond the basic action.
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 short and the core purpose is front-loaded. The Args block is somewhat redundant with the schema but does not add significant bloat, keeping the overall entry compact.
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?
The description provides the essential call requirements (latitude and longitude) and the presence of an output schema reduces the need to document return values. However, it omits practical context like expected coordinate units, available forecast periods, and why an agent would choose this over get_alerts.
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 Args section repeats the parameter names with minimal glosses ('Latitude of the location'), adding almost no meaning beyond the schema titles. Since schema description coverage is 0%, the description should compensate with coordinate format or range details, but it does not.
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 uses a clear verb and resource: 'Get weather forecast for a location'. It does not explicitly mention the sibling get_alerts, but the forecast-vs-alerts distinction is clear enough from the domain.
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 is given about when to use this tool instead of get_alerts, nor are any exclusions or alternative conditions provided. The intended usage is only implied by the tool name and description.
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.
v0.1.0get_alertsget_forecastScored across 2 tools
The two tools have clearly distinct purposes: one for weather alerts by state, one for forecast by coordinates. No overlap or ambiguity.
Both tools follow the consistent 'get_<resource>' pattern (get_alerts, get_forecast), with clear nouns indicating the resource type.
With only 2 tools, the server feels minimal but adequately covers its stated purpose of weather alerts and forecasts. It is at the lower bound of acceptable scope.
The server covers alerts and forecasts, but lacks current conditions, historical data, or other common weather queries. Basic coverage, but notable gaps exist.
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.
Provide real-time and forecast weather information for locations in the United States using natura…