Skip to main content
Glama
bati3702

weather-chat-mcp

by bati3702
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

๐ŸŒฆ๏ธ Weather Israel MCP Server (Playwright)

The MCP that puts the LLM's hand on the mouse.
Weather forecasts Made in Israel โ€” not through a boring API, but the Israeli way: open a browser, poke your nose into the site, type, click... and get a forecast.

๐ŸŽฏ What is this project?

In the classic Weather MCP example, the LLM pulls weather data through a US API. Nice, but... who really cares about a forecast somewhere in the USA when you need the current temperature in Tel Aviv or Jerusalem?

This project builds an Israeli MCP Server that gives the LLM a completely human ability: to control a real browser. Instead of calling an API, the Agent:

  1. Opens a real Chromium browser (in headless=False mode, so you can watch it live!).

  2. Types a city name into the search field of weather2day.co.il.

  3. Picks the city from the autocomplete dropdown dynamically.

  4. Scrapes the page content, cleans it, and feeds it back to the LLM so it can answer on its own (Retrieval-Augmented Generation / RAG).

The big idea: Everything a human user does with two hands โ€” the LLM learns to do with four Tools.

Related MCP server: Israeli Weather MCP Agent

๐Ÿง  What you'll learn

  • Build your own MCP Server for any purpose or targeted website.

  • Expose Python functions as Tools for an LLM using the FastMCP decorator.

  • Use Playwright to give an LLM physical control over a browser (mouse & keyboard simulation).

  • Build RAG (Retrieval-Augmented Generation): Stream live, freshly-scraped page content directly into the model's context.

  • Sync & Stability: Handle dynamic web element loading and prevent flakiness in browser automation.

๐Ÿ“‚ Project Structure

project-template/ โ”œโ”€โ”€ weather_Israel.py # MCP Server โ€” Israel forecast via Playwright โ”œโ”€โ”€ host.py # Terminal chat โ€” connects the LLM to the MCP server โ”œโ”€โ”€ client.py # Generic MCP Client (stdio communication) โ”œโ”€โ”€ pyproject.toml # Project dependencies and metadata (uv) โ””โ”€โ”€ .env # Environment variables (OpenAI API key)

๐Ÿ› ๏ธ Technologies Used

  • Python 3.13+

  • FastMCP (MCP SDK) - Anthropic's official framework for building Model Context Protocol servers easily.

  • Playwright (Python Async API) - Advanced browser automation and control library.

  • OpenAI API - The brain of the Agent (powered by gpt-4o-mini), deciding which tools to call and interpreting the results.

๐Ÿงฉ The Four Tools of the Israeli MCP

The manual steps a human performs on the website are broken down into 4 modular tools that the LLM calls sequentially:

Tool

What it does

Human equivalent

open_weather_forecast_israel

Launches Chromium in non-headless mode and navigates to the forecast site.

Open a browser and go to the site.

enter_weather_forecast_city_israel(city)

Finds the search field, clears it, and types the city name char-by-char to trigger autocomplete.

Click the search bar and type the city name.

select_weather_forecast_city_israel

Detects the dropdown list, clicks the first auto-complete suggestion, and waits for the city page to load.

Click on the correct city from the suggestions.

get_forecast_content_israel

Scrapes the loaded page, cleans up redundant spaces and empty lines, and feeds it back to the LLM.

Read the forecast details on the screen.

Why not just search Google?
Running a Google search through automated browsers quickly triggers CAPTCHA challenges. By guiding the Agent through a direct, targeted flow on a specific website, we bypass bot detection completely and guarantee a seamless run.

๐Ÿ›ก๏ธ Loop Protection (ืžื ื’ื ื•ืŸ ืžื ื™ืขืช ืœื•ืœืื•ืช)

During development, we identified that LLMs can sometimes get stuck in an infinite loop, calling the same tool repeatedly (such as trying to open the browser over and over).

To prevent this, we implemented a strict Loop Protection Mechanism inside host.py:

  • The host keeps track of all executed tools within the current turn.

  • If the LLM tries to invoke the same tool more than once per turn, the call is blocked and a system message is returned: "This action has already been completed in this turn. Please proceed to the next step."

  • This forces the LLM to progress linearly: Open โž” Type โž” Select โž” Scrape.

๐Ÿš€ Setup & Run (ืฉืœื‘ ืื—ืจ ืฉืœื‘)

