space-finder-mcp

Overview Schema Source Related Servers Discussions Admin

solar_system_now

Generate a diagram of current planet, asteroid, probe, and comet positions around the Sun, or plot selected orbits and apparitions for a chosen time.

Instructions

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

例:「太陽系を上から見た図」「今の惑星の位置」「イトカワの今の位置を図で」

Args: when: 時刻 ISO8601（例 "2026-09-09T11:00:00Z"）。省略時は現在時刻。 asteroid: 小惑星（例 "イトカワ"/"itokawa"/"25143", "ベンヌ", "アポフィス"）。view="asteroid_orbit" では楕円軌道全体を描く。 asteroid2: 2つ目の小惑星。 probe: 遠方探査機（例 "ボイジャー1号"/"voyager1"/"パイオニア10号"/"はやぶさ2"/ "hayabusa2"）。1光日に達していない探査機では、到達時の方向（◇）・到達予測日も図と structuredContent に出る。はやぶさ2 は JPL Horizons ID -37。 probe2: 2つ目の探査機。 comet: 彗星（例 "ハレー彗星"/"halley"/"1P", "エンケ彗星", "67P", "紫金山・アトラス"/"C/2023 A3", "ラブジョイ"/"C/2014 Q2"）。 comet2: 2つ目の彗星。 engine: 互換引数（描画は 1 本）。"accurate" を指定すると線形縮尺 （相対距離が正確・枠 ±45 AU）で描く。それ以外は対数縮尺（既定）。旧 "simple" / "accurate"(matplotlib) は廃止済みで、指定しても同じ描画になる。 projection: 互換引数。描画は常に斜め俯瞰（仰角34°・方位28°・弱い透視。奥ほど暗く細い線で描く。画面上の距離はAUに比例しない）。旧 "top" を指定しても斜め俯瞰で描き、その旨を figure.notes に出す。 elevation: カメラの仰角（度, 0〜90。既定 34）。0 で真横（軌道が線に潰れる）、 90 で真上（＝旧「真上図」と同じ構図）。注記・題名にも実値を出す。 azimuth: カメラの方位（度, -360〜360。既定 28）。黄道面内の回転。 dolly: 透視の強さ＝カメラ距離（画面半径の倍数, 0〜20。既定 4.2）。 0 で完全な正射影（遠近が消える）。 view: "system"(既定)=太陽系俯瞰図 / "comet_orbit"=彗星の軌道面ビュー / "asteroid_orbit"=小惑星の閉じた楕円軌道面ビュー / "apparition"=彗星の見え方チャート（地心距離・日心距離・予想光度・太陽離角の推移。comet の指定が必須で、1天体ずつ）。 comet_orbit は comet の指定が必須で、彗星自身の軌道面を真横から見た図（太陽＝円錐曲線の焦点）を返す。e>=1 の C/彗星は閉じない双曲線の枝として描く。 asteroid_orbit は asteroid の指定が必須で、JPL SBDB の osculating elements に基づく小惑星の楕円全体と指定時刻の現在位置を軌道面から描く（1天体ずつ）。 comet にカンマ区切りで複数（または comet2 を併用、最大4天体）指定すると、 1彗星=1パネルで並べた1枚の画像を返す（パネルごとに軌道面と縮尺が異なる。その旨は figure.notes に数値から生成して入る）。 days: view="apparition" の表示日数（1〜3650、既定 180）。今日の 30 日前から days 日後までを描く（直前に過ぎた近日点・最接近も見えるようにするため）。 route: view="system" で、通過経路を俯瞰図に重ねる（破線）。彗星は軌道全体を描き、近日点・遠日点には◇と日付を添える（近日点の日付は SBDB の2体近似に加えて JPL Horizons の n 体解も併記。2体近似はずれることがある。ハレー彗星では約164日）。探査機（probe=）では Horizons の実状態ベクトル点列を描き、惑星との最接近（スイングバイ）を距離の局所極小として実測して◇＋日付＋距離を添える（アポロ計画・ボイジャー計画などの重力アシスト航路。例: solar_system_now(probe="ボイジャー1号", route=True)）。探査機の航路はミッション期間（打ち上げ〜到着）を自動で引き、表に無い機体は指定時刻までの過去1年を描く。 アポロの月スイングバイのように地球−月系の内側だけで完結する航路は、太陽系図では太陽の描画円盤に隠れて読めないため描かず、その旨と代替（月面地図の planetary_orbiter_track(flyby=True)）を figure.notes に出す。既定 False。線形の "accurate" では形は本当の軌道と一致するが、対数縮尺の "simple" では線の長さと曲率が実際の軌道と一致しない（その旨は figure.notes に入る）。彗星の形そのものを見たいときは view="comet_orbit"。 range_au: view="system" の表示範囲（太陽からの距離の上限）。既定 0＝自動（対数版は 60 AU 起点、線形版は ±45 AU 起点で、遠方の天体・経路に合わせて拡張）。 数値（AU）でも天体名でも指定できる（「火星まで」「木星まで」のように LLM が判断して縮尺を選ぶ用途を想定）。数値: 10=土星(9.58 AU)より内側／2=火星まで／5.62=木星まで／30=海王星まで。0.5 未満はエラー。天体名: "火星"（→1.65 AU）／"木星"（→5.62）／"土星"（→10.35）／"海王星"（→32.5）／ "冥王星"／英語名（mars, jupiter…）／"小惑星帯"／"内惑星"／"外惑星"。その呼び出しで指定した小惑星・彗星・探査機の名前も使える（例: asteroid="イトカワ" に対して range_au="イトカワ"）。天体名は「その天体の軌道の円が入る」ように長半径×1.08 で決める（決め方は figure.notes と structuredContent.range_resolved に数値付きで出る）。 "fit"（＝指定天体に合わせる）: その呼び出しで指定した天体・経路がすべて入る範囲（最大値×1.10、下限 1.2 AU）。天体を指定せず "fit" にすると自動（45 AU 起点）。解決できない名前は推測せずエラーで候補一覧を返す。 範囲外の天体・目印・軌道の円は描かず、figure.notes と structuredContent に出典付きで列挙する（黙って消さない）。対数版は下限も範囲に合わせて下がる。

