Moon Phase Software

Moon phase

get_moon_phase

Read-onlyIdempotent

Returns the Moon's phase, percent lit, lunar age and waxing or waning direction right now, at 12:00 on a date, or at a clock time on a date, in a time zone or city. Also returns the next new Moon, first quarter, full Moon and last quarter, the previous full Moon and the moment the phase name changes. Dates run from 1900 to 2100.

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_moon_phase"
  }
}

Input Schema

Name	Required	Description
`date`	No	Local calendar date as YYYY-MM-DD, from 1900 to 2100. Without a date and a time the result describes the Moon right now; a date alone gives the Moon at 12:00 local time.
`time`	No	Local clock time as HH:MM on a 24-hour clock. Without a date it refers to today in the chosen time zone.
`place`	No	A city from the website's list of 136 world cities, such as Tokyo, Chicago or Cairo; its time zone is used unless timeZone is given.
`timeZone`	No	IANA time zone name such as America/New_York or Asia/Tokyo; UTC when omitted.

Output Schema

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

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 11, 2026

TDQS

A3.6/5.0

Behavior3/5

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

Annotations already establish read-only, idempotent, non-destructive, closed-world behavior, so the safety profile is fully covered. The description adds the supported date range and enumerates return contents, but since a rich output schema exists those clauses largely restate structured data rather than adding new behavioral context such as precision, caching, or data source.

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 primary return values, then the secondary phase events, then the date range guard. Two sentences with little waste, though the long enumeration of each returned field is partly redundant given the output schema.

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?

Annotations, a complete parameter schema, and an output schema mean the description only needed to supply purpose and mode behavior, both of which are present. The remaining gap is that it does not position this tool against get_moon_calendar or find_full_moons for agents deciding where to send a phase-related query.

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% and each parameter already documents its pattern, defaults, and interaction (date alone yields noon; time alone yields today). The description's "in a time zone or city" hints at the place/timeZone relationship, but the schema already spells out that the city's zone is used unless timeZone is given, so added meaning is marginal. Baseline 3 applies.

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 specific verb and resource ("Returns the Moon's phase") and enumerates the exact outputs: percent lit, lunar age, waxing/waning direction, and upcoming quarter phases. This clearly separates it from get_moon_distance, get_moon_sign, and get_moonrise_moonset, but it never names or distinguishes itself from get_moon_calendar, whose phase-listing overlap is the one genuinely ambiguous boundary.

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?

It gives clear invocation contexts: "right now", "at 12:00 on a date", or "at a clock time on a date, in a time zone or city", plus the 1900–2100 date envelope. It offers no exclusions or explicit pointer to a sibling when a different moon query is wanted, so it stops short of full when/when-not guidance.

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.