Skip to main content
Glama
cuolm

meteo-swiss-mcp

by cuolm
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

sunshine_hours

Retrieve total sunshine hours for a Swiss location or postal code over a specific period. Provide start and end times to receive summed sunshine in hours.

Instructions

        Get the sunshine hours for a location over a period.

        MeteoSwiss publishes sunshine as minutes per hour, which are added up over the period
        and reported as hours.

        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-23T06:00". Today or up to 8 days ahead.
            end (str): Swiss local time the period ends, ISO 8601 without offset, e.g. "2026-09-23T18:00".

        Returns:
            dict: Sunshine in hours, the resolved location with its altitude, the period, and
                the model run.

        Examples:
            sunshine_hours("Zurich", "2026-09-23T00:00", "2026-09-24T00:00")   # the whole day
            sunshine_hours("Zurich", "2026-09-23T12:00", "2026-09-23T18:00")   # the afternoon

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
endYes
startYes
locationYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv0.2.0
    • addedInput schema / properties / end
      Added value: +{
+  "title": "End",
+  "type": "string"
+}
    • removedInput schema / properties / lead_time_end_swiss
      Removed value: -{
-  "title": "Lead Time End Swiss",
-  "type": "integer"
-}
    • removedInput schema / properties / lead_time_start_swiss
      Removed value: -{
-  "title": "Lead Time Start Swiss",
-  "type": "integer"
-}
    • addedInput schema / properties / start
      Added value: +{
+  "title": "Start",
+  "type": "string"
+}
    • changedInput schema / required
      Previous value: -[
-  "location",
-  "lead_time_start_swiss",
-  "lead_time_end_swiss"
-]New value: +[
+  "location",
+  "start",
+  "end"
+]
    • changedOutput schema / (root)
      Previous value: -{
-  "properties": {
-    "result": {
-      "title": "Result",
-      "type": "number"
-    }
-  },
-  "required": [
-    "result"
-  ],
-  "title": "sunshine_hoursOutput",
-  "type": "object"
-}New value: +null
  2. First observedv0.1.0

TDQS

A4.2/5.0
Behavior4/5

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

With no annotations provided, the description carries the full burden. It discloses the data source (MeteoSwiss), the unit conversion (minutes summed to hours), time-zone and offset requirements, the valid time window (today to 8 days ahead), and the return structure (sunshine hours, resolved location with altitude, period, and model run). This is substantial behavioral context beyond a bare call signature, though it does not mention error behavior or rate limits.

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 description is well-structured with Args, Returns, and Examples sections. Every sentence contributes information: the purpose, the unit conversion, parameter constraints, return shape, and two use cases. It is slightly verbose but appropriately so for a tool with no schema documentation. The main purpose is front-loaded.

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?

Given there is no output schema, the description is adequately complete: it describes the return dict and its fields, explains the period constraints, and gives examples. It covers everything an agent needs to select and call the tool correctly for a typical read-only weather data request. Minor omissions like invalid-location handling are acceptable for this complexity level.

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?

The input schema has no descriptions (0% coverage), so the description must explain each parameter. It does so thoroughly: location accepts a name or Swiss postal code; start and end are Swiss local times in ISO 8601 without offset, with example values and the restriction that the period starts today or up to 8 days ahead. Examples illustrate valid calls, fully compensating for the schema gap.

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 clearly states the tool's purpose: 'Get the sunshine hours for a location over a period.' The verb 'get', the resource 'sunshine hours', and the scope (location + period) are specific and distinct from sibling tools like hourly_forecast or daily_forecast, which serve different weather metrics. No ambiguity about what it does.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides useful context, such as the MeteoSwiss data source and the minute-to-hour conversion, and constrains start/end times to Swiss local time and a forward-only range. However, it does not explicitly state when to prefer this tool over alternatives or mention any exclusions (e.g., 'use daily_forecast for temperature'). Usage guidance is implied by the specific metric but not made explicit.

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