Skip to main content
Glama

planetary_orbiter_track

Plot spacecraft orbits and current positions on maps of the Moon, Mars, and more, or display historical landing sites like Apollo. Provides clear visual tracking for planetary exploration.

Instructions

任意の天体(月・火星・水星・タイタン等)を周回する探査機の現在位置と軌道を、その天体の地図にプロットした画像を返す。

例:「LROの現在位置を月面地図で」「MROの火星での現在地」「火星周回機の位置」
「かぐやの月面落下地点は?」(過去機は運用終了を案内し、落点が公表されていれば
その地点を月面図にマーカーで示した図を返す)
「アポロの着陸地点を月面図で」「アポロ11号の着陸地点は?」(sites 指定=地点マーカー図)
JPL Horizons が返す中心天体の状態ベクトルを IAU 自転モデルで天体固定座標
(緯度経度・高度) に変換し、NASA Trek の等角図法地図に重ねて描画。認証不要。

全面表示にするには span_deg=360(既定 120)。zoom 省略時は全面(1)に自動設定。

Args:
    body: 天体名(moon, mars, mercury, titan, vesta, ceres)。
    orbiter: 周回機名(月: lro, gateway/火星: mro, odyssey)または
        JPL Horizons の負の天体ID(例 "-74")。和名("かぐや"/"あかつき" 等)も可。
        過去機(kaguya 等)は運用終了のため現在位置は返さず、**落点が公表されている
        機体(かぐや)は落点の緯度経度・時刻・出典を structuredContent.impact_site に返す**。
    when: 観測時刻 ISO8601(例 "2026-09-10T00:00:00Z")。省略で現在。
    minutes: 現在位置の前後何分の軌道を表示するか(既定 90, 最大 1440)。
    step: トレイルの時間刻み(分。既定 5, 最小 1)。
    zoom: 地図ズーム 1〜最大(既定: span_deg>=360 なら1=全面, それ未満は3)。
    span_deg: 表示する経度幅(度。360=天体全面, 既定 120, 最大 360)。
    out_px: 出力画像の長辺ピクセル(既定 900, 最大 1600)。
    sites: **地点マーカー図**にする場合の地点指定(例 "apollo"=アポロ6地点すべて、
        "apollo11"="apollo17"=個別)。指定すると周回機の計算を行わず、NASA NSSDC が
        公表した着陸船(LM)座標にマーカーを置いた図を返す(1地点なら局所図、複数なら
        天体全面図+凡例)。旗の位置は公開表に無いため、注記でその旨を明示する。

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

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
bodyNomoon
stepNo
whenNo
zoomNo
sitesNo
out_pxNo
minutesNo
orbiterNolro
span_degNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.29.1
    • addedInput schema / properties / sites
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Sites"
      +}
  2. Addedv0.25.2

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations, the description carries the full transparency burden and does so thoroughly. It discloses the underlying computation (JPL Horizons state vectors, IAU rotation model, NASA Trek map), output storage path, structuredContent.image_path and impact_site fields, the always-prepended image link for non-rendering harnesses, authentication-free access, and the fact that flag positions are not available. This is unusually complete behavioral disclosure for a tool with no annotations.

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 appropriately so for a tool with nine parameters, zero schema descriptions, and no annotations. It is front-loaded with purpose and examples before diving into technical details, and the per-parameter explanations are scannable and information-dense. Every major sentence adds usable guidance 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 the tool's complexity, nine parameters, no output schema, and no annotations, the description is complete enough for correct selection and invocation. It covers what the tool returns, how to use each mode, examples of valid queries, defaults, constraints, authentication expectations, file output behavior, and structuredContent fields. An agent can invoke this tool correctly without additional context.

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%, so the description must fully compensate. It does: every parameter (body, orbiter, when, minutes, step, zoom, span_deg, out_px, sites) receives an explanation including defaults, ranges, accepted values, valid aliases, and conditional behavior. This goes far beyond what the bare input schema provides.

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 that it returns an image plotting the current position and trajectory of a spacecraft orbiting a celestial body on that body's map, using concrete verbs and resources. It includes multiple example queries (LRO, MRO, Kaguya, Apollo) that make the tool's scope and output unmistakable, and the "sites" mode and past-probe impact-point behavior further define its exact function.

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 strong usage context via examples and parameter modes: it explains when to use past-probe impact-point handling, when the "sites" marker mode applies, and how zoom/span_deg behavior changes. It does not explicitly compare this tool to siblings like sat_ground_track or planetary_rover_location_map, so exclusion guidance is implied rather than stated.

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