Skip to main content
Glama
nechamiToledano

weather-Israel

by nechamiToledano
OverviewSchemaRelated ServersScoreDiscussions
Python
Local

MCP with Playwright — Israeli Weather Forecast

An MCP server that gives an LLM the ability to control a real browser (via Playwright) and fetch weather forecasts for Israeli cities from weather2day.co.il, instead of calling a conventional weather API.

This project is the Israeli counterpart to the bundled weather_USA.py demo (which calls the US National Weather Service API). Here, the "API" is a human user's browsing flow, automated end-to-end.

How it works

  1. open_weather_forecast_israel — opens a headless Chromium browser and navigates to https://www.weather2day.co.il/forecast.

  2. enter_weather_forecast_city_israel — types the requested city name into the site's search box, triggering its autocomplete dropdown.

  3. select_weather_forecast_city_israel — clicks the first suggestion in the dropdown, which navigates to that city's forecast page.

  4. get_weather_forecast_content_israel — extracts the visible text of the resulting page, cleans it up, and hands it back to the LLM as context (RAG), so the LLM can answer the user's question directly in the chat instead of just leaving the browser open on the page.

The LLM (via host.py) decides on its own, based on the user's question, which of these 4 tools to call and in what order.

Related MCP server: weather-israel-mcp

Project structure

.
├── client.py            # Generic MCP client (provided)
├── host.py              # Terminal chat loop that wires everything together
├── weather_USA.py       # US forecast MCP server (provided, via NWS API)
├── weather_Israel.py    # ← This project: Israeli forecast MCP server (Playwright)
├── pyproject.toml
├── uv.lock
├── .env.example
└── README.md

Setup

  1. Install dependencies:

    uv sync

  2. Install the Chromium browser for Playwright:

    uv run playwright install chromium

  3. Copy .env.example to .env and fill in your GOOGLE_API_KEY.

  4. Run the chat host:

    uv run host.py

⚠️ If a tool call fails / selectors need tuning

weather2day.co.il's exact HTML (class names, ids) can change, and the autocomplete widget is rendered dynamically by JavaScript. The 3 CSS selectors used in weather_Israel.py (search input, dropdown item, forecast content container) are defined as constants at the top of the file:

SEARCH_INPUT_SELECTOR = "..."
DROPDOWN_ITEM_SELECTOR = "..."
FORECAST_CONTENT_SELECTOR = "..."

If a tool call times out, the fastest fix is to record the real selectors yourself:

uv run playwright codegen https://www.weather2day.co.il/forecast

This opens a browser + Inspector panel. Click into the city search field and select a city manually — Playwright will show you the exact selector/action it recorded in the Inspector. Copy the corrected selector into the matching constant in weather_Israel.py.

Example questions to ask the Agent

  • "מה התחזית להיום בתל אביב?"

  • "האם צפוי גשם בחיפה השבוע?"

  • "מה הטמפרטורה הצפויה בירושלים מחר?"

  • "יש התראות מזג אוויר בבאר שבע?"

  • (English also works) "What's the weather like in Eilat right now?"

The agent will pick the weather-Israel MCP server for Israeli cities and the weather-USA MCP server for US states/coordinates.

Notes

  • The browser runs headless by default (no visible window). To watch it work while debugging, change headless=True to headless=False in open_weather_forecast_israel.

  • Each call to open_weather_forecast_israel closes any previously-open browser session first, so re-asking a new question starts clean.

Available Tools

4 tools
enter_weather_forecast_city_israelA

Type a city name into the forecast website's search field.

Args: city: The Hebrew (or English) name of the Israeli city to search for, e.g. "תל אביב" or "חיפה".

ParametersJSON Schema
NameRequiredDescriptionDefault
cityYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.7/5.0
Behavior3/5

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

No annotations are provided, so the description must carry the burden. It describes an input action but does not disclose potential side effects (e.g., clearing previous text) or whether it triggers a search. A simple action like this may be adequately transparent, but more detail would help.

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, using only two lines plus the parameter documentation. Every sentence is necessary and information-dense, with no wasted words.

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?

