Moon Phase Software

Moonrise and moonset

get_moonrise_moonset

Read-onlyIdempotent

Returns moonrise, moonset and the Moon's highest point on a local date for a city from the website's list of world cities, or for any latitude and longitude, with compass directions and the Moon's phase that day. Also returns when the Moon is up after dark and, for today, where the Moon is right now. Times are in the place's own time zone.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_moonrise_moonset"
  }
}

Input Schema

Name	Required	Description
`date`	No	Local calendar date as YYYY-MM-DD, from 1900 to 2100; today at the place when omitted.
`place`	No	A city from the website's list of 136 world cities, such as London, Lima or Perth. Required unless latitude, longitude and timeZone are given.
`latitude`	No	Latitude in degrees, north positive. Given together with longitude and timeZone for a place outside the city list.
`timeZone`	No	IANA time zone name of the place, such as Atlantic/Reykjavik. Needed with latitude and longitude; a city uses its own zone.
`longitude`	No	Longitude in degrees, east positive. Given together with latitude and timeZone.

Output Schema

Name	Required	Description	Default
`item`	Yes
`view`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 11, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already declare read-only, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds meaningful behavior beyond that: compass directions, the Moon's up-after-dark window, the live position for today, and that all times use the place's own time zone. It does not cover failure behavior, such as an unlisted city name or an out-of-range date.

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 the returned values, then the optional extras, then the time-zone caveat. Three sentences with no filler, though the first sentence is dense enough that the two modes are packed together rather than separated.

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?

Covers both input modes, the date default, the time-zone semantics, and the extra outputs available for today; an output schema exists so return shapes need not be enumerated. The only gap is guidance on choosing this tool over the phase and calendar siblings.

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?

Schema coverage is 100%, so every parameter is already documented with format, bounds and the city-or-coordinates requirement. The description reinforces the city-versus-latitude/longitude choice and the local-date framing but adds no format or edge-case detail the schema lacks. Baseline 3 applies when the schema carries the detail.

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?

States a specific verb and resource ('Returns moonrise, moonset and the Moon's highest point') plus the scope: a named city or arbitrary latitude/longitude on a local date. The returned quantities (rise/set, highest point, compass directions, phase) make it distinguishable from phase-only or calendar siblings without opening the schema.

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 two input modes are explained (city from the site's list, or latitude/longitude plus time zone), and it notes that today's data additionally yields the Moon's current position. However, it never states when to prefer this over get_moon_phase or get_moon_calendar, leaving alternative selection to inference.

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

All Moon Phase Software tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.