Skip to main content
Glama
arunm8489

Weather MCP Server

by arunm8489
OverviewSchemaRelated ServersScoreDiscussions
Python
Hybrid

Weather MCP Server & Client

A Model Context Protocol (MCP) implementation that exposes weather alerts from the National Weather Service API as tools. Includes an interactive chat client powered by Groq LLM and test scripts for both STDIO and SSE transports.

Table of Contents

Related MCP server: MCP Weather Alert Agent

Prerequisites

  • Python 3.13+ (see pyproject.toml)

  • uv – Python package manager (install)

  • Groq API Key – for the LLM (get one)

Setup

  1. Clone or navigate to the project:

    cd /path/to/MCP

  2. Create a .env file with your Groq API key:

    GROQ_API_KEY=your_groq_api_key_here

  3. Install dependencies with uv:

    uv sync

    This creates a .venv and installs all dependencies from pyproject.toml. The project uses langchain>=1.2.0,<2.0.0 for compatibility with mcp-use.

Configuration Files

File

Purpose

server/weather_mcp.json

Default config for stdio: spawns uv run server/weather.py

server/weather_stdio_config.json

Same as above; used by stdio test script

server/weather_sse_config.json

SSE config: connects to http://127.0.0.1:8000/sse

Config Format

STDIO (command-based):

{
  "mcpServers": {
    "weather": {
      "command": "uv",
      "args": ["run", "server/weather.py"]
    }
  }
}

SSE (URL-based):

{
  "mcpServers": {
    "weather": {
      "url": "http://127.0.0.1:8000/sse"
    }
  }
}

Use Cases & How to Run

All commands use uv run to execute scripts with the project's virtual environment and dependencies.

Case 1: Interactive Chat Client (STDIO)

Run an interactive chat that connects to the weather MCP server. The agent can call get_alerts when you ask about weather.

Run:

uv run client_chatbot.py

Commands:

  • Type any question (e.g., "What are the weather alerts for California?")

  • exit or quit – end the session

  • clear – clear conversation history

What happens:

  • Client reads server/weather_mcp.json

  • Spawns uv run server/weather.py as a subprocess

  • Communicates via stdin/stdout (stdio transport)

  • Agent uses Groq LLM and calls get_alerts when needed

Case 2: STDIO Transport Test

Explicit test of the stdio transport. Same behavior as Case 2 but uses a dedicated config file.

Run:

uv run test_weather_stdio.py

What happens:

  • Uses server/weather_stdio_config.json

  • Client spawns uv run server/weather.py

  • Runs one query and exits

Case 3: SSE Transport Test

Test the SSE (HTTP) transport. The script starts the server in HTTP mode, connects via URL, runs a query, then shuts down the server.

Run:

uv run test_weather_sse.py

What happens:

  1. Starts server/weather_sse.py in the background (listens on port 8000)

  2. Waits for the server to be ready

  3. Connects to http://127.0.0.1:8000/sse

  4. Runs one query

  5. Terminates the server process

Case 4: Run Weather Server Manually (SSE)

Run the weather server as a standalone HTTP process. Useful for debugging or when multiple clients need to connect.

Run:

# Terminal 1: Start the server
uv run server/weather_sse.py

Then in another terminal, use a client configured with url: "http://127.0.0.1:8000/sse" (e.g., test_weather_sse.py or a custom client with weather_sse_config.json).

Case 6: Run Weather Server Manually (STDIO)

Running the stdio server directly is rarely useful because it expects JSON-RPC on stdin. It's normally spawned by the client.

For debugging:

uv run server/weather.py
# Server waits for stdin; won't do anything useful without a client

Project Structure

MCP/
├── README.md                 # This file
├── .env                      # GroQ API key (create this)
├── pyproject.toml            # Project dependencies
├── client_chatbot.py         # Interactive chat client (stdio)
├── test_weather.py           # Quick one-shot test (stdio)
├── test_weather_stdio.py     # STDIO transport test
├── test_weather_sse.py       # SSE transport test
├── server/
│   ├── weather.py            # MCP server (STDIO transport)
│   ├── weather_sse.py        # MCP server (SSE transport)
│   ├── weather_mcp.json      # Default client config (stdio)
│   ├── weather_stdio_config.json
│   └── weather_sse_config.json
└── src/
    └── app_mcp/
        └── __init__.py       # Package init

MCP Tools Exposed

Tool

Description

Args

get_alerts

Get active weather alerts for a US state

state (e.g., "CA", "NY")

MCP Resources

URI

Description

echo://{message}

Echo a message (for testing)

Troubleshooting

"No module named 'mcp_use'"

Run uv sync to install dependencies, then use uv run for all scripts:

