Skip to main content
Glama
ShriniTechie

NWS Weather MCP Server

by ShriniTechie

🌀️ NWS Weather MCP Server & Agentic Client

A fully functional Model Context Protocol (MCP) server and custom LLM client that enables dynamic, real-time weather querying through the National Weather Service (NWS) API.

This project demonstrates an end-to-end AI agentic workflow using the ReAct pattern, where an LLM dynamically discovers available tools, determines the required parameters, executes tool calls through an MCP server, retrieves live weather data, and synthesizes the results into a natural-language response.


✨ Key Features

  • Model Context Protocol (MCP): Implements the MCP server/client architecture for tool discovery and standardized communication over stdio.

  • Dynamic Tool Discovery: The client discovers available MCP tools at runtime rather than relying on hardcoded tool definitions.

  • Zero-Shot Tool Calling: Dynamically translates MCP Pydantic schemas into Gemini FunctionDeclaration objects, allowing the LLM to understand and invoke available tools.

  • National Weather Service Integration: Retrieves real-time weather alerts and forecast information from the NWS API.

  • Dynamic Coordinate Resolution: Weather information is retrieved based on dynamically determined geographic coordinates.

  • Decoupled Architecture: Separates the tool execution environment from the LLM reasoning engine.

  • Pydantic Validation: Uses Pydantic models to validate structured weather data returned by the MCP server.

  • Agentic Reasoning Loop: Demonstrates how an LLM can determine when additional contextual information or tool execution is required before generating a final response.


Related MCP server: Weather MCP Server

πŸ—οΈ Architecture

                         β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
                         β”‚        User         β”‚
                         β”‚ Natural Language    β”‚
                         β”‚      Request       β”‚
                         β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜
                                    β”‚
                                    β–Ό
                         β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
                         β”‚    Gemini Client    β”‚
                         β”‚   LLM Reasoning     β”‚
                         β”‚    / ReAct Loop     β”‚
                         β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜
                                    β”‚
                         MCP Tool Discovery
                                    β”‚
                                    β–Ό
                         β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
                         β”‚     MCP Client      β”‚
                         β”‚ Tool Schema Mapping β”‚
                         β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜
                                    β”‚
                             JSON-RPC / stdio
                                    β”‚
                                    β–Ό
                         β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
                         β”‚     MCP Server      β”‚
                         β”‚   Weather Tools     β”‚
                         β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜
                                    β”‚
                                    β–Ό
                         β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
                         β”‚   NWS Weather API   β”‚
                         β”‚  Live Weather Data  β”‚
                         β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜
                                    β”‚
                                    β–Ό
                         β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
                         β”‚ Structured Weather  β”‚
                         β”‚       Data          β”‚
                         β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜
                                    β”‚
                                    β–Ό
                         β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
                         β”‚       Gemini        β”‚
                         β”‚ Response Synthesis  β”‚
                         β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜
                                    β”‚
                                    β–Ό
                         β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
                         β”‚   Natural Language  β”‚
                         β”‚      Response       β”‚
                         β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜

🧠 How It Works

The application follows an agentic workflow where the LLM can dynamically discover and execute tools provided by the MCP server.

1. Tool Discovery

The Gemini client starts the weather MCP server and requests the tools exposed by the server.

Available tools include:

  • get_alerts

  • get_forecast

The MCP client receives the tool definitions and their associated schemas.

2. Schema Translation

The MCP tool schemas are dynamically converted into Gemini-compatible FunctionDeclaration objects.

This allows Gemini to understand:

  • What tools are available

  • What each tool does

  • What parameters each tool expects

  • What information needs to be supplied for execution

3. Agentic Reasoning

The user provides a natural-language weather request.

Gemini analyzes the request and determines whether a tool needs to be called.

For example:

User:
What's the weather forecast for my location?

        ↓

Gemini determines:
I need geographic coordinates to retrieve the forecast.

        ↓

MCP Tool Call:
get_forecast(latitude, longitude)

        ↓

NWS API:
Returns forecast information.

        ↓

Gemini:
Synthesizes the weather data into a natural-language response.

4. Tool Execution

The MCP server receives the requested tool call and executes the corresponding Python function.

The weather tool communicates with the National Weather Service API and retrieves the required information.

5. Data Validation

The returned data is validated using Pydantic models before being passed back to the client.

This provides a structured and predictable interface between the external API and the LLM.

6. Response Synthesis

Gemini receives the tool output and uses the retrieved information to generate a conversational response for the user.


πŸ› οΈ Tech Stack

Technology

Purpose

Python 3.11

Application development

MCP SDK

Model Context Protocol server/client implementation

Gemini

LLM reasoning and tool calling

google-genai

Gemini API integration

httpx

HTTP communication with the NWS API

Pydantic

Data validation and structured models

asyncio

Asynchronous execution

uv

Python package and environment management

National Weather Service API

Live weather data


