NWS 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., "@NWS Weather MCP ServerWhat's the forecast for Chicago?"
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.
π€οΈ 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
FunctionDeclarationobjects, 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_alertsget_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-server2. Install Dependencies
Initialize the environment and install the project dependencies using uv:
uv sync3. 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.pyThe client will:
Start the MCP weather server.
Establish communication with the server.
Discover the available MCP tools.
Convert MCP schemas into Gemini function declarations.
Send the available tools to Gemini.
Process the user's request.
Execute the required weather tools.
Retrieve live data from the NWS API.
Return the tool results to Gemini.
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_keyInstead, 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 toolsget_alertsC
Get weather alerts for a US state.
Args:
state: Two-letter US state code (e.g. CA, NY)
| Name | Required | Description | Default |
|---|---|---|---|
| state | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| alerts | Yes |
TDQS
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.
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.
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.
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.
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.
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
| Name | Required | Description | Default |
|---|---|---|---|
| latitude | Yes | ||
| longitude | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| periods | Yes | The forecast periods, soonest first |
| latitude | Yes | Latitude the forecast is for |
| longitude | Yes | Longitude the forecast is for |
TDQS
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.
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.
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.
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.
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.
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.
2 tool updates
v0.1.0- First observed
get_alerts - First observed
get_forecast
TDQS
Scored across 2 tools
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.
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.
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.
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
Related MCP Connectors
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.
Get US weather forecasts, active alerts, and current observations.
Provide real-time and forecast weather information for locations in the United States using naturaβ¦
Related MCP Servers
- AlicenseBqualityDmaintenanceEnables AI assistants to access real-time US weather forecasts and alerts through the National Weather Service API.25 npmMIT
- 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-
- FlicenseNot gradedqualityDmaintenanceProvides real-time weather alerts and forecasts from the National Weather Service for US locations, integrating with AI assistants via the Model Control Protocol.-
- FlicenseNot gradedqualityDmaintenanceProvides weather forecasts and alerts for US locations via the National Weather Service API, enabling AI assistants to deliver real-time weather information.8 npm-