uv sync
uv run client_chatbot.py

"ModuleNotFoundError: No module named 'httpx'"

Dependencies are in pyproject.toml. Run uv sync to install.

"qwen-qwq-32b has been decommissioned"

The project uses llama-3.3-70b-versatile. If you see references to qwen-qwq-32b, update the model in the client/test scripts.

"Connection closed" or "Invalid JSON"

Avoid printing to stdout from code that runs in the MCP server process. Stdio uses stdin/stdout for JSON-RPC; any extra output breaks the protocol.

Port 8000 already in use

Stop the process using port 8000, or change the port in server/weather_sse.py:

mcp = FastMCP("weather", host="127.0.0.1", port=8001)

Then update SSE_SERVER_PORT in test_weather_sse.py and the URL in weather_sse_config.json.

Sandbox / uv cache errors

Run with full permissions if you see "Operation not permitted" for uv cache:

uv run client_chatbot.py  # may need to run outside sandbox

Available Tools

1 tool
get_alertsA

MCP Tool: Get active weather alerts for a US state.

This tool is exposed to MCP clients and can be invoked by AI agents. It fetches from the NWS API and returns formatted alert information.

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

Returns: Formatted string of all active alerts, or a message if none found

ParametersJSON Schema
NameRequiredDescriptionDefault
stateYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4/5.0
Behavior3/5

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 mentions the data source ('NWS API') and that it 'returns formatted alert information', which adds some context. However, it lacks details on error handling, rate limits, authentication needs, or what 'formatted' specifically entails, leaving gaps in behavioral understanding.

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

Conciseness5/5

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

The description is well-structured and front-loaded with the core purpose in the first sentence. Each subsequent sentence adds value without redundancy, such as specifying the API source and return format. There is no wasted text, making it efficient and easy to parse.

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

Completeness4/5

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

Given the tool's moderate complexity (single parameter, no annotations, but with an output schema), the description is reasonably complete. It explains the purpose, parameter, and return behavior. The presence of an output schema means the description doesn't need to detail return values, but it could benefit from more behavioral context like error handling or usage constraints.

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 0% description coverage, but the description compensates by explaining the 'state' parameter as 'Two-letter US state code (e.g. CA, NY, TX)', which adds crucial semantic context not present in the schema. This effectively documents the single parameter, though it doesn't cover edge cases or validation rules.

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's purpose with specific verb ('Get'), resource ('active weather alerts'), and scope ('for a US state'). It distinguishes itself by specifying the data source ('NWS API') and the geographic limitation, making the purpose unambiguous even without sibling tools for comparison.

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 context by mentioning 'active weather alerts' and 'US state', suggesting it should be used when such alerts are needed. However, there are no explicit guidelines on when to use this tool versus alternatives, nor any mention of prerequisites or exclusions, leaving the agent to infer appropriate usage scenarios.

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

Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.9/5.0
Disambiguation5/5

With only one tool, there is no possibility of ambiguity or overlap between tools. The tool's purpose is clearly defined and distinct by default.

Naming Consistency5/5

A single tool inherently follows a consistent naming pattern. The tool name 'get_alerts' uses a verb_noun structure, which is clear and appropriate for its function.

Tool Count2/5

A single tool is too few for a weather server's apparent scope, which typically includes forecasts, current conditions, and alerts. This feels thin and limits functionality, though it is focused on one specific task.

Completeness2/5

The tool set is severely incomplete for a weather domain, covering only alerts for US states. Obvious gaps include lack of forecast retrieval, current weather data, international support, or historical data, which will cause agent failures in broader weather-related tasks.

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

    mauricioTechDev
    A
    license
    Not graded
    quality
    D
    maintenance
    A Model Context Protocol server that enables AI models to fetch weather alerts and detailed forecasts for US locations using the National Weather Service API.
    80
    GPL 3.0

  • MCP Weather Alert Agent

    MokshadaRaibagkar
    F
    license
    Not graded
    quality
    D
    maintenance
    A lightweight AI agent that fetches real-time weather alerts for any U.S. state using the National Weather Service API.

  • MCP Weather Server

    SandroSD
    -
    license
    B
    quality
    D
    maintenance
    Enables users to retrieve current weather alerts for US states and detailed weather forecasts by geographic coordinates using the US National Weather Service API. Built with Node.js and TypeScript following Model Context Protocol standards for seamless LLM integration.
    2

  • Weather Alerts MCP Server

    shubhechhadey
    F
    license
    A
    quality
    D
    maintenance
    Provides real-time weather alerts for US states using the National Weather Service API, enabling users to fetch and view active weather warnings through natural language queries.
    1
    1

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/arunm8489/MCP'

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