πŸ“ Project Structure

weather-mcp-server/
β”‚
β”œβ”€β”€ weather.py
β”‚   └── MCP weather server
β”‚
β”œβ”€β”€ client_gemini.py
β”‚   └── Gemini-powered MCP client and agentic reasoning loop
β”‚
β”œβ”€β”€ pyproject.toml
β”‚   └── Project configuration and dependencies
β”‚
β”œβ”€β”€ uv.lock
β”‚   └── Locked dependency versions
β”‚
└── README.md
    └── Project documentation

πŸš€ Getting Started

Prerequisites

Make sure you have the following installed:

  • Python 3.11+

  • uv package manager

  • A valid Google Gemini API key


1. Clone the Repository

git clone https://github.com/ShriniTechie/weather-mcp-server.git
cd weather-mcp-server

2. Install Dependencies

Initialize the environment and install the project dependencies using uv:

uv sync

3. Configure the Gemini API Key

Set your Gemini API key as an environment variable.

Windows PowerShell

$env:GEMINI_API_KEY="your_actual_api_key_here"

Linux / macOS

export GEMINI_API_KEY="your_actual_api_key_here"

⚠️ Security: Never commit your API key to GitHub. Use environment variables or another secure secrets-management approach.


4. Run the Agentic Client

Start the integrated Gemini client:

uv run client_gemini.py

The client will:

  1. Start the MCP weather server.

  2. Establish communication with the server.

  3. Discover the available MCP tools.

  4. Convert MCP schemas into Gemini function declarations.

  5. Send the available tools to Gemini.

  6. Process the user's request.

  7. Execute the required weather tools.

  8. Retrieve live data from the NWS API.

  9. Return the tool results to Gemini.

  10. Generate the final natural-language response.


πŸ”„ Agentic Execution Flow

User Request
     β”‚
     β–Ό
Gemini LLM
     β”‚
     β”‚ Determines required tool
     β–Ό
MCP Client
     β”‚
     β”‚ Sends tool request
     β–Ό
MCP Server
     β”‚
     β”‚ Executes Python function
     β–Ό
NWS API
     β”‚
     β”‚ Returns weather data
     β–Ό
MCP Server
     β”‚
     β”‚ Validates response
     β–Ό
MCP Client
     β”‚
     β”‚ Returns tool result
     β–Ό
Gemini LLM
     β”‚
     β”‚ Synthesizes response
     β–Ό
Final Answer

πŸ”§ MCP Tools

get_alerts

Retrieves active weather alerts from the National Weather Service.

The tool can be used by the LLM when the user asks about active weather warnings or alerts.


get_forecast

Retrieves forecast information from the National Weather Service based on geographic coordinates.

The tool provides forecast information that can then be interpreted and summarized by Gemini.


πŸ’‘ Example Interaction

User:
What is the weather forecast for the requested location?

Agent:
I need to retrieve the forecast information.

MCP:
get_forecast(latitude=<latitude>, longitude=<longitude>)

NWS:
Returns structured forecast information.

Gemini:
The forecast is retrieved and synthesized into a
natural-language response for the user.

The important aspect of this workflow is that the LLM is not simply generating an answer from its existing knowledge. It can discover and invoke external tools to retrieve live information before producing the final response.


🎯 Project Goals

This project was built to demonstrate practical concepts around:

  • Model Context Protocol (MCP)

  • LLM tool calling

  • Agentic AI workflows

  • ReAct-style reasoning

  • Dynamic tool discovery

  • Function calling

  • API integration

  • Structured data validation

  • Python asynchronous programming

  • Separation of reasoning and tool execution

  • LLM integration with external services


πŸ” Key Takeaways

This project demonstrates how an LLM application can be structured into separate components:

Reasoning Layer

Gemini is responsible for understanding the user's request, determining what information is required, and deciding which tools to invoke.

Tool Layer

The MCP server exposes weather-related capabilities through standardized tools.

Data Layer

The National Weather Service API provides live weather information.

Validation Layer

Pydantic provides structured validation of returned data.

This separation makes the architecture easier to understand, extend, and maintain.


πŸ” Security

Do not commit secrets or API keys to the repository.

For example, avoid committing:

GEMINI_API_KEY=your_actual_api_key

Instead, configure the API key through your environment.

You should also ensure sensitive configuration files are included in .gitignore.

Example:

.env
.venv/
__pycache__/
*.pyc

πŸ“Œ Future Improvements

Potential extensions for this project include:

  • Adding additional weather-related MCP tools.

  • Supporting more external APIs.

  • Adding automated tests for MCP tools.

  • Improving error handling and retry logic.

  • Adding logging and observability.

  • Supporting multiple LLM providers.

  • Adding a web-based user interface.

  • Extending the agent with additional tool capabilities.


