Skip to main content
Glama
loosephoto

space-finder-mcp

by loosephoto
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

planetary_rover_location_map

Generate a map image showing a planetary rover's current location and traveled path on a selected celestial body for mission tracking.

Instructions

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

例:「パーサヴィアランスの現在地を火星地図で」「キュリオシティが今どこにいるか地図で」
ローバーの現在地データ（現状は NASA MMGIS / 火星）と走行経路を取得し、NASA Trek の
等角地図タイルに、走行経路(橙線)・現在地(赤●)・着陸地点(青●)を合成して描画。
planetary_map.BODIES の天体テーブルを利用するため、ベースマップは天体を指定して切り替え可能。

Args:
    body: 天体名（既定 "mars"。planetary_map の対応天体）。
    rover: ローバー名（"perseverance"=既定, "curiosity"）。
    zoom: 地図ズーム。省略時は天体の最大ズーム（火星7）。高倍率ほど詳細。
    span_deg: 表示する画角(経度幅・度)。大きいほど広範囲・解像度低下。既定0.5。
    out_px: 出力画像の長辺ピクセル(既定1000, 最大2000)。

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

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
bodyNomars
zoomNo
roverNoperseverance
out_pxNo
span_degNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.25.2

TDQS

A4.5/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 burden and does so well: it discloses that no auth is required, the underlying data source (NASA MMGIS / Mars), the rendering pipeline (NASA Trek equirectangular tiles with orange path line, red current-position dot, blue landing-site dot), the fact that a file is written to disk (a side effect), and the structuredContent.image_path return. It even explains the fallback behavior for harnesses that cannot render inline images.

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?

Purpose is front-loaded, followed by examples, then a behavior/render block and an Args block — a logical structure. The final paragraph about inline-image linking is somewhat verbose and repeated in intent, but it documents genuinely necessary fallback behavior rather than padding.

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 5-parameter tool with no output schema and no annotations, the description covers what the tool produces (an image plus structuredContent.image_path), how it renders, all parameter semantics, and environment constraints. There is no output schema, so the description rightly explains the return artifact itself.

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, and it fully documents all five parameters with defaults and semantics: body (default mars, bounded by planetary_map bodies), rover (perseverance default, curiosity), zoom (defaults to the body maximum, Mars=7, higher is more detailed), span_deg (longitude width in degrees, default 0.5, larger = wider but lower resolution), and out_px (default 1000, max 2000).

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 states a specific verb and resource: it returns a rendered map image showing a rover's current position on an arbitrary celestial body. The purpose is unambiguous, though it never explicitly distinguishes itself from the sibling 'mars_rover_status' (data vs. rendered map), leaving that disambiguation to inference.

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?

Two example queries ("Perseverance's current location on a Mars map", "where is Curiosity now") make the intended use case concrete. However, there is no explicit when-not guidance nor a direct comparison to the alternative 'mars_rover_status' tool, so the routing signal is contextual rather than explicit.

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

Deploy Server

Other Tools