⚠️ figure.notes は図の誤読を防ぐための注記なので、要約・言い換えせずそのまま引用すること。

回答時はこのリンクをそのまま提示してください（画像が描画されない環境では唯一の導線）。

Input Schema

Name	Required	Default
`days`	No
`view`	No	system
`when`	No
`comet`	No
`dolly`	No
`probe`	No
`route`	No
`comet2`	No
`engine`	No	oblique
`probe2`	No
`azimuth`	No
`asteroid`	No
`range_au`	No
`asteroid2`	No
`elevation`	No
`projection`	No	oblique

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedv0.48.0Oct 31, 2026
- addedInput schema / properties / azimuth
```
Added value: +{
+  "type": "string"
+}
```
- addedInput schema / properties / dolly
```
Added value: +{
+  "type": "string"
+}
```
- addedInput schema / properties / elevation
```
Added value: +{
+  "type": "string"
+}
```
- changedInput schema / properties / engine / default
```
Previous value: -"simple"New value: +"oblique"
```
- addedInput schema / properties / projection
```
Added value: +{
+  "default": "oblique",
+  "type": "string"
+}
```
Changed32 schema fields changedv0.41.4Oct 23, 2026
- removedInput schema / properties / asteroid / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- removedInput schema / properties / asteroid / default
```
Removed value: -null
```
- removedInput schema / properties / asteroid / title
```
Removed value: -"Asteroid"
```
- addedInput schema / properties / asteroid / type
```
Added value: +[
+  "string",
+  "null"
+]
```
- removedInput schema / properties / asteroid2 / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- removedInput schema / properties / asteroid2 / default
```
Removed value: -null
```
- removedInput schema / properties / asteroid2 / title
```
Removed value: -"Asteroid2"
```
- addedInput schema / properties / asteroid2 / type
```
Added value: +[
+  "string",
+  "null"
+]
```
- removedInput schema / properties / comet / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- removedInput schema / properties / comet / default
```
Removed value: -null
```
- removedInput schema / properties / comet / title
```
Removed value: -"Comet"
```
- addedInput schema / properties / comet / type
```
Added value: +[
+  "string",
+  "null"
+]
```
- removedInput schema / properties / comet2 / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- removedInput schema / properties / comet2 / default
```
Removed value: -null
```
- removedInput schema / properties / comet2 / title
```
Removed value: -"Comet2"
```
- addedInput schema / properties / comet2 / type
```
Added value: +[
+  "string",
+  "null"
+]
```
- removedInput schema / properties / days / title
```
Removed value: -"Days"
```
- removedInput schema / properties / engine / title
```
Removed value: -"Engine"
```
- removedInput schema / properties / probe / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- removedInput schema / properties / probe / default
```
Removed value: -null
```
- removedInput schema / properties / probe / title
```
Removed value: -"Probe"
```
- addedInput schema / properties / probe / type
```
Added value: +[
+  "string",
+  "null"
+]
```
- removedInput schema / properties / probe2 / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- removedInput schema / properties / probe2 / default
```
Removed value: -null
```
- removedInput schema / properties / probe2 / title
```
Removed value: -"Probe2"
```
- addedInput schema / properties / probe2 / type
```
Added value: +[
+  "string",
+  "null"
+]
```
- removedInput schema / properties / range_au / title
```
Removed value: -"Range Au"
```
- removedInput schema / properties / route / title
```
Removed value: -"Route"
```
- removedInput schema / properties / view / title
```
Removed value: -"View"
```
- removedInput schema / properties / when / default
```
Removed value: -null
```
- removedInput schema / properties / when / title
```
Removed value: -"when"
```
- removedInput schema / title
```
Removed value: -"solar_system_nowArguments"
```

