Skip to main content
Glama
Sign In
cuolm

meteo-swiss-mcp

by cuolm
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

forecast_freezing_level

Get the height of the 0 degree line at a place at a specific time.

Instructions

        Get the height of the 0 degree line at a place at a specific time.

        This is the height where the air is at 0 degrees. Snow usually reaches somewhat below it,
        so it answers questions about snow in the mountains, such as how high a ski area has to be.

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

        Returns:
            dict: The freezing level in metres above sea level, the place, the forecast point
                used, the time it is valid for and the model run.

        Examples:
            forecast_freezing_level("Zermatt", "2026-09-23T14:00")
            forecast_freezing_level("Arosa", "2026-09-25T06:00")

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

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.3.0

TDQS

A4/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 input time semantics (Swiss local time, full hour, ISO 8601 without offset, today to 8 days ahead) and enumerates what the return dict contains (freezing level in metres AMSL, place, forecast point, valid time, model run). It does not state behavior for out-of-range times, ambiguous place names, or errors.

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?

The core meaning and scope come first, followed by a helpful interpretation sentence, then Args/Returns/Examples. The Args section partially duplicates the schema, but the structure is scannable and no sentence is pure filler.

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?

For a 3-parameter, no-annotation, no-output-schema tool, the description covers purpose, both required inputs' formats and ranges, the return payload contents, and worked examples. Minor gaps: no guidance on error cases or on when the 'near' disambiguation is needed (deferred to the schema).

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 33% (only 'near' is documented in the schema), but the description fully compensates for both required parameters: it defines 'location' as a town/village/city district/lake/peak with an example, and 'when' with format, timezone, hour granularity and a valid range. The 'near' parameter is left to the schema, which handles it adequately.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: 'Get the height of the 0 degree line at a place at a specific time', reinforced by a plain-language gloss ('the height where the air is at 0 degrees'). The resource is clearly distinct from the sibling forecast_* tools, though it never names or contrasts them explicitly.

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 usage context ('answers questions about snow in the mountains, such as how high a ski area has to be') and an operational constraint (today or up to 8 days ahead), which tells the agent when the tool is applicable. No explicit when-not-to-use or pointer to a sibling alternative.

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