space-finder-mcp

Overview Schema Source Related Servers Discussions Admin

planetary_rover_location_map

Generates a map image showing a rover's current location on a planetary or lunar surface, so you can visually locate missions like Perseverance or Curiosity.

Instructions

任意の天体面を移動する探査ローバーの現在地を、その天体の地図上に示した画像を返す（認証不要）。

例:「パーサヴィアランスの現在地を火星地図で」「キュリオシティが今どこにいるか地図で」例: 火星ではマルス2/3号・バイキング・フェニックスなど、月では

Args: body: 天体名（既定 "mars"。"mars" / "phobos" / "moon"）。 rover: ローバー名（"perseverance"=既定, "curiosity", "idefix"、 "apollo11"〜"apollo17", "lunokhod1", "lunokhod2", "yutu", "yutu2"）。 zoom: 地図ズーム（タイル系のみ）。省略時は天体の最大ズーム。 span_deg: 表示する画角(経度幅・度)。大きいほど広範囲・解像度低下。既定0.5。 out_px: 出力画像の長辺ピクセル(既定1000, 最大2000)。 site_lat: 着陸地点の纬度(度・北が正)。指定するとその地点を「着陸予定点」として描く。 site_lon: 着陸地点の経度(度・東向き正)。site_lon_w とは排他。 site_lon_w: 着陸地点の経度(度・西向き正。IAU/フォボスの慣用表記)。 show_lat_band: 着陸地点の緯度制約帯（フォボスでは ±30°）を描くか。既定 True。 show_sites: 同じ天体にあるほかの人工物の着陸地点を地図に重ねて描くか。既定 True。例: 火星ではマルス2/3号・バイキング・フェニックスなど、月ではサーベイヤー3号（Apollo 12 号の LM のすぐ隣）など。

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

Input Schema

Name	Required	Default
`body`	No	mars
`zoom`	No
`rover`	No	perseverance
`out_px`	No
`site_lat`	No
`site_lon`	No
`span_deg`	No
`show_sites`	No
`site_lon_w`	No
`show_lat_band`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed14 schema fields changedv0.41.4Oct 23, 2026
- removedInput schema / properties / body / title
```
Removed value: -"Body"
```
- removedInput schema / properties / out_px / title
```
Removed value: -"Out Px"
```
- removedInput schema / properties / rover / title
```
Removed value: -"Rover"
```
- addedInput schema / properties / show_lat_band
```
Added value: +{
+  "default": true,
+  "type": "boolean"
+}
```
- addedInput schema / properties / show_sites
```
Added value: +{
+  "default": true,
+  "type": "boolean"
+}
```
- addedInput schema / properties / site_lat
```
Added value: +{
+  "type": [
+    "number",
+    "null"
+  ]
+}
```
- addedInput schema / properties / site_lon
```
Added value: +{
+  "type": [
+    "number",
+    "null"
+  ]
+}
```
- addedInput schema / properties / site_lon_w
```
Added value: +{
+  "type": [
+    "number",
+    "null"
+  ]
+}
```
- removedInput schema / properties / span_deg / title
```
Removed value: -"Span Deg"
```
- removedInput schema / properties / zoom / anyOf
```
Removed value: -[
-  {
-    "type": "integer"
-  },
-  {
-    "type": "null"
-  }
-]
```
- removedInput schema / properties / zoom / default
```
Removed value: -null
```
- removedInput schema / properties / zoom / title
```
Removed value: -"Zoom"
```
- addedInput schema / properties / zoom / type
```
Added value: +[
+  "integer",
+  "null"
+]
```
- removedInput schema / title
```
Removed value: -"planetary_rover_location_mapArguments"
```
Addedv0.25.2Sep 12, 2026

TDQS

A4.2/5.0

Behavior4/5

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

With no annotations, the description carries full burden. It discloses authentication-free access, image-return behavior, the need to present the link as the sole fallback, and detailed parameter side effects (e.g., zoom only for tile systems, span_deg affects resolution, site_lat/lon draws a landing site marker). Missing rate limits or error behavior, but strong overall.

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 front-loaded with purpose, then examples, then structured Args. However, there is redundancy: a truncated example line ('例: 火星ではマルス2/3号・バイキング・フェニックスなど、月では') is repeated under show_sites. Otherwise efficient.

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?

Given 10 parameters, no annotations, and no output schema, the description covers all parameters and key behaviors. It adequately explains the image return and link presentation. Minor gaps remain around exact return format (e.g., marker details) but overall complete.

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 compensate. It fully documents all 10 parameters: body with enum values, rover names and defaults, zoom semantics, span_deg effect, out_px limits, site_lat/lon with coordinate convention (east positive vs site_lon_w west positive), exclusivity, and show_lat_band/show_sites defaults with examples.

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 first sentence states a specific verb + resource: returns an image showing a rover's current location on a celestial body's map, and notes '認証不要'. This clearly distinguishes it from siblings like mars_rover_status, but no explicit sibling comparison is made.

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?

Provides concrete example queries ('パーサヴィアランスの現在地を火星地図で') that show when to use the tool. Also includes a directive to present the returned link. However, it does not name alternatives or exclusion conditions.

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

Deploy Server

planetary_rover_location_map

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools