Skip to main content
Glama
Sign In
loosephoto

space-finder-mcp

by loosephoto
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

sat_tle

Retrieve TLE orbital elements for any satellite—ISS, Hubble, weather satellites, Tiangong—by name, NORAD ID, or CelesTrak group; Japanese names are resolved automatically to known satellites.

Instructions

任意の人工衛星（ISS・ハッブル・気象衛星・中国宇宙ステーション等）の軌道要素(TLE)を返す。

例:「ISSの軌道要素」「ハッブル宇宙望遠鏡のTLE」「気象衛星の軌道」

Args: name: 衛星名または省略名（例 "iss", "hubble", "tiangong", "goes-18"）。 和名は英語名/既知名へ自動解決する（"ひので"→29479, "ひまわり9号"→41836, "宇宙ステーション"→iss）。解決できない場合は既知の名前を提示して停止する。 norad_id: NORAD カタログ番号（例 25544=ISS）。name より優先。 group: CelesTrak の衛星グループ（例 "stations", "weather", "amateur", "science"）。 limit: 返す件数（既定 5、最大 20）。

Input Schema

NameRequiredDescriptionDefault
nameNo
groupNo
limitNo
norad_idNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed14 schema fields changedv0.41.4
    • removedInput schema / properties / group / anyOf
      Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
    • removedInput schema / properties / group / default
      Removed value: -null
    • removedInput schema / properties / group / title
      Removed value: -"Group"
    • addedInput schema / properties / group / type
      Added value: +[
+  "string",
+  "null"
+]
    • removedInput schema / properties / limit / title
      Removed value: -"Limit"
    • removedInput schema / properties / name / anyOf
      Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
    • removedInput schema / properties / name / default
      Removed value: -null
    • removedInput schema / properties / name / title
      Removed value: -"Name"
    • addedInput schema / properties / name / type
      Added value: +[
+  "string",
+  "null"
+]
    • removedInput schema / properties / norad_id / anyOf
      Removed value: -[
-  {
-    "type": "integer"
-  },
-  {
-    "type": "null"
-  }
-]
    • removedInput schema / properties / norad_id / default
      Removed value: -null
    • removedInput schema / properties / norad_id / title
      Removed value: -"Norad Id"
    • addedInput schema / properties / norad_id / type
      Added value: +[
+  "integer",
+  "null"
+]
    • removedInput schema / title
      Removed value: -"sat_tleArguments"
  2. Addedv0.25.2

TDQS

A3.8/5.0
Behavior3/5

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

With no annotations, the description carries the behavioral burden and usefully discloses automatic Japanese-name resolution, failure behavior ('既知の名前を提示して停止'), and the limit default/maximum. It still does not state whether the lookup is read-only, where data comes from beyond the CelesTrak group mention, data freshness, or the return structure.

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 front-loaded with the core purpose, followed by a compact examples section and a structured Args block. Every sentence adds useful information, and there is no redundant repetition of the tool name or schema types.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a four-parameter tool with no annotations and no output schema, the description covers purpose, parameters, name resolution, failure behavior, and limit bounds. It remains incomplete on return-value structure beyond 'TLE' and on how to choose this tool over nearby satellite-status/position tools.

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 does: name accepts satellite names or abbreviations with Japanese-to-English auto-resolution examples, norad_id is explicitly prioritized over name, group lists CelesTrak examples, and limit states default 5 and maximum 20.

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: return orbital elements (TLE) for an arbitrary satellite, with concrete examples including ISS, Hubble, weather satellites, and the Chinese space station. It is clearly not about current position or status, but it does not explicitly differentiate itself from siblings such as satellite_status or iss_now.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage context is implied through examples like 'ISSの軌道要素' and 'ハッブルのTLE', suggesting the tool is for retrieving TLE data rather than live position or status. However, it gives no explicit when-to-use/when-not-to-use guidance versus alternatives like satellite_status, iss_now, or sat_ground_track.

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