Skip to main content
Glama
cuolm

meteo-swiss-mcp

by cuolm

rain_outlook

Get 3-hour rain chance and rainfall amounts for a Swiss location to know if you need an umbrella or when rain will stop.

Instructions

        Get when and how much it may rain at a location, 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.

        Args:
            location (str): Location name (e.g., "Zurich") or Swiss postal code (e.g., "8001").
            start (str): Swiss local time the period starts, 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, ISO 8601 without offset, at most 48 hours after start.

        Returns:
            dict: The resolved location with its altitude, one row per 3-hour block (from, to,
                rain chance in percent, median rainfall and wettest hour's "up to" amount in
                millimetres), and the model run.

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

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
endYes
startYes
locationYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.2.0

TDQS

A5/5.0
Behavior5/5

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

No annotations are provided, so the description carries full responsibility. It discloses the return structure (dict with resolved location, altitude, per-block rows, and model run), explains that the median is often 0 when showers are possible and advises reading the chance and 'up to' amount, and states time constraints (start today or up to 8 days ahead, end at most 48 hours after). This is thorough and proactive.

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 well-structured with Args, Returns, and Examples sections. It front-loads the core purpose and usage, then provides concise yet complete parameter details. Every sentence adds value—no filler. The examples are illustrative and directly useful for an agent.

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 the tool's moderate complexity and lack of annotations/output schema, the description is exceptionally complete. It explains the output format, parameter constraints, interpretation guidance, and even provides two example calls. An agent has everything needed to select and invoke it correctly.

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?

Schema coverage is 0%, but the description fully documents each parameter: location (name or Swiss postal code), start (Swiss local time ISO 8601 without offset, with valid range), and end (same format, max 48 hours after start). It adds essential format and constraint details that the schema completely lacks.

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 states a specific verb ('Get') and a clear resource: when and how much it may rain in 3-hour blocks. It differentiates from siblings like hourly_forecast and daily_forecast by focusing exclusively on rain probability and amounts, and it names the exact use cases ('will it rain this afternoon', 'do I need an umbrella'). The purpose is unmistakable.

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?

The description explicitly says 'Use this for...' and lists three concrete scenarios. It also implicitly distinguishes from alternative forecast tools by focusing on rain-specific data and 3-hour resolution. While it doesn't name alternatives, the guidance is clear and actionable, leaving no ambiguity about when to invoke this tool.

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