Skip to main content
Glama
meteo-swiss-mcp

meteo-swiss-mcp

by cuolm

measurements_extremes

Read-only

Find where in Switzerland it is currently warmest, coldest, windiest, wettest or sunniest using MeteoSwiss station readings; returns top stations, altitude, and sunshine/rain counts.

Instructions

        Get where in Switzerland it is warmest, coldest, windiest, wettest or sunniest now.

        Use this for "where is it warmest now" or "where is it sunny now". The values are those
        of about 160 MeteoSwiss stations, so give the altitude with each station. For the
        sunniest, the stations are grouped by their sun in the last 10 minutes with MeteoSwiss's
        sunshine terms: mostly sunny (8 to 10 minutes), rather sunny (5 to 7), partly sunny (2 to
        4), only a little sunshine (1) and hardly any sunshine (0). The cantons come in order of
        their stations' average sun, sunniest first. A station is rainy when it had rain in the
        last 10 minutes.

        Args:
            extreme (str): One of "warmest", "coldest", "windiest", "wettest" or "sunniest".

        Returns:
            dict: The time of the measurements and the first 5 stations. For the sunniest instead
                the number of stations in each sunshine group, in Switzerland and in each canton,
                the sunniest canton first. For the wettest also the number of rainy stations out of
                those that measure rain, in Switzerland and in each canton.

        Examples:
            measurements_extremes("warmest")
        

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "extreme": "<extreme>"
    },
    "name": "measurements_extremes"
  }
}

Input Schema

NameRequiredDescriptionDefault
extremeYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.4.0

TDQS

A4.6/5.0
Behavior5/5

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

Goes well beyond the readOnlyHint/openWorldHint annotations: it discloses the ~160-station MeteoSwiss source, instructs the caller to report altitude with each station, and defines the sunshine bucketing (8-10 min = mostly sunny, down to 0) and the 'rainy' criterion. The canton ordering rule and the wettest-tool denominator ('out of those that measure rain') are exactly the sort of semantics that prevent misreading the output.

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?

Front-loaded with purpose and a usage cue before the mechanical Args/Returns/Examples blocks, and each block earns its place. The Args line restates the enum verbatim and the sunshine grouping sentence is dense, but neither is padding.

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?

There is no output schema, and the Returns section compensates thoroughly by describing the timestamp plus first-5-stations payload and the divergent shapes for 'sunniest' and 'wettest'. For a one-parameter tool with a single enum, nothing material is left unspecified.

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 0% and the Args block merely repeats the enum, but the body explains how each value changes the response shape — grouped sunshine counts for 'sunniest', rainy-station ratios for 'wettest', top-5 stations otherwise. That meaning is genuinely absent from the plain enum in 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?

Opens with a specific verb and resource plus a geographic and temporal scope: 'Get where in Switzerland it is warmest, coldest, windiest, wettest or sunniest now.' That is clearly distinguishable from sibling measurement/forecast tools, which are station- or forecast-oriented rather than ranking extremes across the country.

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 ('where is it warmest now', 'where is it sunny now') so an agent can pattern-match intent. It stops short of naming an alternative such as measurements_current for a single station's readings, so there is no explicit when-not guidance.

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