Skip to main content
Glama
cuolm

meteo-swiss-mcp

by cuolm

forecast_hourly

Get the weather hour by hour for a place: temperature with its likely range, chance of rain and the weather in words.

Instructions

        Get the weather hour by hour for a place: temperature with its likely range, chance
        of rain and the weather in words.

        Use this for one hour, such as "how warm is it at 15:00", or part of a day, such as "how
        is the afternoon" or "when is the best time for a walk". Without end it returns the one
        hour starting at start. Each row covers the hour from its "from" to its "to": the
        temperature is the mean of that hour, while the rain chance and the weather cover the 3
        hours up to "to", as MeteoSwiss publishes them only per 3 hours. For whole days or
        periods longer than a day use forecast_daily, which answers in far fewer rows, and for
        rain amounts forecast_rain.

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

        Returns:
            dict: The place, the forecast point used, one row per hour and the model run; the
                field names give the units. In 8 of 10 possible outcomes, the temperature lies
                between its 10th and 90th percentile.

        Examples:
            forecast_hourly("Zurich", "2026-09-23T15:00")                        # one hour
            forecast_hourly("Zurich", "2026-09-23T12:00", "2026-09-23T18:00")    # the afternoon
        

Input Schema

NameRequiredDescriptionDefault
endNo
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.5/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses the default single-hour behavior when 'end' is omitted, the aggregation semantics (temperature is the hour mean while rain chance and weather cover the 3 hours up to 'to', because MeteoSwiss publishes them per 3 hours), and the 8-day horizon. It stops short of covering failure modes (ambiguous place names besides 'near', out-of-range times) and any auth/rate constraints.

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?

Purpose and the aggregation caveat are front-loaded, followed by sibling routing, then Args/Returns/Examples in a conventional shape. The Examples block earns its place by showing the single-hour vs range call. A little boilerplate indentation and the redundant restatement of the 3-hour caveat in Returns keep it from a 5.

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, but the Returns section describes the payload (place, forecast point, one row per hour, model run, units from field names) and the percentile interpretation, which is enough to call and interpret confidently. The only gap is that the 'near' disambiguation parameter is not addressed in the prose despite no annotations anywhere.

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%, so the description must compensate, and it does: 'start' is specified as Swiss local time, full hour, ISO 8601 without offset, with an example and a 'today to 8 days ahead' range, and 'end' as optional and after start. The 'near' parameter is omitted from the Args block, leaving that one to the schema.

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+resource (hour-by-hour weather for a place) and enumerates the returned quantities: temperature with likely range, rain chance, and weather in words. It also distinguishes itself from siblings by naming forecast_daily and forecast_rain and the conditions that select them.

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?

Gives concrete use cases ('how warm is it at 15:00', 'how is the afternoon', 'best time for a walk') and explicit alternatives for the out-of-scope cases: forecast_daily for whole days or multi-day periods, forecast_rain for rain amounts. When-to-use and when-not are both present.

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