Given the simplicity of the tool (one parameter) and the existence of an output schema, the description is nearly complete. It lacks context about how this tool fits into a workflow with siblings (e.g., after opening the website, before fetching content), but this is a minor gap.

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

Parameters5/5

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

The description adds significant value beyond the schema by specifying that the city can be in Hebrew or English, and provides examples. This compensates for the schema's lack of parameter descriptions (0% coverage).

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 the action: typing a city name into the forecast website's search field. It uses a specific verb and resource, and the tool name adds context. However, it does not explicitly connect this action to a broader goal like retrieving a forecast, which would improve clarity.

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 on when to use this tool versus sibling tools. The description only explains the action itself, without mentioning prerequisites (e.g., the website should be open) or when not to use it.

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

get_weather_forecast_content_israelA

Extract and clean the text content of the currently open forecast page, so the LLM can read the forecast directly and answer the user's question without the user needing to look at the browser themselves.

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?

No annotations; description discloses it extracts and cleans (read operation) but doesn't detail what 'clean' entails or any side effects. Adequate but not rich.

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?

Single sentence with no wasted words, front-loaded with purpose. Efficient.

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-param tool with output schema, description fully explains what it does and why, with no missing information.

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; schema coverage 100% trivially. Description adds value by explaining why the tool exists, meeting baseline for no params.

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?

Clearly states the tool extracts and cleans text content of the forecast page, with a specific purpose (so LLM can read it). Distinguishes from siblings like enter/select/open.

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?

Describes when to use (when forecast page is open and LLM needs to read it). No explicit when-not or alternatives, but context is clear.

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

Open a browser and navigate to the Israeli weather forecast website (weather2day.co.il/forecast). Call this first, before searching for a city.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.7/5.0
Behavior4/5

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

No annotations, but the description clearly states the action (open browser, navigate to URL). No hidden behaviors implied; the simple action is transparently described.

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, no filler, directly conveys purpose and usage order.

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?

Given zero parameters and presence of output schema, the description fully covers the tool's function and when to call it.

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, schema coverage 100%. Description adds no param info but none 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?

Specific verb 'Open a browser and navigate' with exact URL provided. Clearly distinguishes from siblings which handle city-specific actions.

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?

Explicit instruction 'Call this first, before searching for a city' provides clear sequence for agent.

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

Select the first city suggestion from the search dropdown that appeared after enter_weather_forecast_city_israel was called, and navigate to that city's forecast page.

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 provided. The description explains the action but does not cover edge cases like missing dropdown or errors. For a simple 0-parameter tool, it adds some value beyond the empty schema.

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 sentence, front-loaded with the action and prerequisite. It is concise but could be slightly tighter. No wasted words.

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?

Given 0 parameters and no annotations, the description adequately sets context, especially with sibling tools. It lacks details on failure modes but is sufficient for typical use.

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?

There are no parameters, so schema coverage is 100%. The description does not need to add parameter info. Baseline 4 is appropriate.

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 city suggestion from a dropdown after a specific preceding step and navigates to the forecast page. It distinguishes from siblings by naming the prerequisite tool and implying a sequential workflow.

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 tells when to use this tool (after enter_weather_forecast_city_israel is called), providing clear context. It lacks explicit exclusions or alternative uses, but the sequential nature is well communicated.

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. Dates show when Glama detected each change.

  1. 4 tool updatesv0.1.0
    • First observedenter_weather_forecast_city_israel
    • First observedget_weather_forecast_content_israel
    • First observedopen_weather_forecast_israel
    • First observedselect_weather_forecast_city_israel
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.1/5.0
Disambiguation5/5

Each tool has a distinct role: opening browser, entering city name, selecting from dropdown, and extracting content. No overlap.

Naming Consistency4/5

All tools follow a consistent 'verb_weather_forecast_x_israel' pattern, though names are verbose.

Tool Count5/5

4 tools are appropriate for the simple workflow of retrieving a city weather forecast.

Completeness4/5

Covers the full pipeline from opening site to reading forecast; missing a cleanup or error recovery tool.

Maintenance

ActivitySlowing
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/nechamiToledano/MCP-with-Playwright'

If you have feedback or need assistance with the MCP directory API, please join our Discord server