Skip to main content
Glama
nitvob

Weather MCP Server

by nitvob
OverviewSchemaRelated ServersScoreDiscussions
Python
Remote

Weather MCP Server

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.

Features

  • 🌤️ 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

Tools Available

get-forecast

Get 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-alerts

Get 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?"

Prerequisites

  • Python 3.10 or higher

  • uv package manager

  • Access to the internet (for NWS API calls)

Installation

  1. 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"

  2. Clone or navigate to the project directory:

    cd weather

  3. Install dependencies:

    uv sync

Running the Server

Standalone Testing

To test the server directly:

uv run weather.py

The server will start and listen on standard input/output. You can test it using the MCP inspector or other MCP clients.

With Claude for Desktop

  1. Install Claude for Desktop from claude.ai/download

  2. Configure Claude for Desktop by editing the configuration file:

    macOS/Linux:

    code ~/Library/Application\ Support/Claude/claude_desktop_config.json

    Windows:

    code $env:AppData\Claude\claude_desktop_config.json

  3. Add 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"
      ]
    }
  }
}

  4. Restart Claude for Desktop completely

  5. Verify the integration by looking for the "Search and tools" icon in Claude for Desktop

Usage Examples

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)

API Details

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

Project Structure

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 file

Troubleshooting

Server Not Showing Up in Claude

  1. Check the configuration file syntax - Ensure valid JSON

  2. Verify the absolute path - Use full paths, not relative ones

  3. Check Claude's logs:

    # macOS/Linux
tail -f ~/Library/Logs/Claude/mcp*.log

# Windows
# Check logs in %AppData%\Claude\logs\

  4. Restart Claude for Desktop completely

Tool Calls Failing

  1. Verify the server runs standalone:

    uv run weather.py

  2. Check for rate limiting - The NWS API has rate limits

  3. Ensure coordinates are for US locations - The NWS API only covers the US

  4. Check internet connectivity - Server needs to reach api.weather.gov

Common Error Messages

  • "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

Development

Adding New Tools

To add new weather-related tools:

  1. Add the tool using the @mcp.tool() decorator

  2. Implement the async function with proper type hints

  3. Add error handling and validation

  4. Test with uv run weather.py

Dependencies

Key dependencies (managed by uv):

  • mcp: Model Context Protocol SDK

  • httpx: HTTP client for API requests

  • fastmcp: Simplified MCP server framework

License

This project is part of the Model Context Protocol ecosystem. Check individual dependencies for their licenses.

Contributing

Feel free to submit issues and pull requests to improve the weather server functionality.

Related Resources

Available Tools

2 tools
get_alertsA

Get weather alerts for a US state.

Args: state: Two-letter US state code (e.g. CA, NY)

ParametersJSON Schema
NameRequiredDescriptionDefault
stateYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.6/5.0
Behavior2/5

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

No annotations are provided, and the description does not disclose behavioral traits such as rate limits, data sources, or that it is a read-only operation. The minimal description leaves the agent to infer behavior from the tool name alone.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very short, but it includes a clear 'Args' section. While the parameter details are repeated from the schema, the added examples make it useful. A little more conciseness could be achieved by dropping the 'Args' section if unnecessary, but it's acceptable.

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

Completeness3/5

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

Given the tool has an output schema (unspecified) and only one parameter, the description is somewhat minimal. It adequately covers the input but does not explain the output format or how alerts differ from forecasts. More context would improve completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has no description for the 'state' parameter, but the description adds valuable meaning: it specifies a two-letter US state code with examples (CA, NY). This compensates for the 0% schema description coverage.

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 clearly states the tool gets weather alerts for a US state, which is a specific verb-resource combination. It distinguishes itself from the sibling tool 'get_forecast' by focusing on alerts rather than 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 description implies usage is for US state alerts but does not provide explicit guidance on when to use this tool versus alternatives like 'get_forecast'. No when-not-to-use or prerequisite information is given.

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

get_forecastC

Get weather forecast for a location.

Args: latitude: Latitude of the location longitude: Longitude of the location

ParametersJSON Schema
NameRequiredDescriptionDefault
latitudeYes
longitudeYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations provided, the description must disclose behavior but only states the basic function. It does not mention data freshness, units, forecast period, or any limitations, which is insufficient for a forecast tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is short but includes an 'Args' block that redundantly restates schema parameters. It could be more concise without this structure, but overall it is not overly verbose.

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

Completeness2/5

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

For a simple tool with output schema, the description misses important context: whether it returns current or forecast data, time resolution, geographic coverage, or usage notes. The sibling tool further demands differentiation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must add value. It repeats parameter names and adds minimal context ('Latitude of the location', 'Longitude of the location'), but lacks details like valid ranges or format.

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 clearly states the tool retrieves a weather forecast for a location using the verb 'Get' and resource 'weather forecast'. It effectively distinguishes from the sibling 'get_alerts', which presumably deals with alerts.

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

Usage Guidelines2/5

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

There is no guidance on when to use this tool versus alternatives like 'get_alerts'. No exclusions or prerequisites are mentioned, leaving the agent to infer usage from context.

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 observedget_alerts
    • First observedget_forecast
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.4/5.0
Disambiguation5/5

The two tools have clearly distinct purposes: one for weather alerts by state, one for forecast by coordinates. No overlap or ambiguity.

Naming Consistency5/5

Both tools follow the consistent 'get_<resource>' pattern (get_alerts, get_forecast), with clear nouns indicating the resource type.

Tool Count3/5

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.

Completeness3/5

The server covers alerts and forecasts, but lacks current conditions, historical data, or other common weather queries. Basic coverage, but notable gaps exist.

Maintenance

ActivityInactive
ResponsivenessNo issues

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

    x8yuv
    A
    license
    Not graded
    quality
    D
    maintenance
    Provides weather forecasts and alerts for US locations using the National Weather Service API. Supports getting detailed forecasts by coordinates and active weather alerts by state code.
    80
    GPL 3.0

  • Weather MCP Server

    bryankemp
    A
    license
    Not graded
    quality
    D
    maintenance
    Provides access to National Weather Service data, enabling users to retrieve real-time weather forecasts for specific coordinates and active weather alerts by US state.
    BSD 3-Clause

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/nitvob/nws-mcp-server'

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