Provides a natural language interface to query US weather data via Google's Gemini AI.
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., "@MCP What are the current weather alerts in CA?"
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 Simple implementation of a command-line tool that provides access to US weather data through a client-server architecture using the Model Context Protocol (MCP) and Google's Gemini AI. Built to practive and understand how MCP works.
This project connects a Python client application with a weather data server, allowing users to query weather information using natural language. The server communicates with the National Weather Service API to retrieve weather alerts and forecasts.
Related MCP server: mcp-foundry
Query weather alerts for US states using state codes
Get detailed weather forecasts for specific locations using latitude and longitude
Natural language interface powered by Google's Gemini AI
Client-server architecture using Model Context Protocol (MCP)
Python 3.8+
Node.js (if running JavaScript server)
Google Gemini API key
Clone the repository:
git clone https://github.com/Abhinavexists/MCP_Server.git
cd weather-toolInstall uv if you don't have it already:
pip install uvCreate and activate a virtual environment:
uv venvOn Windows: .venv\Scripts\activate
On macOS/Linux: source .venv/bin/activate
Install dependencies using uv (this project uses uv.lock and pyproject.toml):
uv pip syncCreate a .env file in the project root directory with your Gemini API key:
GEMINI_API_KEY=your_gemini_api_key_hereStart the client and connect to the weather server:
python client.py server.pyOnce connected, you can ask questions about weather information:
Query: What are the current weather alerts in CA?
Query: What's the forecast for latitude 37.7749, longitude -122.4194?Type quit to exit the application.
The server provides the following tools:
get_alerts: Fetches weather alerts for a specified US state (using two-letter state code)
get_forecast: Retrieves weather forecasts for a specific location (using latitude and longitude)
client.py: MCP client that connects to the server and processes user queries using Gemini AI
server.py: MCP server that implements weather data tools and communicates with the National Weather Service API
The application includes robust error handling for:
Invalid server script paths
Connection issues with the NWS API
Invalid or missing data in API responses
Add additional weather data endpoints
Implement caching for frequently requested data
Add support for location name lookup (instead of requiring lat/long)
Create a web interface
For more information about Model Context Protocol (MCP), refer to the official Claude MCP documentation:
Get weather alert for US states.
Args:
state: Two-letter US state code (e.g. CA, NY)
| Name | Required | Description | Default |
|---|---|---|---|
| state | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses nothing about what an alert response contains, alert severity/type, rate limits, or error behavior (e.g., non-US input). For a read tool this is a minimal but real 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?
Front-loaded one-line purpose followed by a tidy Args block. No wasted sentences; appropriately sized for a single-parameter tool.
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?
For a simple one-param read tool with no output schema, the description is adequate but thin. It never hints at the return shape (list of alerts, active vs historical) or what happens with an invalid state code.
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 single schema property has no description, so the description must compensate. It does by specifying 'Two-letter US state code (e.g. CA, NY)', giving both format and concrete examples — genuinely useful beyond the bare schema.
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 alert for US states.' It makes the domain (US state alerts) clear and implicitly distinguishes itself from the forecast sibling, though it never names or contrasts with get_forcast explicitly.
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 guidance on when to use this tool versus get_forcast or any alternative. The agent must infer that alerts and forecasts are different queries from the names alone.
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 |
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, but it discloses nothing about data source, update frequency, units, error behavior, or return format. A read operation is implied by 'Get' but nothing beyond that is stated.
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 prose is short and front-loaded with the purpose. The Args block is somewhat redundant with the schema, but it does not bloat the description significantly.
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?
For a two-required-parameter tool with no annotations, no output schema, and 0% schema description coverage, the description should explain parameter format and expected return. It covers neither, leaving the agent under-informed before invocation.
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%, so the description must compensate, yet it only restates 'Latitude of the location' and 'Longitude of the location' — the same content already in the property titles. No format, range, or coordinate-system details are added.
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?
States a clear verb+resource: 'Get weather forecast for a location.' The scope (single-location forecast) is identifiable, though the sibling get_alerts is not referenced, so an agent must infer that forecasts and alerts are distinct.
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 when-to-use, when-not-to-use, or alternative guidance is provided. The existence of get_alerts as a sibling goes unmentioned, leaving selection between forecast and alerts entirely to the agent's inference.
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_forcastScored across 2 tools
get_alerts and get_forecast clearly serve distinct purposes: one retrieves alerts for a state, the other a forecast by coordinates. There is no ambiguity between them.
Both tool names follow a consistent get_ + noun pattern, matching the domain (alerts, forecast). The naming style is uniform and predictable.
With only two tools, the server feels very minimal, likely covering only a narrow subset of weather functionality. It is borderline appropriate for a highly focused server but may be too thin for general weather use.
The surface is extremely limited: no support for current conditions, alerts by coordinates, or marine/aviation forecasts. Users needing basic weather data beyond forecast or state alerts will find the server inadequate.
Hosted MCP server for Xweather weather data: conditions, forecasts, alerts, and more.
MCP server for weather with reasoning — umbrella advice, outdoor checks, city comparisons.
Weather, code search, currency & Solana trust scoring as MCP tools. Free, no API key needed.
An MCP server for weather information by @kulybaba