Skip to main content
Glama

solar_system_now

Visualize the current positions of planets, asteroids, probes, and comets in one solar system chart. Specify a target object or date to see exactly where it is now.

Instructions

太陽を中心とした太陽系の惑星・小惑星・探査機・彗星の現在位置図を返す(認証不要)。

例:「太陽系を上から見た図」「今の惑星の位置」「イトカワの今の位置を図で」
「ボイジャー1号の現在位置を図で」「ハヤブサ2は今どこ?」「ハレー彗星は今どこ?」
「紫金山・アトラス彗星の位置」
惑星(8惑星+冥王星)は JPL DE421 暦表、小惑星は JPL SBDB 軌道要素のケプラー伝播、
遠方探査機(ボイジャー/パイオニア等)は JPL Horizons の状態ベクトル、
彗星は周期彗星(ハレー等)を SBDB 軌道要素、非周期C/彗星を Horizons 状態ベクトルで計算。

学生・観賞用途では視認性の高い Pillow 版(既定)を推奨。対数縮尺で内惑星から
百数十AUの遠方天体までを一枚に収める。探査機・遠方彗星を指定すると表示範囲を
自動拡張し、それぞれ色付き菱形マーカー・シアン色の尾を持つ彗星マーカーで強調する。
遠方天体は線形の matplotlib 版では枠外のため、指定時は対数縮尺の Pillow 版を自動選択。

engine で描画方法を選択:
  - "simple"(既定):   Pillow による視認性重視の合成。惑星を色アイコン、小惑星を緑十字、
    探査機を色付き菱形、彗星をシアンの核+尾で強調。距離は対数縮尺。
  - "accurate":       matplotlib による線形距離の正確な俯瞰図(近距離のみ)。
画像は content に base64 インライン表示、座標は structuredContent に JSON。
structuredContent.figure には「この図をどう描いたか」の注記(figure/1)が入る。
⚠️ figure.notes は図の誤読を防ぐための注記なので、要約・言い換えせずそのまま引用すること。

Args:
    when: 時刻 ISO8601(例 "2026-09-09T11:00:00Z")。省略時は現在時刻。
    asteroid: 小惑星(例 "イトカワ"/"itokawa"/"25143", "ベンヌ", "アポフィス")。
    asteroid2: 2つ目の小惑星。
    probe: 遠方探査機(例 "ボイジャー1号"/"voyager1"/"パイオニア10号"/"はやぶさ2"/
        "hayabusa2")。はやぶさ2 は JPL Horizons ID -37。
    probe2: 2つ目の探査機。
    comet: 彗星(例 "ハレー彗星"/"halley"/"1P", "エンケ彗星", "67P",
         "紫金山・アトラス"/"C/2023 A3", "ラブジョイ"/"C/2014 Q2")。
    comet2: 2つ目の彗星。
    engine: "simple"(既定/Pillow) / "accurate"(matplotlib)。
    view: "system"(既定)=太陽系俯瞰図 / "comet_orbit"=彗星の軌道面ビュー。
        comet_orbit は comet の指定が必須で、彗星自身の軌道面を真横から見た図
        (太陽=円錐曲線の焦点)を返す。e>=1 の C/彗星は閉じない双曲線の枝として描く。
        **comet にカンマ区切りで複数(または comet2 を併用、最大4天体)指定すると、
        1彗星=1パネルで並べた1枚の画像**を返す(パネルごとに軌道面と縮尺が異なる。
        その旨は figure.notes に数値から生成して入る)。

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

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
viewNosystem
whenNo
cometNo
probeNo
comet2No
engineNosimple
probe2No
asteroidNo
asteroid2No

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.27.0
    • addedInput schema / properties / view
      Added value: +{
      +  "default": "system",
      +  "title": "View",
      +  "type": "string"
      +}
  2. Addedv0.25.2

TDQS

A4.7/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 the full burden of behavioral disclosure. It fully covers what the tool does: returns an image in content (base64), coordinates in structuredContent, includes a figure.notes caution about quoting verbatim, auto-saves images to a temp path, and emits a clickable file link for CLI/Android harnesses. It also discloses the auto-selection of Pillow engine for distant objects. This is thorough and non-contradictory.

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 long but highly structured: a purpose paragraph with examples, an explanation of computation sources, engine details, output format, and a parameter list. Every sentence carries information and there is no filler. The length is justified by the tool's complexity (9 parameters, multiple engines, views, and output behaviors). It could be slightly tightened, but it is appropriately detailed.

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?

For a tool with 9 parameters, no schema descriptions, and no output schema, this description is exceptionally complete. It covers all parameters, engines, views, output format, image path handling, figure.notes instruction, and even warns about harness limitations. Nothing an agent needs to invoke it correctly is missing.

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 coverage is 0%, so the description must compensate. It does so excellently: every parameter (when, asteroid, probe, comet, engine, view, plus the 2 variants) is explained with format, examples, and aliases. It even explains the comet_orbit view's multi-comet behavior and the hyperbolic branch for e>=1 comets. This is far beyond typical parameter documentation.

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 opens with a clear statement: it returns a current-position map of solar system bodies centered on the Sun, no authentication required. It lists the specific body classes (planets, asteroids, probes, comets) and gives numerous concrete query examples, distinguishing it from sibling tools like sky_map_with_satellites or constellation_now.

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 provides many usage examples ('例:') that make it obvious when to call this tool, and it explains the two engine options and the two view modes, including when to choose which. It does not explicitly state when NOT to use it or name sibling alternatives, but the scope is clear enough that an agent can route correctly. Missing explicit exclusions against alternatives.

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