πŸ“š References

  • Model Context Protocol (MCP) β€” Protocol for connecting LLM applications with external tools and data sources.

  • National Weather Service API β€” Provides weather forecasts and alerts.

  • Google Gemini API β€” Provides LLM capabilities and function/tool calling.

  • uv β€” Python package and environment management.


⭐ Why This Project?

The goal of this project is to demonstrate a practical implementation of an LLM-powered agent that can discover tools, reason about when to use them, execute external operations, and incorporate live API data into its responses.

It serves as a hands-on example of combining Python, MCP, LLM tool calling, APIs, structured data validation, and agentic workflows into a single application.

Available Tools

2 tools
get_alertsC

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
alertsYes

TDQS

C2.8/5.0
Behavior1/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. The description only states the function and parameter, with no mention of rate limits, data scope, response format, or any side effects. For a read-only weather alerts tool, the lack of any behavioral context is a significant gap.

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 concise and front-loaded with the main verb. It includes the necessary parameter explanation in a single line. It is efficient with no wasted words, though it could arguably include more context without becoming 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?

The tool has an output schema (not shown), which may cover return format, but the description lacks usage guidance relative to the sibling tool and any behavioral notes. Given the simplicity of the tool, the description is still incomplete because it does not tell the agent when to use this over get_forecast or what to expect in terms of alerts.

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?

Schema coverage is 0%, so the description must compensate. It does explain the parameter 'state' as a 'Two-letter US state code (e.g. CA, NY)', providing format and examples. This adds meaningful meaning beyond the bare schema property name, effectively clarifying the expected input.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Get weather alerts for a US state' with a specific verb and resource. It is unambiguous about the action, but it does not differentiate from the sibling tool get_forecast. The name and description make the purpose clear, but a mention of the alternative would elevate it.

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?

No guidance is given on when to use get_alerts versus get_forecast. The description implies alerts are different from forecasts, but it does not state when one should be chosen over the other, nor any exclusions or prerequisites. This leaves the agent to infer usage context.

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

get_forecastB

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
periodsYesThe forecast periods, soonest first
latitudeYesLatitude the forecast is for
longitudeYesLongitude the forecast is for

TDQS

B3.1/5.0
Behavior2/5

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

Annotations are absent so the description carries the full behavioral disclosure burden, yet it only restates the read action ('Get weather forecast'). It does not disclose side effects, return format, data sources, or any limitations beyond what the tool name already implies.

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 short, front-loaded with the core statement, and uses a clean Args format. Every line serves a purpose; nothing is wasted, though the Args section largely duplicates schema field titles.

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?

With only two self-explanatory parameters and an output schema present, the tool is nearly complete as documented. Missing optional details like coordinate units and range validation are minor for this simple tool.

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

Parameters3/5

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

Schema description coverage is 0%, and the description does add a minimal gloss by explaining latitude/longitude are 'of the location'. However, this barely compensates for the gap, and it omits useful semantics such as units (decimal degrees), ranges, or valid values.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource ('Get weather forecast') for a location, which clearly identifies the tool's purpose. It does not explicitly name or differentiate from the sibling tool get_alerts, but the resource difference (forecast vs alerts) is implied by the wording.

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 when-to-use guidance or mention of alternatives. The description gives no context for choosing this tool over get_alerts, nor any constraints like coordinate ranges or supported regions. The only hint is the implicit location scope.

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.

  1. 2 tool updatesv0.1.0
    • First observedget_alerts
    • First observedget_forecast

TDQS

B3.2/5.0

Scored across 2 tools

Disambiguation5/5

The two tools have clearly distinct purposes: one retrieves weather alerts for a state, the other retrieves forecasts for coordinates. There is no overlap in functionality or parameters, making misselection unlikely.

Naming Consistency5/5

Both tools follow the consistent get_verb_noun pattern: get_alerts and get_forecast. The naming is clean, predictable, and uses the same style throughout.

Tool Count3/5

With only 2 tools, the server feels minimal for a weather domain. While the count is not extreme, it is on the thin side and likely covers only a fraction of what the NWS API offers.

Completeness2/5

The NWS provides a broad range of weather data including current conditions, radar, marine forecasts, and fire weather, but this server only covers alerts and forecasts. Significant functionality is missing, which will limit agent workflows.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers

  • A
    license
    B
    quality
    D
    maintenance
    Enables AI assistants to access real-time US weather forecasts and alerts through the National Weather Service API.
    2
    5 npm
    MIT
  • F
    license
    B
    quality
    D
    maintenance
    Provides 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.
    2
    1
    -
  • F
    license
    Not graded
    quality
    D
    maintenance
    Provides real-time weather alerts and forecasts from the National Weather Service for US locations, integrating with AI assistants via the Model Control Protocol.
    -
  • F
    license
    Not graded
    quality
    D
    maintenance
    Provides weather forecasts and alerts for US locations via the National Weather Service API, enabling AI assistants to deliver real-time weather information.
    8 npm
    -