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

meteo-swiss-mcp

by cuolm
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

astronomy_moon

Read-only

Get moonrise and moonset times, phase, and illuminated percentage for a Swiss location and date to answer questions like when the Moon rises or how full it is.

Instructions

        Get when the Moon rises and sets at a place on a day, its phase and how much of it is lit.

        Use this for "when does the moon rise tonight" or "how full is the moon tonight". The
        times are for a level horizon, so in a valley the Moon appears later behind the
        mountains. The day has a moon_phase_time when New Moon, First Quarter, Full Moon or Last
        Quarter happens on it. The lit percent is the one at 12:00.

        Args:
            location (str): Name of a place in Switzerland, e.g. "Zürich".
            date (str): The day, e.g. "2026-09-23".

        Returns:
            dict: The place, the date, the moonrise and moonset, None when the Moon does not rise
                or set that day, the phase with its emoji and time, and the lit percent.

        Examples:
            astronomy_moon("Zürich", "2026-09-23")

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>",
      "date": "<date>"
    },
    "name": "astronomy_moon"
  }
}

Input Schema

NameRequiredDescriptionDefault
dateYes
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?

Annotations already cover the read-only and open-world nature, but the description adds valuable semantics: level-horizon assumption, the fact that a phase event time is only present on days with a quarter/full/new moon, the lit-percent snapshot at 12:00, and null rise/set when the Moon does not rise or set. That is real context beyond the annotations, though it omits error handling (e.g. unknown place name).

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 front-loaded with the one-line purpose, then usage examples, caveats and args/returns. Every section adds value, though the docstring-style Args/Returns blocks make it slightly longer than strictly necessary given the input schema already exists.

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?

With no output schema, the Returns section fully describes the payload (place, date, moonrise/moonset with nulls, phase with emoji and time, lit percent). Combined with the caveats and examples, an agent has everything needed to invoke and interpret the result.

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%, and the description compensates by specifying that `location` must be a place name in Switzerland and that `date` follows a concrete ISO-style format with an example. It omits `near`, but the schema already documents that one thoroughly, so the gap is minor.

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?

The description uses a concrete verb+resource: 'Get when the Moon rises and sets at a place on a day, its phase and how much of it is lit', and the mapped use cases ('when does the moon rise tonight', 'how full is the moon tonight') make the scope unambiguous. It doesn't explicitly contrast with the sibling astronomy_sun, but the resource is distinct enough that the agent can tell them apart.

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?

Provides explicit trigger phrasings for when to use the tool and a clear behavioral caveat (times assume a level horizon, so valley terrain shifts rise/set). No explicit 'when not to use' or sibling routing (e.g. use astronomy_sun for sun events), so it falls just short of 5.

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