Skip to main content
Glama
Sign In
cuolm

meteo-swiss-mcp

by cuolm
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

forecast_rain

Get when and how much it may rain at a place, in 3-hour blocks over a period.

Instructions

        Get when and how much it may rain at a place, in 3-hour blocks over a period.

        Use this for "will it rain this afternoon", "do I need an umbrella" or "when does the
        rain stop". Each block gives the chance of rain, the median rainfall of the 3 hours, and
        how much the wettest hour of the block may bring (its 90th percentile). The median is
        often 0 when showers are possible, so read the chance and the "up to" amount as well.
        A period up to the end of the forecast ends with its last full 3-hour block.

        Args:
            location (str): Place name: a town, village, city district, lake or peak (e.g., "Zurich").
            start (str): Swiss local time the period starts, as a full hour in ISO 8601 without offset, e.g. "2026-09-23T12:00". Today or up to 8 days ahead.
            end (str): Swiss local time the period ends, as a full hour in ISO 8601 without offset, after start.

        Returns:
            dict: The place, the forecast point used, one row per 3-hour block and the model
                run; the field names give the units.

        Examples:
            forecast_rain("Zurich", "2026-09-23T12:00", "2026-09-24T00:00")
            forecast_rain("Lugano", "2026-09-24T06:00", "2026-09-24T18:00")

Input Schema

NameRequiredDescriptionDefault
endYes
nearNoOnly when several places share the name: a village next to the place the user means. For "the Blausee near Bettmeralp" use location "Blausee" and near "Bettmeralp". Leave it out otherwise.
startYes
locationYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.3.0

TDQS

A4.3/5.0
Behavior4/5

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

With no annotations, the description carries the burden and does it well: it explains that each block reports chance, median rainfall, and a 90th-percentile "up to" amount, warns that median is often 0 for showers, and discloses that a period past the forecast horizon truncates at the last full 3-hour block. It doesn't mention any auth, rate limits, or cost, which are the remaining gaps.

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?

It is front-loaded with the core purpose and the disambiguating usage line before the mechanics. The Args/Returns/Examples block is somewhat redundant with the prose and schema for a fairly simple tool, but nothing is misleading.

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?

No output schema exists, and the description compensates by describing the returned dict's shape (place, forecast point, one row per block, model run) and noting units live in field names. Combined with the statistical interpretation guidance, an agent has enough to call and read it correctly.

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 coverage is only 25% (just `near`), so the description must compensate, and it does: location is defined with examples of acceptable place types, and start/end are specified as Swiss local time, full-hour ISO 8601 without offset, with start constrained to today through 8 days ahead. The only undocumented item is the `near` parameter's interaction, which the schema handles.

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?

States a specific verb and resource — when and how much it may rain at a place, in 3-hour blocks — which cleanly separates it from sibling tools like forecast_daily, forecast_hourly, and forecast_wind.

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?

Gives concrete triggering questions ("will it rain this afternoon", "do I need an umbrella", "when does the rain stop"), which makes the intended use unambiguous. It never explicitly names a sibling as the alternative for non-rain questions, so it stops short of full routing guidance.

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

Deploy Server

Other Tools