space-finder-mcp

Overview Schema Source Related Servers Discussions Admin

astronomy_weather

Forecasts suitable stargazing and astronomical observation windows by location using cloud cover, sky darkness, and weather data for up to seven days worldwide.

Instructions

天体観測に最適な時間帯を予報する（Open-Meteo, 認証不要・全世界対応）。

例:「東京で今夜天体観測できる?」「シドニーの晴れ予報」「富士山頂の雲量」

Args: latitude: 緯度（例東京 35.68）。place 指定時は省略可。 longitude: 経度（例東京 139.69）。 place: 地名（緯度経度より優先）。Open-Meteo のジオコーディングで解決。 days: 予報日数（1〜7、既定 3）。 max_cloud: 「観測可」とみなす雲量の上限%（既定 40）。 sun_alt_max: 観測時間帯とみなす太陽高度（度）の上限。既定 -15（薄明の明るい時間帯を除外）。-18 で天文薄明＝完全な暗夜のみ、-6 なら市民薄明が終わった後から。Open-Meteo は hourly に太陽高度を返さないため、日付・経度・UTCオフセットから解析的に推定する（極昼・極夜などで推定できない地点は is_day のみで判定）。 include_rain: 日本国内の地点に限り、気象庁の雨雲・降水画像（解析雨量・降水短時間予報のパネル＋ナウキャスト＝雨雲の動き）を添付する（既定 True。取得失敗時は添付なしで続行）。 ⚠️ structuredContent.figure.notes は要約せずそのまま引用すること。（添付した雨雲・降水画像は content に「🖼️ ◯◯を開く」のリンク付きで出します。インライン画像を描画しないハーネスでは、回答にこのリンクをそのまま提示してください。）

Input Schema

Name	Required	Description	Default
`days`	No
`place`	No
`latitude`	No
`longitude`	No
`max_cloud`	No
`sun_alt_max`	No
`include_rain`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed17 schema fields changedv0.41.4Oct 23, 2026
- removedInput schema / properties / days / title
```
Removed value: -"Days"
```
- removedInput schema / properties / include_rain / title
```
Removed value: -"Include Rain"
```
- removedInput schema / properties / latitude / anyOf
```
Removed value: -[
-  {
-    "type": "number"
-  },
-  {
-    "type": "null"
-  }
-]
```
- removedInput schema / properties / latitude / default
```
Removed value: -null
```
- removedInput schema / properties / latitude / title
```
Removed value: -"Latitude"
```
- addedInput schema / properties / latitude / type
```
Added value: +[
+  "number",
+  "null"
+]
```
- removedInput schema / properties / longitude / anyOf
```
Removed value: -[
-  {
-    "type": "number"
-  },
-  {
-    "type": "null"
-  }
-]
```
- removedInput schema / properties / longitude / default
```
Removed value: -null
```
- removedInput schema / properties / longitude / title
```
Removed value: -"Longitude"
```
- addedInput schema / properties / longitude / type
```
Added value: +[
+  "number",
+  "null"
+]
```
- removedInput schema / properties / max_cloud / title
```
Removed value: -"Max Cloud"
```
- removedInput schema / properties / place / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- removedInput schema / properties / place / default
```
Removed value: -null
```
- removedInput schema / properties / place / title
```
Removed value: -"Place"
```
- addedInput schema / properties / place / type
```
Added value: +[
+  "string",
+  "null"
+]
```
- addedInput schema / properties / sun_alt_max
```
Added value: +{
+  "default": -15,
+  "type": "number"
+}
```
- removedInput schema / title
```
Removed value: -"astronomy_weatherArguments"
```

Changed2 schema fields changedv0.30.1Sep 16, 2026

removedInput schema / properties / include_chart

Removed value: -{
-  "default": true,
-  "title": "Include Chart",
-  "type": "boolean"
-}

addedInput schema / properties / include_rain

Added value: +{
+  "default": true,
+  "title": "Include Rain",
+  "type": "boolean"
+}

Changed1 schema field changedv0.29.1Sep 15, 2026

addedInput schema / properties / include_chart

Added value: +{
+  "default": true,
+  "title": "Include Chart",
+  "type": "boolean"
+}

Addedv0.25.2Sep 12, 2026

TDQS

A4.6/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 no authentication, worldwide coverage, the analytic estimation of solar altitude (because Open-Meteo does not return it hourly), and the polar-day/polar-night fallback to is_day alone. It also states failure behavior for include_rain (continue without the attachment) and instructs verbatim quoting of structuredContent.figure.notes plus link handling for harnesses that do not 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 and examples are front-loaded, followed by a well-organized Args block where every parameter line earns its place. The trailing harness note about inline image rendering is somewhat verbose and slightly tangential, but it is operationally useful rather than filler.

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 seven-parameter tool with no annotations and no output schema, the description is substantially complete: parameters, defaults, precedence, limitations, and attachment behavior are all covered, and the figure.notes guidance compensates for the missing output schema. It does not describe the shape of the main forecast response (e.g., how windows are scored or returned), which leaves a modest gap.

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%, yet all seven parameters are explained with meaning, units, defaults, and examples: latitude/longitude with Tokyo sample values and precedence rules, days 1-7 default 3, max_cloud as the observable threshold in percent default 40, and sun_alt_max with the -18/-15/-6 interpretation spelled out. This fully compensates for the empty schema.

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?

States a specific verb and resource: it forecasts the best time windows for astronomical observation, names the backing service (Open-Meteo), and notes no-auth/worldwide scope. The three example queries (Tokyo tonight, Sydney clear-sky forecast, Mt. Fuji summit cloud cover) make the resource unmistakable and separate it from sibling weather/satellite tools like weather_satellite_now.

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?

Gives concrete usage context through example utterances and resolves the main invocation ambiguity: 'place' takes precedence over latitude/longitude, and lat/lon may be omitted when place is supplied. It also scopes include_rain to Japan only. It stops short of naming an alternative tool or stating when not to use it.

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

Deploy Server

astronomy_weather

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools