Skip to main content
Glama
Sign In
meteo-swiss-mcp

meteo-swiss-mcp

by cuolm
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

measurements_current

Read-only

Check how warm it is or whether it is raining now by retrieving current MeteoSwiss station measurements for a place in Switzerland.

Instructions

        Get the latest measurements of a MeteoSwiss station near a place.

        Use this for "how warm is it now" or "is it raining now". The values are those of the
        station named in data_from. MeteoSwiss publishes new values about every 10 minutes.

        Args:
            location (str): Name of a place in Switzerland, e.g. "Zürich".

        Returns:
            dict: data_from, the place, the time of the measurements and the measured values. A
                value is None when the station has not published it.

        Examples:
            measurements_current("Zürich")

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": {
      "location": "<location>"
    },
    "name": "measurements_current"
  }
}

Input Schema

NameRequiredDescriptionDefault
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.
locationYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.4.0

TDQS

A4.1/5.0
Behavior4/5

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

Beyond readOnlyHint/openWorldHint, the description discloses three useful behaviors: values belong to the station named in data_from (not the requested place itself), MeteoSwiss updates roughly every 10 minutes, and individual values may be None when unpublished. That null-handling and freshness contract is real value the annotations do not carry. It does not say what quantity set is returned (units, which measurements), which keeps it from a 5.

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?

Content is front-loaded: purpose, then when-to-use, then freshness caveat, before the boilerplate Args/Returns/Examples block. The docstring scaffolding ("Args:", "Returns:", "Examples:") is somewhat ceremonial, but each section carries non-redundant information.

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?

With no output schema, the description takes on the burden of describing the return shape (data_from, place, measurement time, values) and does so, plus the None case. For a two-parameter read tool with readOnly annotations this is nearly sufficient; the main omission is what quantities/units come back.

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

Parameters3/5

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

At 50% schema coverage, the description compensates for the undocumented `location` parameter by explaining it is a place name in Switzerland with a concrete example. However, the `near` disambiguation parameter is never mentioned in the description at all, so that half of the semantics rests entirely on the schema's own text.

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?

"Get the latest measurements of a MeteoSwiss station near a place" states a specific verb (get) and resource (latest measurements) with scope (station near a place). The word "latest" and the "now" framing cleanly separate it from the forecast_* siblings without needing to name them.

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?

Explicit trigger conditions are given: "how warm is it now" or "is it raining now", which is exactly the decision rule an agent needs to distinguish this from forecast_daily/forecast_temperature. It stops short of naming a sibling as the alternative for future-oriented questions, so it is clear but not fully routing.

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