Skip to main content
Glama

moon_phase_map

Generate a moon phase calendar for any month and location, showing daily lunar illumination and crescent orientation. Use it to find full moons, new moons, or view a lunation sequence.

Instructions

月齢マップ(月の満ち欠けを1か月ぶん並べた図)を返す(認証不要・ローカル計算)。

例:「今月の月齢マップを見せて」「2026年9月の月相カレンダー」「9月の満月はいつ?」

日食の時系列パネル(solar_eclipse_series)と同じ幾何計算を使い、観測地から見た
太陽と月の実位置から「輝面の向き(位置角 PA)」と照度を求め、月円盤を正しい向きに
欠けさせて描きます(月齢から向きを決め打ちしない)。月齢は直前の朔(新月)からの
経過日数、照度は円盤の輝面の割合です。描いた画素から輝面の面積比を測り直し、
申告した照度と突き合わせて自己検証します(figure.verify)。

layout="calendar"(既定)は指定した月の日別セル(日月火水木金土の格子)、
layout="lunation" は1朔望月(朔→朔)を等間隔の時系列パネルで返します。

月齢・照度は地球規模の見え方なので観測地には依存しませんが、日付・時刻・曜日は
現地時間(緯度経度から取得した UTC オフセット)で表示します。

Args:
    date: 年月("2026-09" / "2026年9月")または年月日("2026-09-16")。省略時は現在の月。
    place: 観測地(例 "東京","大阪","new york")。lat/lon 指定時は無視。省略時は東京。
    lat: 観測地の緯度。lon と併用時は place より優先。
    lon: 観測地の経度。
    layout: "calendar"(既定・1か月の格子)または "lunation"(朔望月の時系列パネル)。
    days: layout="lunation" のパネル枚数(3〜12・既定8)。calendar では無視。

インライン画像を表示できないハーネス(CLI系・Android系の codex / opencode など)向けに、
content の先頭へ「🖼️ [生成した画像を開く(…)](file:///…) | 保存先: `…`」という
アイコン付きリンクを必ず出します(画像は出力ディレクトリに保存し、同じパスを
structuredContent.image_path にも入れます)。
回答時はこのリンクをそのまま提示してください(画像が描画されない環境では唯一の導線)。

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
latNo
lonNo
dateNo
daysNo
placeNo
layoutNocalendar

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.30.1

TDQS

A4.6/5.0
Behavior5/5

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

No annotations are provided, so the description carries full responsibility. It thoroughly discloses no-auth local calculation, self-verification via figure.verify, local-time handling based on UTC offset, output image saving, the always-present file link, and structuredContent.image_path. This is rich behavioral disclosure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but well-structured: purpose and examples first, then behavioral notes, then an Args list. Every sentence carries operational value; the clear organization makes the length manageable for an agent.

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?

Given no annotations and no output schema, the description covers outputs, side effects, defaults, parameter precedence, and harness-specific fallback behavior. An agent has everything necessary to invoke the tool correctly.

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?

Schema description coverage is 0%, yet the description documents every parameter: date formats and default, place with examples and precedence rules, lat/lon behavior, layout values, and days constraints (3–12, default 8, ignored in calendar). It fully compensates for the empty schema.

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 clearly states that the tool returns a moon age map (月齢マップ) with one month of lunar phases arranged in a figure, and provides concrete example queries. It identifies the resource and action well, but does not explicitly contrast itself with sibling map tools beyond referencing shared geometry with solar_eclipse_series.

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?

The description gives concrete example prompts and clearly explains when to use layout='calendar' versus layout='lunation', including that 'days' is ignored in calendar mode. It provides clear usage context but does not explicitly state when to choose this tool over alternatives or list exclusions.

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