F
licenseNot graded
qualityD
maintenanceEnables fetching weather forecasts for the USA via NWS API and for Israel via browser automation using Playwright.
-
Weather MCP Server
by r0556763949
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., "@Weather MCP ServerWhat's the weather in San Francisco?"
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.
# Weather MCP Server š¤ļø
## About
This project implements an MCP Server that provides weather information to an LLM Agent.
The project demonstrates two different approaches:
- **USA Weather MCP** - retrieves weather information using the National Weather Service API.
- **Israel Weather MCP** - retrieves weather information using Playwright browser automation from the weather2day website.
The main goal is to demonstrate how an LLM Agent can use MCP Tools to interact with external sources and enrich its context.
---
## Technologies
- Python
- MCP SDK (FastMCP)
- OpenAI API
- Playwright
- httpx
---
## Project Structure
weather-mcp/
ā
āāā host.py
āāā client.py
āāā weather\\\_USA.py
āāā weather\\\_Israel.py
āāā README.md
---
# šŗšø USA Weather MCP
The USA MCP uses the National Weather Service API.
Available tools:
### get_forecast_in_USA
Returns weather forecast by location coordinates.
Input:
- Latitude
- Longitude
### get_alerts_in_USA
Returns active weather alerts for a USA state.
Input:
- State code (example: CA, NY)
---
# š®š± Israel Weather MCP
The Israel MCP uses Playwright to automate a browser and extract weather information from:
https://www.weather2day.co.il/forecast
The Agent can:
1. Open the weather website.
2. Enter a city name.
3. Select the requested city.
4. Extract weather information from the page.
5. Use the extracted information to answer the user.
Available tools:
### open_weather_forecast_israel
Opens the weather forecast website.
### enter_weather_forecast_city_israel
Receives a city name and enters it into the search field.
### select_weather_forecast_city_israel
Selects the first city from the autocomplete list.
### extract_weather_forecast_content_israel
Extracts weather information from the selected city page and provides it as context for the LLM.
### close_weather_browser
Closes the browser session.
---
## Installation
Install dependencies:
uv sync
Install Playwright browser:
uv run playwright install chromium
---
## Running
Run the project:
uv run host.py
---
## Example Questions
Israel:
×× ××× ××××××Ø ××× × ××Øק?
USA:
What is the weather in Miami?
---
## Learning Goals
This project demonstrates:
- Building a custom MCP Server
- Creating MCP Tools with FastMCP
- Connecting an LLM Agent to external tools
- Browser automation with Playwright
- Extracting information from websites
- Providing external context to an LLM (RAG)
Available Tools
2 toolsget_alerts_in_USAB
Get weather alerts for a USA state
Args: state: Two-letter USA state code (e.g. CA, NY)
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| state | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
B3.1/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden, yet it discloses nothing about behavior beyond the bare purpose. It does not say the operation is read-only, whether alerts are US-national or state-scoped at runtime, freshness/rate limits, or auth needs. An output schema exists, so return-value explanation is legitimately omitted, but the behavioral gaps remain.
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?
One short sentence plus a compact Args block; the purpose is front-loaded and nothing is padded. The Args formatting is slightly redundant with the schema but not wasteful.
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?
For a one-parameter read tool with an output schema, the description covers purpose and the parameter format adequately. What is missing is routing guidance relative to the get_forecast_in_USA sibling and any read-only/safety framing, given zero annotations.
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 description coverage is 0% (the schema only labels the field 'State'), so the description must compensate, and it does: it specifies the format as a two-letter USA state code with examples (CA, NY). That is meaningful added meaning beyond the raw schema, though casing/validation rules are unstated.
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?
States a specific verb and resource ('Get weather alerts') scoped to a USA state, which is clear enough to distinguish from the get_forecast_in_USA sibling in practice. It never explicitly names that sibling or clarifies the alerts-vs-forecast distinction, so it stops short of a 5.
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 when-to-use guidance, no conditions or exclusions, and the sibling get_forecast_in_USA is not mentioned. The agent gets no help deciding between alerts and forecast from this description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_forecast_in_USAC
Get weather forecast for a location in USA.
Args: latitude: Latitude of the location longitude: Longitude of the location
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| latitude | Yes | ||
| longitude | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
C2.8/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It implies a read-only operation by using 'Get', but does not state whether the tool requires authentication, has rate limits, or returns any particular forecast format, despite an output schema existing.
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 and front-loaded with the core purpose. The Args section is somewhat redundant with the input schema, but it does not obscure the main statement and remains easy to scan.
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?
For a simple two-parameter weather forecast tool with an output schema, the description covers the essential purpose but leaves gaps in usage guidance and parameter semantics. It is minimally viable, though an agent must infer coordinate conventions and when to prefer this tool over the sibling alerts tool.
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 description coverage is 0%, so the description must compensate for missing parameter documentation. It only repeats the parameter names with 'Latitude of the location' and 'Longitude of the location', adding no format, range, or coordinate-system details beyond the schema's titles and types.
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 in USA.' This clearly distinguishes it from the sibling get_alerts_in_USA, which likely returns weather alerts rather than forecasts. However, it does not explicitly name or contrast with the sibling tool.
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?
The description provides no guidance on when to use this tool versus get_alerts_in_USA, nor does it mention prerequisites, limitations, or exclusions. Usage is only implied by the tool name and basic purpose statement.
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_in_USA - First observed
get_forecast_in_USA
TDQS
B3.2/5.0
Scored across 2 tools
Disambiguation5/5
The two tools target clearly different data types: weather alerts versus weather forecasts. An agent can easily distinguish when to call each one.
Naming Consistency5/5
Both tools follow the same predictable verb_noun pattern with a consistent USA suffix: get_alerts_in_USA and get_forecast_in_USA.
Tool Count3/5
Only two tools is thin for a weather server. While they cover two useful operations, the surface feels under-scoped for general weather queries.
Completeness2/5
The server lacks current conditions, hourly/daily forecasts, historical data, location search, and any non-USA coverage. These are significant gaps for a general weather MCP server.
Maintenance
ActivityStale
ResponsivenessNo issues
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.
Global weather via Open-Meteo: forecast, historical, marine, air quality, geocoding, elevation.
US weather for AI agents: active NWS alerts by state, 5-period forecasts by lat/lon. Paid per call.
Related MCP Servers
- FlicenseAqualityDmaintenanceEnables users to query weather information for Israel via Playwright browser automation and for the USA via a weather API, allowing an LLM to access real-time weather data and alerts.4-
- FlicenseNot gradedqualityDmaintenanceProvides LLMs with real-time weather forecasts for Israeli cities using browser automation with Playwright to scrape live data from a weather website.-
- FlicenseNot gradedqualityCmaintenanceEnables natural language weather queries for Israeli cities with real-time data extracted via Playwright, plus USA weather alerts and forecasts via NWS API, all orchestrated by Groq LLM.1-