This project is managed using uv for ultra-fast dependency management.

  1. Install dependencies and set up the environment: Command: uv sync

  2. Install the Chromium browser for Playwright: Command: uv run playwright install chromium

  3. Configure your API key: Create a .env file in the project root and add your OpenAI API key: OPENAI_API_KEY=your_actual_api_key_here (The .env file is already listed in .gitignore to ensure your secret key is never pushed to public repositories).

  4. Start the Chat Agent: Command: uv run host.py

    Type your query in the terminal, press Enter, and watch the browser open and perform the actions on its own! To exit, simply type "quit".

๐Ÿ’ฌ Example Questions to Try

The Agent will analyze your request and trigger the correct sequence of tools automatically. Try asking:

  • "ืžื” ืžื–ื’ ื”ืื•ื•ื™ืจ ื‘ื™ืจื•ืฉืœื™ื ื”ื™ื•ื?" (What's the weather in Jerusalem today?)

  • "Check the temperature in Tel Aviv for the upcoming days"

  • "ื”ืื ืฆืคื•ื™ ืœืจื“ืช ื’ืฉื ื‘ื—ื™ืคื” ืžื—ืจ? ืžื” ืื—ื•ื–ื™ ื”ืœื—ื•ืช?"

๐Ÿ’ญ A Closing Thought

Playwright was born long before the GenAI era โ€” originally designed as a testing automation tool for developers. But with the rise of AI Agents, it has taken center stage. Suddenly, giving an LLM "hands and a mouse" to interact with the real web has become the ultimate way to bridge the gap between static knowledge and real-world actions.

Available Tools

4 tools
enter_weather_forecast_city_israelA

ืžื–ื™ืŸ ืฉื ืขื™ืจ ื‘ืฉื“ื” ื”ื—ื™ืคื•ืฉ ืฉื‘ื“ืฃ ืžื–ื’ ื”ืื•ื™ืจ. ื™ืฉ ืœืงืจื•ื ืœืคื•ื ืงืฆื™ื” open_weather_forecast_israel ืœืคื ื™ ืฉื™ืžื•ืฉ ื‘ืคื•ื ืงืฆื™ื” ื–ื•.

Args: city: ืฉื ื”ืขื™ืจ ืœื—ื™ืคื•ืฉ (ืœื“ื•ื’ืžื”: 'ืชืœ ืื‘ื™ื‘', 'ื™ืจื•ืฉืœื™ื')

ParametersJSON Schema
NameRequiredDescriptionDefault
cityYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.9/5.0
Behavior2/5

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

No annotations provided, so description carries full burden. It only states the basic input action, with no details on side effects, expected behavior after entering (e.g., submission), or error handling.

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?

Extremely concise: two sentences plus an args line. Prerequisite is front-loaded, and the parameter explanation is direct. No wasted words.

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?

Given the tool's simplicity (one parameter, no output schema shown), the description is adequate but lacks detail on post-entry behavior or whether the tool triggers any action. It meets minimum viability.

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%, so description must fully explain the single parameter 'city'. It provides a clear explanation with examples, adding value beyond the schema's minimal definition.

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 action: entering a city name into a search field on a weather page. It distinguishes from siblings by specifying prerequisite and context.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly requires calling 'open_weather_forecast_israel' first, providing clear prerequisite. No mention of when not to use or alternatives, but adequate for a simple tool.

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

get_forecast_content_israelA

ืžื—ืœืฆืช ืืช ืชื•ื›ืŸ ื”ืชื—ื–ื™ืช ืžื”ื“ืฃ ื”ื˜ืขื•ืŸ ืœืื—ืจ ื‘ื—ื™ืจืช ืขื™ืจ. ื™ืฉ ืœืงืจื•ื ืœืคื•ื ืงืฆื™ื” ื–ื• ืจืง ืœืื—ืจ ื‘ื—ื™ืจืช ื”ืขื™ืจ ื‘-select_weather_forecast_city_israel.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.6/5.0
Behavior4/5

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

No annotations provided, but description indicates a read operation ('extracts content'). Specifies precondition. Does not detail error behavior if called prematurely, but sufficient for a simple tool.

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?

Two sentences, front-loaded with purpose and condition. No redundant information; every word is useful.

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 an output schema present, the description adequately covers usage context. Could mention that the page must be loaded, but implied by the sequential dependency.

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?

Zero parameters, baseline score of 4. Description does not need to add parameter info as there are none.

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 action: extracting forecast content after city selection. It differentiates from siblings by specifying the dependency on select_weather_forecast_city_israel.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use: only after selecting the city via select_weather_forecast_city_israel. Provides clear sequential context with no ambiguity.

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

open_weather_forecast_israelA

ืคื•ืชื— ื“ืคื“ืคืŸ Chromium ื•ืžื ื•ื•ื˜ ืœืืชืจ ืžื–ื’ ื”ืื•ื™ืจ ื”ื™ืฉืจืืœื™. ื™ืฉ ืœืงืจื•ื ืœืคื•ื ืงืฆื™ื” ื–ื• ืจืืฉื•ื ื” ืœืคื ื™ ื›ืœ ืคืขื•ืœื” ืื—ืจืช.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.3/5.0
Behavior3/5

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

Describes opening Chromium and navigating to a site, but lacks details on side effects (e.g., waiting for page load, session management) given no annotations are provided.

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?

Two sentences with no waste: first states purpose, second gives usage order. Highly efficient and front-loaded.

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

Completeness5/5

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

For a no-parameter initialization tool with an output schema and sibling tools covering subsequent steps, this description fully informs the agent of its role and prerequisites.

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?

No parameters exist; baseline is 4. Description adds no parameter info, which is appropriate since none are needed.

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 uses a specific verb ('opens and navigates') and resource ('Chromium browser to Israeli weather website'), clearly distinguishing from sibling tools that handle city entry, content retrieval, and selection.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states 'must call this function first before any other action', providing clear sequential guidance. Does not mention when not to use or alternatives, but the context with siblings implies this is a prerequisite.

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

select_weather_forecast_city_israelA

ื‘ื•ื—ืจืช ืืช ื”ืคืจื™ื˜ ื”ืจืืฉื•ืŸ ื‘ืจืฉื™ืžืช ื”ืขืจื™ื ืฉื”ื•ืคื™ืขื” ืœืื—ืจ ื”ื”ืงืœื“ื”. ื™ืฉ ืœืงืจื•ื ืชื—ื™ืœื” ืœ-enter_weather_forecast_city_israel.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.1/5.0
Behavior3/5

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

No annotations are provided, so the description carries the burden of behavioral disclosure. It only states that the tool selects the first item, but does not disclose what happens after selection (e.g., navigation, field population), error handling, or what to do if the list is empty.

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 extremely concise with two short sentences. The first sentence states the action, and the second provides a prerequisite. No unnecessary words, and the key information is front-loaded.

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?

Given the tool's simplicity with no parameters and the existence of an output schema, the description covers the basic purpose and prerequisite. However, it lacks details about what the tool returns or what state changes occur after selection, which could leave the agent underinformed.

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 tool has no parameters, and schema description coverage is trivially 100%. Per guidelines, 0 parameters yields a baseline of 4. The description adds no parameter information, which is appropriate since there are none.

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 selects the first item from a city list after typing, and it distinguishes itself by mentioning the prerequisite sibling tool. The verb 'select' and the specific context 'first item from list of cities' make the purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states that enter_weather_forecast_city_israel must be called first, providing clear usage context and a prerequisite. It does not mention when not to use, but for a simple selection tool, this is sufficient guidance.

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. 4 tool updatesv0.1.0
    • First observedenter_weather_forecast_city_israel
    • First observedget_forecast_content_israel
    • First observedopen_weather_forecast_israel
    • First observedselect_weather_forecast_city_israel
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.2/5.0

Scored across 4 tools

Disambiguation5/5

Each tool has a clearly distinct role in a sequential workflow: open browser, enter city, select from list, extract forecast. No overlap in purpose.

Naming Consistency4/5

Names follow a consistent pattern of verb_noun_location (e.g., open_weather_forecast_israel), though they are quite verbose. Slight inconsistency in 'enter_weather_forecast_city_israel' vs 'select_weather_forecast_city_israel' but still readable.

Tool Count5/5

Four tools is well-scoped for a focused weather forecast retrieval task. No unnecessary bloat.

Completeness4/5

Covers the essential steps to retrieve a forecast from a specific Israeli weather site. Missing generic options like city validation or error recovery, but sufficient for the intended workflow.

Maintenance

ActivityStale
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • Weather Israel MCP Server

    Rivka55
    F
    license
    A
    quality
    C
    maintenance
    Enables querying weather forecasts for Israeli cities by automating browser with Playwright, extracting data from Weather2Day website, and feeding it to an LLM for natural language responses.
    4
    -