Skip to main content
Glama
Sign In
loosephoto

space-finder-mcp

by loosephoto
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

impact_risk

Queries JPL Sentry for future asteroid collision risks, returning high-risk object lists or detailed cumulative probability and virtual impactor data for a specific designation.

Instructions

JPL Sentry による「将来の衝突リスク」を返す（認証不要・APIキー不要）。

例:「衝突確率の高い小惑星」「Sentry に載っている天体」「2024 YR4 の衝突リスク」

Args: designation: 小惑星の仮符号または番号（例 "2024 YR4"、"2000 SG344"、"99942"）。 指定すると、その天体の詳細（累積確率・想定時期・仮想衝突(VI)の一覧）を返します。 和名・愛称は JPL 側が受け付けません。推測せず仮符号で指定してください。 min_probability: 一覧の下限（累積衝突確率 ip。既定 1e-3 = 0.1%）。1e-10〜1。 limit: 一覧で表示する最大件数（1〜50、既定 10）。確率の高い順。

Input Schema

NameRequiredDescriptionDefault
limitNo
designationNo
min_probabilityNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 schema fields changedv0.41.4
    • removedInput schema / properties / designation / anyOf
      Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
    • removedInput schema / properties / designation / default
      Removed value: -null
    • removedInput schema / properties / designation / title
      Removed value: -"Designation"
    • addedInput schema / properties / designation / type
      Added value: +[
+  "string",
+  "null"
+]
    • removedInput schema / properties / limit / title
      Removed value: -"Limit"
    • removedInput schema / properties / min_probability / title
      Removed value: -"Min Probability"
    • removedInput schema / title
      Removed value: -"impact_riskArguments"
  2. Addedv0.39.0

TDQS

A4.5/5.0
Behavior4/5

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

With no annotations, the description carries the behavioral burden and discloses that no authentication or API key is required. It also describes parameter ranges, defaults, sorting order, and what the designation-specific response contains, though it does not discuss error behavior or rate limits.

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 tool's core purpose, followed by useful examples and a structured Args section. Every part adds actionable information without unnecessary repetition.

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 tool with no output schema and no annotations, the description is mostly complete: it covers purpose, authentication needs, and detailed parameter semantics. It describes the designation-specific return fields but is less explicit about the structure of the list response when no designation is supplied.

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%, but the description fully compensates by explaining all three parameters: designation format and caveats about Japanese names, min_probability range and default, and limit range plus probability-descending ordering.

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 states a specific verb and resource: it returns future collision risks from JPL Sentry. The examples ('high collision probability asteroids', 'objects listed on Sentry', '2024 YR4 collision risk') make its purpose distinct from siblings like neo_today or neo_close_approach.

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?

It gives clear usage contexts through example queries and explains that specifying a designation returns that object's detail while omitting it returns a probability-ranked list. However, it does not explicitly name when not to use it or point to a specific sibling alternative.

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