Changed3 schema fields changedv0.39.0Oct 12, 2026

addedInput schema / properties / days

Added value: +{
+  "default": 180,
+  "title": "Days",
+  "type": "integer"
+}

addedInput schema / properties / range_au

Added value: +{
+  "anyOf": [
+    {
+      "type": "number"
+    },
+    {
+      "type": "string"
+    }
+  ],
+  "default": 0,
+  "title": "Range Au"
+}

addedInput schema / properties / route

Added value: +{
+  "default": false,
+  "title": "Route",
+  "type": "boolean"
+}

Changed1 schema field changedv0.27.0Sep 13, 2026

addedInput schema / properties / view

Added value: +{
+  "default": "system",
+  "title": "View",
+  "type": "string"
+}

Addedv0.25.2Sep 12, 2026

TDQS

A4.3/5.0

Behavior5/5

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

With zero annotations the description carries the full burden and does so: it discloses the fixed oblique camera, that deprecated engine/projection values are silently normalized, that out-of-range bodies are omitted but enumerated with sources in figure.notes, that unresolvable names error out with a candidate list rather than guessing, that range_au below 0.5 is an error, and that figure.notes must be quoted verbatim. These are exactly the failure modes an agent needs to plan around.

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

Conciseness3/5

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

The purpose sentence is properly front-loaded and the Args block is one-entry-per-parameter, but the whole thing runs well past a thousand words, with long parenthetical digressions on deprecated matplotlib engines, Halley's 164-day two-body error, and Apollo swingby rendering that are not needed to select or invoke the tool. Trimming the historical and compatibility prose would lose nothing.

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?

For a 16-parameter tool with no annotations and no output schema, the description covers behavior, side channels (structuredContent.range_resolved, figure.notes) and error semantics thoroughly. What is left slightly implicit is the exact return shape — whether an image, a link, or both are returned — though the closing instruction to present the link implies it.

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 has to compensate and it does for all 16 parameters: aliases for asteroids/probes/comets, range_au accepting numbers, body names or "fit" with the 1.08/1.10 multiplier rules, view-mode-specific constraints on days, and elevation/azimuth/dolly ranges with their visual effect. The only friction is that elevation, azimuth and dolly are typed as strings in the schema while the description describes them as bounded numbers, which the description does not reconcile.

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 opening sentence names a specific verb and resource: returns a current-position diagram of the Sun-centered planets, asteroids, probes and comets, and notes that no auth is required. That is unambiguous, but it does not position itself against the nearest siblings (sky_map_with_satellites, constellation_now, moon_phase_map) beyond a single aside pointing to planetary_orbiter_track for lunar flybys.

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?

Each view mode is spelled out with its prerequisites (comet_orbit and apparition require comet, asteroid_orbit requires asteroid, one body at a time), and natural-language trigger examples are given. It also names an alternative (planetary_orbiter_track with flyby=True) for Earth-Moon-only routes, but there is no broader when-not-to-use guidance versus the other sky/position tools.

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

Deploy Server

solar_system_now

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools