Space Finder MCP is an MCP server that lets AI agents search, compute, visualize, and cite space/astronomy data from many public sources using natural language.
Reverse-lookup historical “firsts” and records, and list upcoming, Chinese, and Russian rocket launches.
Fetch NASA daily data (APOD, near-Earth objects) and search space images, audio, and videos with inline display or links.
Search Earth-observation and satellite data across ISRO, ESA/Copernicus, JAXA, CSA, INPE, DLR, Roscosmos, UK EO DataHub, CNES, CNSA, AWS Earth Search, and EO Dashboard.
Get satellite/orbit info: TLEs, ISS/Tiangong positions, ground tracks, QZSS status, weather-satellite imagery, and WMO OSCAR satellite status.
Compute sky/astronomy views: constellations, sky maps with satellites, solar-system positions, eclipses, moon phases, astronomy weather, news, and Mars rover status.
Query astronomical catalogs and archives: SIMBAD, VizieR, exoplanets, MAST/JWST/HST, ALMA, CADC, GCN alerts.
Search literature and planetary evidence with DOI citations from OpenAlex, Crossref, NASA NTRS, JAXA, J-STAGE, CiNii, Zenodo, and DataCite.
Monitor space weather and hazards: solar flares/CME/geomagnetic storms/forecasts, fireballs, NEO close approaches, and impact risk.
Manage an astronomy calendar: monthly event images/JSON, event lists, and add/remove personal events.
Return structured plus human-readable content, annotated generated figures, media links, caching, and concurrent tool-call handling.
Provides access to NASA's Astronomy Picture of the Day, near-Earth object close-approach data, and search of NASA image, video, and audio libraries.
Enables reverse historical lookup queries (e.g., first space telescope by country, first astronaut by nationality) via Wikidata SPARQL, returning cited results and Wikipedia article links.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@space-finder-mcp show me photos of Jupiter"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
宇宙・天文データを横断検索し、画像・動画・音声までチャット上で表示できる Model Context Protocol (MCP) サーバーです。
惑星・人工衛星・宇宙ミッションのメディア検索、ロケット打ち上げ、小惑星接近情報、「史上初の宇宙望遠鏡は？」といった逆引き歴史Q&Aを、AIエージェント（Claude / Cursor / Hermes 等）から自然言語で呼び出せます。
「Space Finder」は宇宙(Space)に関する情報を探すMCPです。「物理的な空間＝オフィス・駐車場を探す」同名サービスとは無関係です。
画像・動画・音声をそのまま返せる — 画像はチャット内にインライン表示、音声・動画は再生URLを返却
tokyo-transit方式のJSON応答 — 人間向け表示（content）とLLM向け純粋JSON（structuredContent）を分離し、情報を失わずに構造化データを渡せる
認証不要のツールが大半 — APIキーの管理なしですぐ動く（NASA の一部ツールのみ任意キー。ESA/Copernicus は検索・プレビューのみで、認証付きダウンロードは非対応）
他国の宇宙機関データに対応 — インド ISRO・欧州 ESA/Copernicus・日本 JAXA・カナダ CSA・ブラジル INPE・英国 EO DataHub・フランス CNES・ドイツ DLR EOC・ロシア Roscosmos オープンデータ・中国 CNSA 系ポータル・全衛星軌道(CelesTrak)・EO Dashboard(NASA/ESA/JAXA共同) を横断検索
天体カタログと系外惑星、準天頂衛星に対応 — 天体の素性は SIMBAD、観測星表は VizieR（いずれも CDS・認証不要）、系外惑星は NASA Exoplanet Archive、みちびき（QZSS）の精密軌道は内閣府の公開アーカイブ API から取得します（QZSS は提供元明記の非商用利用のみ）
引用元を明示 — 科学的な内容には必ずデータソースへのリンクを併記
図の注記を機械可読で返す（figure/1） — 描画系ツールは「どの面を・どの縮尺で・主天体を焦点に置いたか」と注記・自己検証を JSON で返し、LLM が図を誤読しないようにする
⚠️ 注（出力のどこまでが保証か） — ツールが返す**
structuredContentの JSON・数値・画像・リンクは、同じ引数で同じ時刻に呼べばどのモデルからでも同じ内容です（データ取得と計算はサーバー側で完結し、モデルには依存しません）。一方、それを読みやすい文章に組み立てる工程はホスト側の AI モデルに委ねられます**。説明の順序・語り口・要約の粒度・強調する点はモデルや設定によって変わるため、同じツール結果でも書き上がりは同一にはなりません。数値や出典の最終的な根拠はstructuredContentに置いてください（表示文と食い違って見える場合は JSON 側が正で、その差は「モデルの文章化」のばらつきです）。
Related MCP server: NASA MCP Server
描画系ツール（solar_system_now / sat_ground_track / planetary_orbiter_track / planetary_rover_location_map / sky_map_with_satellites / solar_eclipse_series / moon_phase_map / astronomy_weather〔雨雲・降水画像を返すとき〕 / space_calendar）は、画像を返すだけでなく structuredContent.figure（schema: "figure/1"） に「その図をどう描いたか」を自己申告します。LLM はピクセルから描画規約を推測できないため（高離心率の軌道を「主天体の周りを回る円」と説明してしまう等）、注記をデータとして渡す設計です。
view — どの面を（frame）どの投影で（projection）見た図か、なぜその視点なのか（why）
primary — 主天体を焦点（at: "focus"）に置いたか中心（"center"）に置いたか、焦点と中心のズレ（center_offset）
scale — 線形／対数（type）、実寸か（to_scale）、誇張している要素（exaggerated）
conic — 軌道の円錐曲線（kind: ellipse / parabola / hyperbola、a / e / q / apo / c）
notes — 図の誤読を防ぐ注記。数値から生成するので図と文が食い違いません
地図タイルが取れなかった場合は「地図タイル N/M 枚を取得できませんでした（図の該当領域は背景色のまま）」も数値から生成します（欠けを黙って捨てると「地図に無い＝何も無い」と誤読されるため）
verify — 図の自己検証（描いた画素から測った近点／遠点距離、ラベルの線被り画素数、periapsis_check: equality / upper_bound）
近点が画面上で分解できない図（超長距離の楕円では近日点が「誇張した主天体の円盤」の内側に入る）は、画素から近点距離を測っても意味がないため等値検査をせず、periapsis_resolvable: false ＋ 理由 ＋ 上界検査（曲線が焦点から円盤半径以上に近点側へ伸びていないこと＝主天体を楕円の中心に置く誤りは依然として検出）に切り替えます。この場合の注記には「この縮尺では図から確認できない」旨が数値から生成されて入ります
verify.panel_overlaps_marker — 地図の上に置く情報パネルが現在位置マーカーを隠していないか。パネルは surface_map.panel_placement() がマーカーを隠さない隅へ置き、どの隅でも重なる小さい図ではマーカーをパネルの上に描き直します（描いた後にパネルを重ねるとマーカーが消えるため。実測: 月面の LRO が図の上端に来ると左上のパネルの下に入り、画素検査 marker_pixels が 0 になりました）
notes_usage — 注記の扱いをホスト LLM に伝える指示文（「要約・言い換えせず引用すること」）。structuredContent 側にだけ入れます
caption — そのまま使える1〜2文の説明
content（人間向け表示）にも同じ注記を ### ⚠️ 図の注記 として出すので、structuredContent を使わないクライアントでも注記は失われません。なお content は人間が読むチャネルなので、LLM への指示文（「要約せず引用してください」等）は入れません（表示に指示文が混ざると読み手に意味不明な文が出るため。指示は docstring と figure.notes_usage ＝ JSON 側に置きます）。
uv run python scripts/check-tools.py --figures # 描画系の figure/1 を検査（注記が空・verify.ok が偽なら exit 1）
uv run python scripts/check-tools.py --media-links # 画像/音声/動画のリンク先行を検査（画像より前にリンクが無い等で exit 1）
uv run python scripts/check-tools.py --concurrency # 並列ツール呼び出し（single-flight／スレッド逃がし／例外漏れ）を検査
uv run python scripts/check-tools.py --stdio # 実クライアント経路（stdio）で代表ツールが無応答にならないか検査LLM は1ターンで複数のツールを並行に呼びます。サーバー側がそれに応えられるかは別問題で、FastMCP は同期関数をイベントループ上でそのまま呼ぶため、素のままだと1つのツールが API 待ちをしている間、他のツール呼び出しは1つも動き出しません（実測: 同一ツール4並列で wall = 各呼び出しの合計 2.55s）。
同期ツールは anyio のワーカースレッドで実行（server.py の _threaded / _reg）。同じ4並列が wall 2.47s・4.0× になりました。実ネットワークでも、別々の地名の astronomy_weather 3並列が 3.93s（逐次合計 11.72s・3.0×）です。
同じ引数の並行呼び出しは1回に集約（cache.ttl_cache の single-flight）。8並列の同一呼び出しでも実行は1回・結果は共有なので、NASA の DEMO_KEY のような共有枠を N 倍消費しません。
matplotlib で描く経路は img_common.RENDER_LOCK で直列化。pyplot はプロセス全体の状態（rcParams・現在の figure）を持つため、並列に描くと図が混ざります。
共有状態はロックで保護（cache / nasa_budget）。キャッシュされた戻り値は呼び出し側で書き換えません（並行時に他人の結果を壊すため。書き換えるなら deepcopy）。
CPU 律速の計算は GIL で並列化しません（Skyfield・Pillow の計算）。並列化が効くのは I/O 待ち（API 呼び出し）で、それが並列ツール呼び出しの主目的です。
検査: uv run python scripts/check-tools.py --concurrency（single-flight／ワーカースレッドへの逃がし／混在4ツールの並列呼び出しで例外漏れ・structuredContent 欠落が無いこと）。
⚠️ 遅延 import するネイティブ拡張は起動前に import 済みにしておきます（server.py 冒頭の import numpy）。stdio サーバーが動き出した後に numpy / matplotlib / skyfield を import すると、import が返らずツール呼び出しが無応答になります（実測: numpy・matplotlib.pyplot・skyfield.api が HANG。PIL.Image・sgp4・requests は問題なし）。scripts/check-tools.py --stdio が実際に子プロセスを起動して代表ツールの応答を確認します。
「自然な入力をしたのに 0 件／エラー」を防ぐため、名前の解決を name_common.py の共通段階に集約しています（各ツールが個別に対処すると必ず穴が残るため）。
段階 | 内容 | 実例（実測） |
1. 内蔵テーブル / 既知名 | 速い・オフライン |
|
2. 表記ゆれ（空白/アンダースコア/連結/大小） | アーカイブは観測者の入力そのままを持つ |
|
3. 和名 → 英語名 |
| 「ひまわり」→himawari、「ひので」→29479、「オリオン大星雲」→Orion Nebula |
4. 名前 → 座標 | Sesame/CDS（SIMBAD・NED 横断・認証不要） |
|
5. それでも駄目なら 候補を提示して停止 | 推測で検索しない | ALMA はアーカイブ内の候補名、CelesTrak は既知の名前一覧を提示 |
JA_ALIASES は 103 キー: 日本の気象・地球観測・科学衛星（ひまわり/だいち/いぶき/しずく/しきさい/みちびき/ひので/あかつき/はやぶさ2…）、有人・輸送（宇宙ステーション/きぼう/こうのとり）、宇宙望遠鏡（ハッブル/JWST/スピッツァー/ケプラー/ガイア…）、中国機（天宮/天和/問天/夢天/神舟/嫦娥…）、深宇宙天体（銀河・星雲・星団17件）、明るい恒星16件。
現役衛星は WELL_KNOWN に NORAD ID を実測登録（CelesTrak GROUP=active の OBJECT_NAME と突合）: ひまわり8/9号、だいち2/4号、いぶき/いぶき2号、しずく、しきさい、あじさい、あらせ、れいめい、ひさき、天和/問天/夢天、ISS、ハッブル、ひので 等 → 和名から NORAD ID までオフラインで解決（衛星系キーの 21/61。残りは過去機・番号なしのファミリー名で、曖昧なら候補提示、退役機は「表示できない」と正直に返す）。
適用先: alma_search（表記ゆれ＋候補提示）/ cadc_observations（名前→座標のフォールバック）/ satellite_status（和名展開＋一致件数の明示）/ sat_tle（和名→NORAD ID 解決＋候補提示）
⚠️ 修正の根拠は実測: 以前は cadc_observations("M104") が即エラー、satellite_status(query="ひまわり") と sat_tle(name="ひので") が 0 件、alma_search("HL Tau", band=7) が 0 件でした（すべて現在は解決）。
Hermes Agent のようなリッチなクライアントは ImageContent をそのまま描画しますが、CLI系・Android系のハーネス（codex / opencode など）は画像ブロックを無視するため「画像が生成されたのに何も表示されない」状態になります。そこで メディア本体より前に、アイコン付きの markdown リンクを必ず出します。
種別 | 出る場所 | 形 |
生成画像（描画系8ツール） |
|
|
検索した画像（ | 各項目の説明の直後 |
|
検索した音声（ | 各項目の直後 |
|
検索した動画（ | 各項目の直後 |
|
気象衛星の実画像（ |
|
|
気象庁の雨雲・降水画像（ | 各画像の直前行 |
|
EO Dashboard のサムネイル（ | 説明の直後・画像の直前 |
|
APOD の画像URL（ | タイトルの直後 |
|
生成画像は %LOCALAPPDATA%\Temp\space_finder_mcp\out\<tool>_<日時>_<乱数>.<ext> に生バイトのまま保存し、file:// URI と実パスの両方を出します（最新200件を残して自動整理）。
同じパスを structuredContent.image_path にも入れるので、LLM はファイルを再参照できます。
URL 内の空白・括弧は %20 / %28 にエスケープします（NASA のアセットURLには空白入りの動画名があり、生のままだとリンクが途中で切れます）。
content の並びは常に「リンクを含むテキスト → ImageContent」なので、画像を描けないクライアントでもリンクは必ず見えます。
機械的に検査します — scripts/check-tools.py --media-links（画像ブロックより前にアイコン付きリンクが無い／リンクの文言が統一形式でない／リンク行が空行で区切られていない／structuredContent にURL・保存パスが無い／image_path のファイルが存在しない／配信時（server._threaded）に整形されていない場合は exit 1。実測: メディアを返す全ツール OK）。生成系の docstring には「回答時はこのリンクをそのまま提示してください」と明記しています。
リンクの文言は img_common.media_link_line(対象, kind=…) が生成します — 動詞は kind から決まる（画像を開く / 生成した画像を開く / 音声を開く / 動画を開く / ファイルを開く）ので、ツール側で動詞を書かない限り表記は必ず揃います（手書きすると「サムネイル画像を開く: 」「動画を再生: 」のようにばらつく。ゲートの img_common.canonical_media_label() が検出）。
複数のメディアを返すときは、リンクをまとめて先に出し、各リンク行を空行で区切ります — Markdown は同一段落内の単一改行をスペースに畳み込むため、単一改行で組むと隣り合うリンクや caption が 1行に融合します（1枚だけ返すときは段落が分かれるので気付きにくい。実測: astronomy_weather の気象庁画像2枚、複数画像を並べた回答）。配信時に server._delivered が img_common.layout_media_links() で空行を補うので、ツール側で入れ忘れても融合はしません（ゲートの融合検査は配信される形＝整形後で行い、整形そのものが働いているかは delivery_issues() が確かめます）。
各バージョンの変更内容は GitHub Releases に記載しています（最新: v0.39.2）。
README では履歴を二重管理しません — 同じ内容を2か所に書くと必ず片方が古くなるため、変更点はリリース時に GitHub Releases の本文へ書きます（手順は CLAUDE.md の「リリース手順」）。
uv（Python 3.11+）
画像を返すツールの日本語表示には OS の日本語フォントを使います（Windows: メイリオ / macOS: ヒラギノ / Linux: Noto CJK 等。無い環境では下記「日本語フォント」参照）
# リポジトリをクローンして依存インストール
git clone https://github.com/loosephoto/space-finder-mcp.git
cd space-finder-mcp
uv sync# MCP サーバー起動（stdio）
uv run space-finder-mcpローカルで
uv runを使うため、uvがPATHにある必要があります。
画像を返すツール（sat_ground_track / moon_phase_map / solar_eclipse_series /
sky_map_with_satellites 等）は、図中の日本語を描くために Windows / macOS / Linux それぞれの
標準日本語フォント を自動で探します（img_common.py）。探索順は
(1) 環境変数 → (2) OS 標準パス → (3) 標準フォントディレクトリの走査 で、
採用する前に そのフォントが実際に日本語グリフを持っているかを cmap で検証します
（名前だけでは判定できないため。例: DejaVu Sans は日本語なし）。
OS | 主な採用フォント |
Windows | メイリオ（ |
macOS | ヒラギノ角ゴシック W3（太字は W6）→ Arial Unicode MS |
Linux | Noto Sans CJK JP → IPAex ゴシック → IPA ゴシック → VL ゴシック / Takao ゴシック |
日本語フォントが1つも入っていない環境（最小構成の Linux 等）では画像の日本語が**豆腐（□）**に
なります。その場合は日本語フォント（例: fonts-noto-cjk / fonts-ipaexfont-gothic）を入れるか、
環境変数で明示指定してください。
export SPACE_FINDER_FONT="/usr/share/fonts/opentype/noto/NotoSansCJK-Regular.ttc"
export SPACE_FINDER_FONT_BOLD="/usr/share/fonts/opentype/noto/NotoSansCJK-Bold.ttc"現在の解決結果は検証ゲートで確認できます（日本語グリフを持たないフォントを掴んでいれば exit 1）。
uv run python scripts/check-tools.py --fontsengine="accurate"（matplotlib）の sky_map_with_satellites / solar_system_now も同じフォントを使います
（img_common.apply_matplotlib_cjk_font()）。
apod・neo_today は api.nasa.gov の無料キーを使います。未設定でも DEMO_KEY で動作しますが、レート制限 30 req/hr/IP と低く、2ツールが同じ枠を取り合います。実用にはキーを推奨します。なお space_weather(DONKI) は 2026-09-30 の URL 移転で認証不要の別ホスト（ccmc.gsfc.nasa.gov/DONKI-API）になり、fireball_reports / neo_close_approach / impact_risk（JPL CNEOS）と space_weather の SWPC フォールバックも認証不要なので、この枠を消費しません。
呼び出し回数はサーバー側で管理しています（nasa_budget.py）— 直近1時間の使用数を数え、枠を使い切っていたらHTTP を投げずに回復までの目安（例:「約30分後に自動的に回復します」）を返します。実際に 429 を受けた場合は Retry-After を尊重し、その間は再試行しません（同じ 429 を繰り返し踏みに行かない）。CelesTrak も短時間の連続リクエストで IP 単位に遮断され（403、または TCP が返らない blackhole）、その間は 1 回の呼び出しが分単位で固まります。接続は (connect 10 秒, read 25 秒) で打ち切り、遮断を受けたらセッション内で記憶して以降は HTTP を出さずに即座に案内を返します（sat_tle / sat_ground_track / tiangong_now / sky_map_with_satellites が該当）。 さらに TLE は代替源へ自動フォールバックします — CelesTrak 遮断中は認証不要の公開ミラー（tle.ivanstanojevic.me → db.satnogs.org）から同じ衛星の TLE を取得し、content / structuredContent にどちらから取ったかを明示します（tle_source。代替源の TLE を「CelesTrak の TLE」と書かないため）。グループ検索（group=）は代替源に無いので、遮断中はその旨を案内します。
キーの取得方法（無料・即時発行）: api.nasa.gov にアクセスし、メールアドレスを登録するだけで 無料の API キーが即時発行されます。無料開発者キーのレート制限は 1時間あたり 1,000 リクエスト です（実用に十分な容量）。登録時に入力したメール宛てに確認が来ます。
# (a) 環境変数で渡す
export NASA_API_KEY="your_key_here"
# (b) リポジトリ直下の .env に書く（MCPクライアントの設定にキーを書きたくない場合）
cp .env.example .env # 編集して NASA_API_KEY=... を記入（.gitignore 済み・コミット禁止）優先順位は MCPクライアントの env > リポジトリ直下の .env です（未設定なら DEMO_KEY）。
キーの取り扱い: 応答に含まれる API キーは伏せ字化します（
nasa_budget.redact()→api_key=***、budget.keyはDEMO_KEY/customのみ）。requests の例外文字列が URL ごとキーを含むため、そのまま返すと利用者のキーが漏れるためです。
space_literature_search / planetary_evidence で利用する追加ソースのキーです。3つとも任意で、未設定でも OpenAlex / Crossref / NASA NTRS / JAXAリポジトリ / J-STAGE / CiNii / Zenodo / DataCite は引き続き利用できます。キー未設定のソースはスキップされ、理由を sources[].note に返します。
ADS_API_KEY — NASA ADS の無料トークン。登録して取得し、設定すると ADS の書誌検索を利用できます（上限 5,000 リクエスト/日）。
S2_API_KEY — Semantic Scholar の API キー。未設定でも検索を試みますが、共有レート制限により HTTP 429 になる場合があります。
WOS_API_KEY — Clarivate Web of Science Starter API のキー。登録が必要です。無料枠は 1 リクエスト/秒・50 リクエスト/日で、被引用数は返りません。
設定先は MCP クライアントの環境変数（優先）またはリポジトリ直下の .env です（変数名と空欄の例は .env.example を参照）。キーはサーバー側でのみ扱い、クライアントへの応答には含めません。
copernicus_search の検索とプレビューURL取得は認証不要で動作します。本サーバーは OAuth2 による認証付きダウンロードは行いません（CDSE_CLIENT_ID 等のクレデンシャルは使用しません）。実際の画像ダウンロードが必要な場合は Copernicus Data Space で取得してください。
cd /絶対パス/space-finder-mcp
claude mcp add -s project space-finder -- uv --directory "$(pwd)" run space-finder-mcp
claude mcp list # 確認（space-finder が表示されればOK）-s project はリポジトリ直下に .mcp.json を作ります（共有向け）。個人利用なら -s user を指定します。
プロジェクトガイドは CLAUDE.md、開発規約は .claude/rules/ にあります（Claude Code が自動で読み込みます）。
codex mcp add space-finder --env NASA_API_KEY=<your_key> -- uv --directory <絶対パス>/space-finder-mcp run space-finder-mcp
codex mcp list--env は省略可（その場合は .env か DEMO_KEY を使用）。エージェント向けガイドは AGENTS.md です。
claude_desktop_config.json / mcp.json）同梱の mcp.json を参考に設定してください（args のパスは環境に合わせて書き換えます）。
{
"mcpServers": {
"space-finder-mcp": {
"command": "uv",
"args": ["--directory", "/絶対パス/space-finder-mcp", "run", "space-finder-mcp"]
}
}
}
envを書く場合は空文字を入れないでください（空だとDEMO_KEYにフォールバックしません）。キーはenvか.envのどちらか一方に置けば十分です。
ファイル | 用途 |
Claude Code 用プロジェクトガイド（セットアップ・規約・検証・リリース手順） | |
Codex など | |
エージェント向けスキル定義（66ツールの仕様・使用例・キャッシュ・注意事項） | |
開発規約（コーディング・検証ゲート・データ出典） |
hermes config set mcp_servers.space-finder-mcp.command uv
hermes config set 'mcp_servers.space-finder-mcp.args' '["run", "--project", "/絶対パス/space-finder-mcp", "space-finder-mcp"]'
# 反映には再起動登録ツールは 66本（宇宙・天文イベントカレンダー 4本（space_calendar / calendar_events / calendar_event_add / calendar_event_remove）＋ロケット打ち上げ・逆引き 4本＋NASA日次・宇宙天気 3本＋メディア 3本＋各国宇宙機関・地球観測 18本＋衛星・軌道 6本＋天体位置・画像合成 7本＋観測支援・天文データ 13本（うち天体カタログ 2本（object_lookup / catalog_search）・系外惑星 1本（exoplanet_search））＋気象衛星リアルタイム画像 1本＋天体異常系 3本＋学術文献 2本）。全66ツールを実呼び出しで検証済みです（外部APIの障害・レート制限時は、例外ではなく CallToolResult のエラーとして返します）。
ツール | できること | データ源 | 認証 |
| 「史上初の宇宙望遠鏡は？」等をカテゴリ+国+時期から解決 | Wikidata SPARQL | 不要 |
| 今後のロケット打ち上げ予定（日時・機体・射場・状態） | Launch Library 2 | 不要 |
| 中国のロケット打ち上げ予定（長征・Shenzhou・LandSpace等・射場・ミッション） | Launch Library 2 | 不要 |
| ロシア（Roscosmos）のロケット打ち上げ予定（ソユーズ・Progress・Luna等・射場・ミッション） | Launch Library 2 | 不要 |
| 今日（指定日）の天文写真 | NASA Open API | キー(任意) |
| 今日地球に接近する小惑星 | NASA Open API | キー(任意) |
| 惑星・衛星の画像検索＋チャット内インライン表示（既定は先頭1枚・ | NASA Image & Video Library | 不要 |
| 宇宙音声の検索（ | NASA / Sounds from Beyond | 不要 |
| 宇宙動画の検索＋再生URL（解像度別・字幕付き） | NASA Image & Video Library | 不要 |
| インドISROの人工衛星・ロケット・顧客衛星・センター一覧/検索 | ISRO公式API (github.com/isro/api) | 不要 |
| ESA Copernicus の衛星データコレクション一覧 | Copernicus Data Space (STAC) | 不要 |
| ESA Copernicus の衛星画像を STAC で検索（領域・日時・雲量） | Copernicus Data Space (STAC) | 不要（検索・プレビューのみ） |
| JAXA Earth の地球観測データセット一覧（ALOS/GSMaP/GCOM等） | JAXA Earth API (STAC COG) | 不要 |
| JAXA Earth データセットをキーワード検索 | JAXA Earth API (STAC COG) | 不要 |
| カナダCSAオープンデータ（RADARSAT等）を検索 | CSA Open Data Portal (CKAN) | 不要 |
| ブラジルINPEの衛星データコレクション一覧 | INPE BDC STAC | 不要 |
| ブラジルINPEの衛星画像（CBERS・Amazonia-1等）をSTAC検索 | INPE BDC STAC | 不要 |
| ドイツDLRの地球観測コレクション一覧（Sentinel-2 MAJA・EnMAP・TROPOMI等） | DLR EOC STAC | 不要 |
| ドイツDLRの地球観測データをSTAC検索（領域・日時・雲量） | DLR EOC STAC | 不要（検索・プレビューのみ） |
| ロシアRoscosmosオープンデータのコレクション一覧（Elektro-L・Arktika-M・Meteor-M） | Roscosmos open data STAC | 不要 |
| ロシアの気象衛星の全球画像（Elektro-L・Meteor-Mモザイク等）を検索 | Roscosmos open data STAC | 不要 |
| 全世界の衛星の軌道要素(TLE)を取得（ISS・ハッブル・気象衛星等） | CelesTrak (NORAD) | 不要 |
| 英国EO DataHubのコレクション一覧 | UK EO DataHub STAC | 不要 |
| 英国EO DataHubの衛星・気候データをSTAC検索 | UK EO DataHub STAC | 不要 |
| フランスCNESのポータル（THEIA/GEODES）到達状態・概要 | CNES THEIA/GEODES | 不要(ダウンロードは要登録) |
| 天体観測に最適な夜間の時間帯を予報（雲量・視程・風速・降水・月相・月明かりから判断）。日本国内の地点では気象庁の雨雲・降水画像（解析雨量・降水短時間予報パネル＋ナウキャスト、雷の有無も確認）を画像で同時に返す（ | Open-Meteo + 気象庁（ナウキャスト・解析雨量） | 不要 |
| 指定地点・時刻で太陽・月・惑星の高度・方位・星座を計算（観測可否判断） | Skyfield + JPL de421 | 不要 |
| 最新の天文ニュース・「今週の星空ガイド」を取得（観測/ニュース絞込可）。取得不可時は他ソースへ自動フォールバック | Sky & Telescope / Universe Today / NASA / Phys.org RSS | 不要 |
| 火星探査ローバー（キュリオシティ等）の現在の状況・天気・ソルを表示 | NASA Mars Weather | 不要 |
| 任意地点の過去の気候・太陽エネルギー統計（気温・日射量・風速） | NASA POWER | 不要 |
| ESO パラナル天文台（チリ, VLT）のリアルタイム大気コンディション（シーイング・可降水量・気象） | ESO ASM API | 不要 |
| CADC（カナダ天文データセンター）の観測データ検索（HST・ジェミニ等） | CADC TAP | 不要(画像DLは一部要登録) |
| NASA GCN（General Coordinates Network）の過渡天体速報。GRB・X線新星・重力波などの GCN Circular を期間（ | NASA GCN (gcn.nasa.gov) | 不要 |
| MAST（NASA/STScI の宇宙望遠鏡アーカイブ）の観測データ検索。JWST・ハッブル(HST)・TESS・Kepler・GALEX 等を、天体名（和名可・Sesame で座標解決）／座標コーン／装置（部分一致）／データ種別／観測日で検索。観測ID・装置・観測日・校正レベル・フィルタ・ | MAST Mashup API | 不要 |
| ALMA（アルマ望遠鏡）科学アーカイブの観測データ検索（観測対象・座標・周波数帯・公開/要権限） | ALMA Science Archive (NAOJ, IVOA TAP) | 不要 |
| 天体の素性を SIMBAD から引く。天体名（和名可・Sesame で英語名へ展開）から主名・天体種別・スペクトル型・年周視差（→ pc / 光年）・固有運動・視線速度・参考文献数・等級（U/B/V/R/I/J/H/K）を返す。 | SIMBAD TAP (CDS) | 不要 |
| 観測星表の円錐検索（VizieR）。2MASS / Gaia DR3・EDR3 / ヒッパルコス / AllWISE / unWISE / Pan-STARRS1 / SDSS DR16・DR12 / NGC を、天体名（和名可）または座標から検索し、星表の列名・単位そのままで返す（生の表名 | VizieR ASU (CDS) | 不要 |
| 系外惑星（NASA Exoplanet Archive）。恒星名／惑星名の部分一致（和名は「ケプラー22」→ Kepler-22 b のように英字名へ展開）・発見方法（日本語可）・恒星距離・発見年・地球類似条件（半径0.5〜2 R⊕・平衡温度200〜320 K）で検索し、軌道周期・軌道長半径・半径・質量・平衡温度・恒星型・距離・TIC/Gaia ID を返す。0件時は候補の恒星名を提示。出典 DOI | NASA Exoplanet Archive (TAP) | 不要 |
| 惑星科学・宇宙の一次文献（論文・技術報告）を横断検索して根拠（DOI付き）を返す。OpenAlex（要旨・被引用数・OAリンク）・Crossref・NASA NTRS（技術報告＋PDF）・JAXAリポジトリ・J-STAGE・CiNii Research・Zenodo・DataCite を1回で横断し、DOI/タイトルの重複を統合。日本語クエリは語彙辞書＋和名テーブルで英語語へ置換してから英語圏ソースへ投げる（実測: OpenAlex/Crossref は日本語クエリだと無関係な文献を返すため）。 | OpenAlex / Crossref / NASA NTRS / JAXAリポジトリ / J-STAGE / CiNii / Zenodo / DataCite | 不要（ |
| 天体（惑星・衛星・小天体・探査機）の文献的な裏づけをまとめて返す。①名前解決（Sesame/CDS で和名→英語名→座標）と、②その天体の文献を英語圏＋日本語の両方から集めて提示（既定は被引用数順。惑星科学概念で絞った OpenAlex を上位に置く＝実測「火星」で MOLA / OMEGA-Mars Express / ALH84001 が上位に来る）。⚠️ 太陽系天体は時刻で位置が変わるため固定座標を持たない旨を | OpenAlex / Crossref / NASA NTRS / JAXAリポジトリ / J-STAGE / CiNii ＋ Sesame/CDS | 不要 |
| TART オープン電波望遠鏡が「いま観測できる電波源」（GNSS・静止衛星等）を仰角順に表示 | TART source catalog (NZ) | 不要 |
| 指定地の空を地上から見上げた画像（既定=地上視点パノラマ: Hipparcos実星表の恒星・天の川・街並み・方位目盛り・惑星・人工衛星。太陽高度で昼/夕方/朝焼け/薄明/夜の空色が変わり、今は見えない天体は○で位置を示す。 | JPL de421+Skyfield / Hipparcos(VizieR) / CelesTrak+SGP4 | 不要 |
| 太陽を中心とした太陽系の惑星・小惑星・探査機・彗星の現在位置俯瞰図（ハレー等の周期彗星とC/彗星・ボイジャー等の遠方天体まで対数縮尺で自動拡張表示）。 | JPL DE421+Skyfield / JPL SBDB / JPL Horizons | 不要 |
| 日食（太陽が月に欠ける過程）の時系列パネル画像（7枚・食分と太陽高度・次回日食の自動検索=約4年(1400日)先まで・max_magnitude対応。地平線下で見えない食は返さない） | JPL DE421+Skyfield | 不要 |
| 月齢マップ（月の満ち欠け）。 | JPL DE421+Skyfield | 不要 |
| EO Dashboard（NASA×ESA×JAXA共同）の173データセットをテーマ・機関・キーワードで検索 | EO Dashboard (GitHub catalog) | 不要 |
| EO Dashboardの1データセットの詳細（衛星・センサー・説明・画像・参照リンク） | EO Dashboard (GitHub catalog) | 不要 |
| 宇宙天気（太陽フレア・CME・地磁気嵐・太陽粒子現象）と予報（ | NASA DONKI（CCMC）→ NOAA SWPC（フォールバック）／予報は NOAA SWPC | 不要 |
| 火球（大気圏突入）の観測記録（直近1〜1825日・衝突エネルギーの下限指定可）。緯度経度・突入高度・衝突エネルギー(kt)・放射エネルギー(J)・突入速度（成分から算出）。広島型原爆（約15kt）との比を併記。⚠️ 隕石の回収情報ではなく大気圏突入の観測。呼ぶと結果がカレンダーの蓄積ストアに入り、後日 | NASA/JPL CNEOS Fireball Data | 不要 |
| 小惑星・彗星の地球接近（1〜365日先・距離上限 au）。地心距離を au / km / 月距離で併記し、既知の直径（無ければ絶対等級 H から推定・アルベド0.14 仮定）と接近時刻の不確かさを返す。 | NASA/JPL CNEOS SBDB CAD | 不要 |
| 将来の衝突リスク（JPL Sentry）。累積衝突確率を確率＋「何回に1回」で表示し、パレルモスケール・想定時期・想定衝突数を返す。 | NASA/JPL CNEOS Sentry | 不要 |
| AWS Earth Searchの衛星データコレクション一覧 | AWS Earth Search STAC | 不要 |
| Sentinel-2 / Landsat / NAIP / DEM をSTAC検索（場所・日時・雲量） | AWS Earth Search STAC | 不要 |
| ISS（国際宇宙ステーション）の現在位置を取得し Googleマップリンクで表示 | Open Notify | 不要 |
| 任意の人工衛星（ISS・ひので・ハッブル等）の現在位置と地上軌道を地球地図にプロットした画像を返す。CelesTrak TLE + Skyfield(SGP4) で真下の点・高度・速度を計算し、NASA Blue Marble 地図に軌道トレイルを重ねる | CelesTrak + Skyfield + Blue Marble | 不要 |
| 任意の天体（月・火星・水星・タイタン等）を周回する探査機の現在位置と軌道トレイルを、その天体の地図にプロットした画像を返す。JPL Horizons の状態ベクトルを IAU 自転モデルで天体固定座標（緯度経度・高度）に変換し、NASA Trek の等角図法地図に重ねる。 | JPL Horizons + NASA Trek / USGS Astrogeology / Hubble OPAL (STScI) / NASA NSSDC / PDS | 不要 |
| 任意の天体面を移動する探査ローバーの現在地をその天体の地図中心に示した画像（走行経路・着陸点）。NASA MMGIS の位置データと NASA Trek の等角地図を合成。現状データは火星ローバー（Perseverance/Curiosity） | NASA MMGIS + Trek WMTS | 不要 |
| GEO/LEO気象衛星19機（ひまわり9号・GOES-18/19・Meteosat・FY・GK-2A・INSAT・NOAA-20/-21・SNPP・Metop-B/C・FY-3D）の公開画像。GEOは最新フレーム、LEOは日次全球合成。取得不可は | JMA(himawari.asia)/NOAA STAR/EUMETSAT WMS/CMA-NSMC/KMA/IMD/NASA GIBS | 不要 |
| 宇宙・天文イベントカレンダー（月グリッド図＋JSON）。打ち上げ（LL2 の月範囲クエリ・日付精度 | Launch Library 2 + JPL DE421/Skyfield + 国立天文台 + JAXA + nasa.gov | 不要 |
| 蓄積済みイベントの一覧（図を描かず外部APIも呼ばない軽い経路）。打ち上げ・天文現象・小惑星接近・火球観測（ | 蓄積ストア（ローカル） | 不要 |
| 自分の予定をカレンダーに追加（ローカル保存・外部送信なし）。日付は | ローカル（ | 不要 |
| 自分の予定を削除（id か title[+date]）。冪等（既に無ければエラーにしない）。同名が複数あるときは削除せず候補を提示して停止 | ローカル | 不要 |
| 世界中の気象・地球観測衛星の運用ステータス・軌道・打ち上げ日（Roscosmos等）。カタログ全1,000件超を走査し、query は一致度順（acronym 完全/前方一致 → 名称の語境界 → 部分一致のみ）で提示 | WMO OSCAR | 不要 |
| みちびき（準天頂衛星システム QZSS）。既定では超速報 SP3（192エポック×15分≒48時間分の精密軌道）を解析し、各機の現在の緯度・経度・高度、東京からの仰角・方位、準天頂軌道の8の字の振れ幅を返す（J07 から PRN 表へ対応づけ、未対応 ID は ID のまま表示）。SP3 の全ゼロ座標など無効値は除外し、 | 内閣府 QZSS 公開アーカイブ API | 不要 |
| 中国CNSA系衛星データポータル（風雲/NSMC・高分/CNSA-GEO・CBERS/CRESDA）の到達状態・概要＋認証不要の代替経路 | CNSA各公式ポータル | 不要(ダウンロードは要登録) |
| 天宮（Tiangong）中国宇宙ステーションの現在位置（SGP4伝播＋Googleマップ表示） | CelesTrak TLE + SGP4 | 不要 |
惑星・衛星の説明を Wikipedia / Wikidata と LLM の既存知識だけで書くと根拠（一次文献）を示せません。
そこで公開の書誌 API を実測し、認証不要で実際に使えたものだけを space_literature_search /
planetary_evidence に組み込みました（2026-09 実測）。
API | 実測結果 | 本サーバーでの扱い |
OpenAlex | 200。要旨（abstract_inverted_index を復元）・被引用数・OAリンクを返す。⚠️ | 既定ソース（ |
Crossref | 200。⚠️ | 既定ソース（2語以下は |
NASA NTRS | 200。技術報告＋PDF リンク（ミッション設計・探査計画に強い） | 既定ソース |
JAXAリポジトリ（WEKO3） | 200。日本語クエリが効く（「はやぶさ2 リュウグウ」で9件） | 日本語ソース |
J-STAGE | 200（Atom）。⚠️ | 日本語ソース（利用規約に従い「表示情報提供元: J-STAGE」＋リンクを表示） |
CiNii Research | 200（OpenSearch JSON） | 日本語ソース |
Zenodo / DataCite | 200。データセット・プレプリントの DOI |
|
NASA ADS | トークン無しは 401。無料トークン（要登録・5,000req/日）で使える |
|
Semantic Scholar | キー無しは 429（共有枠。待っても回復しなかった） |
|
Web of Science（Starter） | キー無しは 401。無料枠は登録制・1req/s・50req/日・被引用数なし |
|
arXiv API | 本環境からは UA を変えても HTTP 406 | 実装しない（取得できないものを載せない） |
JDreamIII / J-GLOBAL | JDreamIII は JST の有償サービス（要契約・API も別契約）。J-GLOBAL WebAPI も MyJ-GLOBAL 登録＋キー交付が必要 | 実装しない（日本語文献は J-STAGE / CiNii / JAXAリポジトリで代替） |
reverse_lookup — 逆引き歴史Q&A「初めて」「記録」「〜による発見」など、カテゴリを横断して最初のもの・記録を Wikidata の構造化データから解決します。検索対象の種別を自動判別します。
機器系（宇宙望遠鏡・探査機・人工衛星・天文台）: instance-of + 打ち上げ日 + 国 で検索
人系（宇宙飛行士）: 職業(P106) + 生年 + 国籍 で検索
Q: 米国で最初に打ち上げた宇宙望遠鏡は？
A: → 1966年の OAO 系観測機が最古として返る
Q: 日本の最初の宇宙飛行士は？
A: 秋山豊寛（1942年生・日本人初）設計方針: 「記録・初」の答えは LLM の記憶から捏造せず、Wikidata SPARQL が根拠を返し、Wikipedia 記事 URL を引用します。
対応カテゴリ:
日本語 | 英語 | 種別 |
宇宙望遠鏡 | space telescope | 機器 |
宇宙探査機 | space probe | 機器 |
人工衛星 / 宇宙船 | satellite / spacecraft | 機器 |
天文台 | observatory | 機器 |
宇宙飛行士 | astronaut | 人 |
upcoming_launches — ロケット打ち上げ認証なしの公開API（Launch Library 2）から今後の打ち上げを返します。
apod / neo_today — NASA日次データapod: 今日（または指定日）の Astronomy Picture of the Day。
date 省略時は「今日」を明示指定して取得し、当日分が未公開（404）や API が 500 を返す場合は
直近の公開分（前日）へ自動フォールバックします（fallback_to_previous_day で判定可能）。
neo_today: 今日地球に接近する小惑星（直径・接近距離・速度）
キーはサーバー側でのみ保持し、クライアントへ晒しません（公開デプロイ時は環境変数・シークレット管理を推奨）。
search_space_images — 画像検索・表示NASA Image & Video Library から惑星・人工衛星の画像を検索し、チャットにインライン表示します。
content: テキストサマリ + base64の画像（ImageContent）。各項目の直後に 🖼️ [画像を開く: タイトル](URL) のリンクを出す（インライン描画できないクライアント向け）
structuredContent: {title, date, nasa_id, image_url, keywords} のJSON
転送量: インラインに埋め込む画像は既定で先頭1枚（inline_max=1〜5 で増やせる）。
高画質URLは structuredContent.results[].image_url に必ず入るため、必要なら再取得できます。
インライン画像は一段小さいバリエーション（~large→~medium）を使い、画像資産は
ディスクキャッシュされます（同じ画像を再ダウンロードしません）。
Q: 木星の画像を見せて → 木星の写真がチャットに表示されるsearch_space_audio — 音声検索宇宙関連の音声を検索します。kind 引数で用途を選べます。
kind | 対象 | 例 |
| 短い宇宙の音（惑星の電波・Sputnikのビープ・打ち上げ音） | 「スプートニクの音」 |
| 長尺の解説・インタビュー | 「アポロのポッドキャスト」 |
| 両方から探す（既定） |
各結果に再生URL＋尺の目安をJSONで返し、content には 🎧 [音声を開く: タイトル](URL) のアイコン付きリンクを出します。
search_space_videos — 動画検索宇宙動画（打ち上げ・ミッション映像・解説）を検索し、再生用MP4 URLを返します。
structuredContent: {title, video_url, urls:{preview/medium/mobile/orig/subtitle}, poster_url} — 解像度別URLと字幕(.srt)を分離
content: テキストサマリ + ポスター画像（インライン）。🎬 [動画を再生: タイトル](MP4 URL) と 🖼️ [ポスター画像を開く: …](URL) のリンクを先に出します
isro_data — インド ISRO の公式データISRO公式オープンAPI（Vercel配信・認証不要）から、ISROが打ち上げた人工衛星・ロケット・外国向け顧客衛星・センター/施設の一覧を返します。query で部分一致検索（例 "cartosat", "chandrayaan"）も可能。
Q: インドの人工衛星を教えて
A: → Aryabhata, Bhaskara-I, ... 全112件から返る
Q: ISROが外国向けに打ち上げた衛星は?
A: kind="customer_satellites" で 国・打ち上げ日・質量・ロケット 付きで返るcopernicus_collections / copernicus_search — 欧州 ESA CopernicusCopernicus Data Space Ecosystem の STAC API（stac.dataspace.copernicus.eu/v1）を利用。Sentinel-1/2/3 ほか地球観測衛星のメタデータを検索できます。
copernicus_collections: 利用可能なコレクション一覧（Sentinel-2 光学・Sentinel-1 SAR・Sentinel-3 海洋/大気 等）
copernicus_search: コレクション・空間範囲(bbox)・日時・雲量上限で衛星画像を検索。structuredContent に id/日時/雲量/bbox/プレビューURL を返す
認証: 検索とプレビューURL取得は認証不要。画像ダウンロードのみ Copernicus Data Space の無料アカウント（OAuth2 client_credentials）が必要です。設定時は環境変数 CDSE_CLIENT_ID / CDSE_CLIENT_SECRET をサーバー側に設定します（キーはクライアントへ晒さない）。
Q: 東京周辺の最近の Sentinel-2 画像を雲が少ない順に見たい
A: copernicus_search(collection="sentinel-2-l2a", bbox="139.6,35.5,139.9,35.8", max_cloud_cover=20)jaxa_datasets / jaxa_dataset_search — 日本 JAXA EarthJAXA Earth API の STAC COG カタログ（認証不要）から、地球観測データセットを探索します。ALOS 標高(AW3D30)・GSMaP 降水・GCOM-C/W・PALSAR-2 森林(FFN) など 60+ データセット。
jaxa_datasets: データセット一覧（ID・タイトル・アセット）
jaxa_dataset_search: キーワード検索（"GSMaP", "ALOS", "GCOM", "precip", "FNF" 等）
Q: JAXAの降雨データセットは?
A: jaxa_dataset_search("GSMaP") → GSMaP の正規・日次データセットが返るcsa_dataset_search — カナダ CSA オープンデータCSA Open Data Portal の CKAN API（認証不要）で、RADARSAT ほかカナダの宇宙データセットを検索します。CSAは中間CAチェーンが不完全なサーバーのため、OS の証明書ストアでTLS検証するアダプタを使用（検証を無効化しない安全な方式）。
Q: カナダの RADARSAT データは?
A: csa_dataset_search("radarsat") → RADARSAT-1 Archive ほか10件が返るinpe_collections / inpe_search — ブラジル INPEINPE BDC（ブラジル宇宙研究所）の STAC API（認証不要）で、CBERS-4/4A・Amazonia-1・GOES-19 等の衛星画像を検索します。
inpe_collections: 79コレクション一覧
inpe_search: コレクション・領域(bbox)・日時・雲量で画像検索
Q: ブラジル周辺のCBERS衛星画像
A: inpe_search("CB4-WFI-L4-SR-1", bbox="-46.6,-23.6,-46.5,-23.5")dlr_collections / dlr_search — ドイツ DLR（EOC 地球観測センター）DLR EOC（ドイツ航空宇宙センターの地球観測センター）の STAC 1.0.0 カタログ（69コレクション・認証不要）で、Sentinel-2（MAJA 大気補正・WASP 合成）・EnMAP／DESIS ハイパースペクトル・Sentinel-5P/TROPOMI（NO2・O3・AOD）・MetOp/GOME-2・世界居住域（WSF）・全球DEM（TanDEM-X 90m）・ドイツ国内プロダクトを検索します。
dlr_collections: コレクション一覧（ライセンス付き）
dlr_search: コレクション・領域(bbox)・日時・雲量上限で検索（サムネイル／メタデータのリンク付き）
Q: ベルリン周辺のドイツのSentinel-2画像
A: dlr_search("S2_L2A_MAJA", bbox="13.0,52.3,13.8,52.7", datetime="2026-01-01/2026-01-31", max_cloud_cover=20)⚠️ DLR の STAC は
filter（CQL2）もsortbyも受け付けません（実測: 前者は 400、後者は無視）。雲量の絞り込みは取得後にクライアント側で行い、excluded_by_cloud/without_cloud_infoに分けて返します。並び順は日時順とは限らないため、期間で絞るにはdatetimeを指定してください。ライセンスはコレクションごとの DLR 申告値（CC-BY-4.0 / CC-BY-NC-4.0 / proprietary が混在）です。
roscosmos_collections / roscosmos_search — ロシア Roscosmos オープンデータRoscosmos オープンデータ STAC（200TB 超・認証不要）から、Elektro-L（静止・15〜30分ごとの全球ディスク）・Arktika-M（高楕円）・Meteor-M（極軌道の日次全球モザイク）と全球モザイク（EL_ARCM / MM）を検索します。
roscosmos_collections: カタログ木を辿ったコレクション一覧（level 1〜3）
roscosmos_search: コレクションのパス＋日付（UTC）で検索。日付省略時はデータがある最新日
Q: ロシアの静止気象衛星エレクトロLの最新の全球画像
A: roscosmos_search("Electro-L/MSU-GS/L2_RGB_VIS_IR", limit=2)⚠️ このカタログは静的 STAC（
/search・/collectionsは 404）のため、catalog.json → コレクション → 年 → 月 → 日を辿って列挙します。ホストはs3.gptl.ru/s3ext.gptl.ruの2つで、到達できない側は記憶して他方へ切り替えます。各アイテムにはクイックルック（PNG）と GeoTIFF（EPSG:4326 / 3857）のリンクが付きます。
sat_tle — CelesTrak（全世界の衛星軌道）CelesTrak（NORADカタログ・認証不要）から、任意の衛星の軌道要素(TLE) を取得します。ISS・ハッブル・気象衛星・中国宇宙ステーション等、name・norad_id・group で指定可能。CelesTrak が遮断中（403 / 接続不可）のときは公開ミラー（tle.ivanstanojevic.me、予備 db.satnogs.org）へ自動で切り替え、structuredContent.source に実際の出典（celestrak.org か代替源のホスト名）を入れます。
Q: ISSの現在の軌道要素は?
A: sat_tle("iss") → 傾角・離心率・周回数・エポック
Q: 中国宇宙ステーションのTLE
A: sat_tle("tiangong") → CSS(TIANHE) の軌道要素uk_stac_collections / uk_stac_search — 英国 EO DataHubUK EO DataHub の STAC API（公開カタログは認証不要）で、Sentinel-2 ARD・UKCP気候モデル・EOCIS 等の英国データを検索します。
Q: 英国のSentinel画像
A: uk_stac_search("sentinel2_ard", bbox="-2.9,49.5,-2.8,49.6")※商用データ（Airbus/Planet）は要アカウント。
cnes_status — フランス CNESCNES の地球観測ポータル THEIA と GEODES の到達状態と提供データ概要を返します。画像ダウンロードには無料アカウント登録が必要です。
Q: フランスのCNES衛星データは?
A: cnes_status() → THEIA / GEODES の状態と概要astronomy_weather — 天体観測用天気（Open-Meteo ＋ 気象庁の雨雲・降水画像）Open-Meteo（認証不要・無料・全世界対応）から、指定地点の今後数日間で天体観測に適した夜間の時間帯を自動抽出します。雲量・視程・風速・降水確率・昼夜判定を総合して判断し、AIからのアドバイスを返します。
場所は緯度経度（latitude/longitude）または地名（place）で指定
富士山・マウナケア・アタカマ・阿智村などの著名観測地は正確な緯度経度を内蔵
max_cloud で観測可否の雲量基準を調整可能（既定 40%）
structuredContent に各時間帯の雲量・視程・風速・降水確率をJSONで返す
Q: マウナケアで今夜天体観測できる?
A: astronomy_weather(place="マウナケア") → 夜間の観測チャンス時間帯と雲量
Q: 東京で明日の星空は?
A: astronomy_weather(place="東京") → 雲が少ない夜間を抽出＋気象庁の雨雲・降水画像（解析雨量＋今夜の予報＋ナウキャスト）を添付
A: astronomy_weather(place="東京", include_rain=False) → 雨雲画像なしで予報のみ出典: open-meteo.com（CC BY 4.0 データ）
eodashboard_collections / eodashboard_detail — EO Dashboard（NASA×ESA×JAXA共同）EO Dashboard（NASA・ESA・JAXA 3機関共同の地球観測ダッシュボード）のデータカタログを検索・表示します。データは GitHub リポジトリで無料公開されており、173件のデータセット（大気・海洋・陸域・雪氷・農業・社会経済）を認証不要で探索できます。
eodashboard_collections: テーマ（atmosphere/oceans/agriculture/cryosphere等）・機関（NASA/ESA/JAXA）・キーワードで検索
eodashboard_detail: 1データセットの詳細（衛星・センサー・説明・参照リンク・サムネイル画像）を返し、画像をインライン表示
Q: NASAの大気データを教えて
A: eodashboard_collections(agency="NASA", themes="atmosphere")
Q: 海氷のデータセットは?
A: eodashboard_collections(keyword="sea ice")
Q: NO2データセットの詳細と画像を見せて
A: eodashboard_detail("N1_NO2") → 詳細+サムネイル画像時系列データ（Sentinel Hub統計API）は別途キーが必要ですが、メタデータ・説明・画像・参照リンクの取得はすべて認証不要です。検索・概要・学習用途に最適です。
出典: github.com/ESA-eodashboards/eodashboard-catalog ／ github.com/eurodatacube/eodash-assets
space_weather — 宇宙天気（NASA DONKI／予報は NOAA SWPC）NASA DONKI（Database Of Notifications, Knowledge, Information）から、太陽活動に伴う宇宙環境の乱れを取得します。天体観測（オーロラ・電波）や通信・衛星運用への影響評価に使えます。
kind で取得対象を選択: all（既定）/ flare（太陽フレア）/ cme（コロナ質量放出）/ gst（地磁気嵐）/ sep（太陽粒子現象）/ forecast（予報: フレア発生確率 C/M/X・活動領域別確率・NOAA 3日予報）
期間は start_date / end_date（YYYY-MM-DD）で指定。CME はこの2つが必須で、省略時は直近30日を自動補完します（実測: 移転先で無指定は 400 Bad Request。FLR/GST/SEP は省略可）
認証: 不要。2026-09-30 に DONKI の URL が移転し（旧 api.nasa.gov/DONKI は 301 で CCMC のお知らせページへ転送される）、新エンドポイント ccmc.gsfc.nasa.gov/DONKI-API/get は API キーを受け付けません（実測 X-Rate-Limit-Remaining: 9999）。NASA_API_KEY は apod / neo_today のみで使用し、DONKI は nasa_budget を通しません（キーを持たないホストへキーを渡さない）
フォールバック: DONKI が障害・URL 変更・JSON でない応答のときは、認証不要の NOAA SWPC（services.swpc.noaa.gov）へ自動で切り替えます。Kp・NOAAスケール（R/S/G の現在値と1〜3日予測）・GOES X線クラス・フレアイベント（直近7日・発生時刻と級の内訳）・太陽風（速度／密度／Bt／Bz）・陽子フラックス・警報・黒点相対数を返し、どちらの出典で答えたかを content と structuredContent.source（NOAA SWPC ＋ fallback: true ＋ DONKI 側の理由 nasa_reason）に明記します。SWPC 側でも取得できなかった項目は failed に残します
転送・非 JSON の検知: 301/302 を追跡した場合と JSON でない応答は明示的に検知し、「URL が転送されました（転送先）」／「JSON を返しませんでした（HTTP コード・バイト数・Content-Type）」と分かる文言で失敗させます。追跡先の HTML を r.json() に渡すと Expecting value: line 1 column 1 (char 0) という原因不明の文言になり、実測で「NASA API の一時的障害」と誤診しました
キャッシュ: カテゴリ単位なので、kind を変えた呼び出しで同じカテゴリを取り直しません（実測: all の直後の flare は HTTP 0回）。DEMO_KEY の共有枠は消費しません
予報（kind="forecast"）: DONKI は予報を持たない（予報は SWPC のプロダクト）ため、SWPC を通常経路として使います（障害時のフォールバックとは別物）。C/M/X 級と 10MeV 陽子の1〜3日の発生確率、活動領域（黒点群）ごとの確率（面積＝太陽半球の百万分率・黒点型・磁場型つき。最新の観測日のみ）、NOAA 3日予報（予想最大 Kp と NOAA スケール、S1以上・R1-R2・R3以上の確率、公式の根拠文）を返します。limit は活動領域の表示数（既定 10・最大 20）、30分キャッシュ（TTL_FORECAST）。予報テキストは折り返しを繋いで1文にし、欠測は failed に残します（1項目も取れなければエラー。空を「静穏」と誤読させない）
Q: 最近の太陽フレアは?
A: space_weather(kind="flare")
Q: 地磁気嵐が起きているか確認
A: space_weather(kind="gst", start_date="2026-08-01")
Q: 宇宙天気の全体状況
A: space_weather() → フレア・CME・地磁気嵐・粒子現象をまとめて表示
Q: 今後の太陽フレアは?
A: space_weather(kind="forecast") → 発生確率（C/M/X・1〜3日）・活動領域別確率・NOAA 3日予報出典: ccmc.gsfc.nasa.gov/DONKI-API（NASA CCMC / M2M-SWAO）／予報（kind="forecast"）: services.swpc.noaa.gov（NOAA SWPC）
fireball_reports / neo_close_approach / impact_risk — 天体異常系（JPL CNEOS）NASA/JPL CNEOS（Center for Near Earth Object Studies）の公開 API （ssd-api.jpl.nasa.gov）から、火球・小惑星等の接近・将来の衝突リスクを取得します。**3ツールとも認証不要（APIキー不要）**で、DEMO_KEY（30 req/h/IP の共有枠）を消費しません。
fireball_reports — 火球（fireball）は大気圏に突入して光った現象の観測記録です（米国政府センサ・地上観測の報告）。days（1〜1825）・min_impact_energy_kt（kt TNT 換算の下限）・limit（1〜50）・require_location（位置が報告された記録のみ）を指定できます。火球のゼロ件は data キー自体が返らない（count: 0 のみ）ため、その場合も「該当なし」として扱います。隕石の回収・落下物の推定はしません（落下物の情報が欲しい場合は別の情報源が必要です）。
neo_close_approach — days（1〜365）・max_distance_au（既定 0.05 ≒ 19.5 月距離。1 LD ≒ 0.00256 au）・limit・hazardous_only（PHA のみ）。距離は au / km / 月距離(LD) の3通りで併記します。直径は既知の値があればそれを、無ければ絶対等級 H とアルベド 0.14 の仮定から換算した推定値で、推定の場合はその旨を表示と structuredContent（diameter_is_estimate）に残します。接近時刻は TDB（力学時）で、t_sigma_f（3σ の不確かさ）も返します。neo_today との違いは「今日だけ・api.nasa.gov のキー枠」ではなく、任意の期間・距離を扱えることです。
カレンダーへの反映（v0.34.0） — neo_close_approach / fireball_reports を呼ぶと、返した行がそのまま蓄積ストア（%LOCALAPPDATA%\space-finder-mcp\calendar_store.json）の neo / fireball レコードになり、後日 space_calendar / calendar_events に表示されます（structuredContent.calendar_stored に件数、content にも「◯件を反映しました」と出ます。書けなかった場合はその旨を出し、例外にはしません）。接近は日付セルに置ける（時刻が確定した計算値。蓄積時に TDB である旨を併記）一方、火球は過去の観測記録として置き、落下地点ではない旨を併記します。impact_risk は日付が無い（数十年〜百年の幅の確率）ため蓄積しません。保持期限は既存の規則どおり 45日（古い API 由来レコードは prune。ユーザー予定は対象外）。
impact_risk — Sentry の衝突確率の推算です（進路が確定した衝突予報ではありません）。min_probability（既定 1e-3 = 0.1%）以上の天体を確率の高い順に返し、designation を指定すると1天体の詳細（累積確率・想定時期・仮想衝突(VI)・観測弧・パレルモスケール）を返します。designation は仮符号または番号（例 "2024 YR4" / "2000 SG344" / "99942"）で、和名・愛称は JPL 側が受け付けません（推測せず指定方法を案内します）。確率が 0 になった天体は Sentry から削除され、HTTP 200 + error で返るため、それを検査して「リスクなし（監視対象から外れた）」を意味しうる旨を案内します。
数値の読み方 — 衝突エネルギーは広島型原爆（約15kt）との比、距離は月距離、直径は推定であるかどうかを必ず併記します（数値から生成し、書き手によって変わらないようにしています）。
Q: 最近の火球は? A: fireball_reports(days=30)
Q: 大きな火球だけ A: fireball_reports(days=365, min_impact_energy_kt=1)
Q: 今週接近する小惑星 A: neo_close_approach(days=7)
Q: 月距離以内に来る天体 A: neo_close_approach(days=30, max_distance_au=0.0026)
Q: 危険な小惑星は? A: impact_risk()
Q: 2024 YR4 の衝突リスク A: impact_risk(designation="2024 YR4")出典: NASA/JPL CNEOS（ssd-api.jpl.nasa.gov）/ Fireball Data API・SBDB Close-Approach Data API・Sentry
stac_collections / stac_search — AWS Earth Search STACAWS Earth Search（STAC規格の衛星データカタログ）で、Sentinel-2 / Landsat 8/9 / NAIP / Copernicus DEM を認証不要で検索します。
stac_collections: 利用可能な9コレクション一覧
stac_search: コレクション・場所（bbox/地名）・日時・雲量上限で検索。structuredContent に実際のデータURL（COG等）を含む
Q: 東京のLandsat画像を探して
A: stac_search("landsat-c2-l2", place="東京")
Q: 関東の雲が少ないSentinel-2画像
A: stac_search("sentinel-2-l2a", bbox="139.6,35.5,139.9,35.8", max_cloud_cover=20)
Q: 利用できる衛星データを一覧
A: stac_collections()Copernicus Data Space（
copernicus_search）が全Sentinelを扱うのに対し、こちらはLandsatやNAIPも検索可能。雲量フィルタは STAC のqueryパラメータを使用します（Earth Search はfilter非対応）。
出典: earth-search.aws.element84.com
iss_now — ISS 現在位置（Googleマップ表示）Open Notify の iss-now.json から、ISS（国際宇宙ステーション）の現在位置（緯度経度）を取得し、Googleマップリンクで表示します。
Q: ISSは今どこを飛んでる?
A: iss_now() → 現在の緯度経度 + Googleマップリンク高度約420km・速度約27,700 km/h・地球1周約90分
structuredContent に緯度経度・タイムスタンプ・GoogleマップURLを返す
認証不要
出典: api.open-notify.org（Open Notify）。HTTP のみ対応（HTTPS では応答しない）。
satellite_status — WMO OSCAR（世界気象機関）衛星カタログWMO OSCAR/Space（世界気象機関の公式カタログ）から、気象・地球観測衛星の運用ステータス・軌道・打ち上げ日を取得します。認証不要で 1041衛星 を収録。
Q: ロシアの気象衛星（Meteor-M）の運用状況は?
A: satellite_status(query="Meteor-M", agency="Roscosmos")
Q: 世界の気象衛星一覧
A: satellite_status()query: 衛星名（meteor, resurs, goes, kanopus, himawari 等）。一致度順に並べ替えて返します — acronym の完全/前方一致を最優先し、名称は語境界で照合、名称の途中に含まれるだけの一致（例: "meteor" が "Meteorological" に含まれる DMSP/COSMIC）は低順位に置き、件数を分けて表示します（以前は 92件の誤ヒットに Meteor-M が埋もれていました）
カタログ全件（約1,044件・35ページ）を走査します。1ページ30件固定の API なので初回は40秒ほどかかりますが、取得結果をディスクにも保存するため以後はプロセスを再起動しても即時です（24時間で更新）。取得できなかったページがある場合は structuredContent.failed_pages と本文に明示します（欠けを黙って捨てません）
agency: 機関名（Roscosmos, NOAA, EUMETSAT, JAXA 等）
運用中🟢 / 計画中🔵 / 延長🟡 / 退役🔴 を色付きで表示
Roscosmos の気象衛星（Meteor-M・Resurs-P・Kanopus等）も詳細に収録
実装メモ: OSCAR API の
search/space_agency/statusパラメータは現在機能しません（常に全件を返す）。そのため全件をページング取得し、クライアントサイドでフィルタしています。
出典: space.oscar.wmo.int（WMO OSCAR/Space）
alma_search — ALMA 電波観測データ検索ALMA（アタカマ大型ミリ波サブミリ波干渉計）の科学アーカイブを、NAOJ が運用する東アジア鏡の IVOA TAP 経由で検索。object_name（例 M100, HL Tau）か ra/dec+radius、受信 band（1〜10）、product_type（cube/image/visibility/all）、public_only で絞り込む。mm/サブmm の電波観測のため低温ガス・塵や惑星系形成領域が対象。
天体名は表記ゆれを自動吸収（HL Tau→HL_Tau/HLTau 等）。0件のときはアーカイブ内の候補名を提示して停止（推測しない）。
返る情報: 観測対象・座標・周波数帯・データ種別（cube/image）・空間分解能（″）・露出時間・可視降水量 pwv・QA2 合否・公開/要権限・プロポーザルID・PI名・関連論文。
with_products=True で datalink を引いて実データ製品（校正済み tar・生データ ASDM・README・パイプライン製品）をアイコン付きリンクで列挙（先頭3件）。
メタデータ検索は認証不要。
data_rights=Publicの FITS は ALMA アーカイブから取得可（Restrictedは元プロポーザル権限者のみ）。
{"observatory": "ALMA", "count": 8, "public": 8, "restricted": 0,
"records": [{"target_name": "M100", "band": "3", "frequency_ghz": "100–104 GHz",
"data_rights": "Public", "proposal_id": "2011.0.00004.SV", ...}]}radio_sources_now — TART 電波望遠鏡の可視電波源オープンソースで開発公開されている教育用電波干渉計 TART（NZ）の可視電波源カタログから、指定した観測地（lat/lon）で地平線より上にある電波源を取得。返るのは主に GNSS・放送・静止通信衛星で、name・仰角el・方位角az・距離・フラックス密度jy を持つ。電波天文・衛星追尾の学習に最適。
lat/lon省略時は TART 本体のある NZ（ダニーデン）基準。可視性（強度）API は 2026-09 時点で応答停止のため未使用。
{"observatory": "TART", "count": 15,
"sources": [{"name": "GSAT0232 (GALILEO 32)", "elevation_deg": 77.9,
"azimuth_deg": 63.1, "range_km": 23342, "flux_density_jy": 1500000}, ...]}sky_map_with_satellites — 地上から見上げた星空＋人工衛星（描画エンジン選択式）指定した観測地・時刻の空を地上から見上げた画像で返す。天体位置は JPL de421 + Skyfield、恒星は Hipparcos 実星表（Vmag<8.5・約6.1万星）、衛星位置は CelesTrak TLE + SGP4 で実測計算（全てローカル/認証不要）。
engine で描画を選択:
"ground"（既定）: 地上視点の正距円筒パノラマ。地平線が下・方位が横軸で、下部に街並み（手続き生成）と方位目盛り、左右端にその端の方位を表示。恒星は実星表の位置・等級・色（B-V）・大気減光を反映し、天の川は銀経・銀緯から面輝度を描きます。太陽高度で空の色と見える限界等級が変わる（昼/朝焼け/夕方/薄明/夜）ので、同じ呼び出しでも時刻で見え方が変わります。今は見えない惑星・主要恒星・銀河は○の輪郭で位置だけを示し（昼でも位置が分かる）、見えている天体は ● で実物に近い色＋リング、月は位相（照度）と距離を反映して明るい側が太陽を向きます。人工衛星は赤いマーカー＋名札、低軌道は前後60分・1分刻みの可視区間を破線で表示（可視区間が飛んでいる場合は破線を分けて描きます）。視野（span/az0）の外にある天体は描かず、本文に「地平線上だがこの視野の外」として列挙します（図に無いものを「見えている」と書かないため）。JPEG。
span（横方向の視野 30〜360°, 既定 360）/ az0（左端の方位, 既定 0）で切り出しを指定（例: span=180, az0=225 で南西→北東）。
lp（"city" 都心 / "suburb" 郊外=既定 / "dark" 山間・離島）で光害の程度＝限界等級・天の川の見え方・空の明るさを切り替え。未対応の値は既定（郊外）に落ちて、本文にその旨を明示します。
show（カンマ区切り, 例 "木星,ベガ,M31"）で依頼表示する天体を指定。指定した天体だけが ●/○ のマーカーと名札を持ち、他は通常の星として描かれます。
"simple" / "accurate": 従来の天頂中心の円形図（simple=Pillow による実写背景の簡易合成・JPEG / accurate=matplotlib 極座標の正確な星図・PNG）。マーカーの配色・光背・土星の環・木星の縞・火星の極冠・名札・凡例は共通パレット img_common.BODY_COLORS / SYMBOL_COLORS の 1 か所から生成します（凡例も実際に描いたものだけを色コード付きで表示）。
画像は content に base64 でインライン表示（ground/simple=JPEG / accurate=PNG）、座標一覧は structuredContent に JSON。JPEG は PNG 比で約1/5の転送量です。
{"time_utc": "...", "engine": "ground (Pillow, 地上視点パノラマ)", "phase": "夜",
"star_catalog": {"source": "Hipparcos 実星表（Vmag<8.5）", "stars": 61221, "drawn": 2952},
"planets": {"月": {"az":..,"alt":..,"visible":true,"illum":0.58}, ...},
"satellites": {"ISS (国際宇宙ステーション)": {"az":..,"alt":..,"trail":[...]}, ...}}実星表は初回だけ VizieR（CDS）から取得して %LOCALAPPDATA%\Temp\space_finder_mcp\stars_hip85.csv にキャッシュします（de421.bsp と同じ扱い）。取得できない環境では名のある明るい恒星のみで描画を続け、structuredContent.star_catalog.source に実際に使った出典を出します（偽らない）。
solar_system_now — 太陽系俯瞰図（太陽中心の惑星・小惑星・探査機・彗星位置）「太陽系を上から見た図」「今の惑星の位置」「イトカワの今の位置を図で」「ベンヌの楕円軌道を表示して」などに応答。太陽を中心とした黄道面俯瞰図を画像化し、惑星(8惑星＋冥王星)は JPL DE421 暦表 + Skyfield で日心黄道座標を計算。任意の小惑星は JPL SBDB API の軌道要素を取得しケプラー2体問題で日心位置へ伝播する（asteroid/asteroid2 で複数指定可）。
距離が 0.4〜40 AU と2桁超のため、Pillow版(既定)は対数縮尺で全天体を一枚に表示。惑星を実物色アイコン＋距離ラベル、小惑星を緑の十字マーカー＋緑軌道リングで強調。惑星軌道円・小惑星帯(2.0-3.4AU目安)も併記。学生・観賞向けに視認性優先。
engine="accurate" で matplotlib 版（線形距離の正確な相対距離俯瞰図）も選択可。科学的な相対距離比較用途向け。
惑星・太陽・小惑星・彗星の色は img_common.BODY_COLORS / SYMBOL_COLORS の共通パレット（sky_map_with_satellites と同一の値）を両エンジンで共有します。
一部の惑星の位置を計算できなかった場合は、その旨（失敗数）を content と figure.notes に出し、structuredContent.planet_errors に天体名と理由を記録します（黙って欠落させません）。
対応小惑星エイリアス: イトカワ(itokawa/25143)・ベンヌ(101955)・アポフィス(99942)・リュウグウ(162173)・ツタティス(4179)・エロス(433)。SBDBのsstr（番号・名前）なら任意の小惑星を指定可能。認証不要。
遠方探査機: probe/probe2 引数に ボイジャー1号/2号・パイオニア10号/11号・ニュー・ホライズンズ・はやぶさ2（日英名対応）を指定。JPL Horizons 状態ベクトル（ECLIPTIC, 太陽中心）から日心位置を取得。ボイジャー等は黄緯が大きい（~35°）ため、黄道面への正射影距離で描画し、ラベルに真距離と黄緯を併記。表示スケールは探査機の距離まで自動拡張し、色付き菱形マーカー＋太陽からの補助線で強調。遠方のため線形 matplotlib 版は使わず Pillow（対数縮尺）で表示。認証不要。
「1光日」を図に重ねる（probe 指定時）: 光が24時間で進む距離＝173.1446 AU＝25,902,068,371 km を破線の円で描きます（探査機を描く図では表示範囲を1光日まで自動で広げます）。1光日に達していない探査機では、その探査機の黄道面投影での1光日リングと到達時の方向（◇＝黄経/黄緯）・到達予測日も出します。俯瞰図は黄道面への正射影なので真距離の円と投影の円は別物で、その旨と両者の半径を数値付きで figure.notes に出します（実測: 黄緯 35.2° のボイジャー1号は真距離 173.14 AU に対し投影 141.6 AU＝別の円。黄緯 3.0° のパイオニア10号は 172.9 AU で図上ほぼ重なるため「見分けられない」旨を注記）。structuredContent.probes[] に light_days（何光日）・light_hours（光の所要時間）・to_light_day_au（1光日までの残り）・light_day_eta_date / light_day_eta_method（到達予測＝現在の日心視線速度による線形外挿）が入ります（実測: ボイジャー1号 0.9925 光日・残り 1.30 AU・2027-02-03＝JPL Horizons の n 体解で厳密に解いた日付と一致）。距離の基準は日心距離（真距離）に統一しています（地心距離での1光日は地球の公転で最大 ±1 AU 変わり、日付が違うため）。1光日が表示範囲の外（例: range_au=10）なら描かず、理由を注記と structuredContent.light_day.ring_why に出します。リングの破線・ラベル文字・探査機マーカーの画素を測り直して figure.verify.light_day に残します（ラベルがマーカーを覆っていれば ok=false）。
彗星の軌道面ビュー（view="comet_orbit"）: 単体なら comet と併せて指定すると、その彗星の軌道を彗星自身の軌道面を真横から見た図で返します。太陽は円錐曲線の焦点（楕円の中心ではない）に置き、近日点・遠日点・現在位置・日心距離目盛(AU)を描画します。e≥1 の C/彗星（例: 紫金山・アトラス＝SBDB の a が負）は閉じない双曲線の枝として近日点から有限距離までを描きます（楕円として描くと a(1+e) が負になり破綻するため）。ハレー彗星（e=0.968・逆行 i=162°）のような極端な楕円でも、焦点と中心のズレ a·e が図と figure.notes の両方に出ます。
小惑星の楕円軌道ビュー（view="asteroid_orbit"）: solar_system_now(asteroid="ベンヌ", view="asteroid_orbit") のように指定すると、JPL SBDB の楕円軌道全体をその軌道面から真横に見た画像を返します。太陽を焦点に置き、近日点・遠日点・指定時刻の現在位置・1 AU目盛を描画。図の線は SBDB の osculating elements によるケプラー二体軌道で、惑星の摂動を含む将来予報ではありません。asteroid / asteroid2 で複数指定した場合、このビューは1天体ずつ呼び出してください。figure.conic / figure.verify に楕円要素と画素検証を含みます。認証不要。
表示範囲を絞って内側を拡大する（range_au）: 数値（AU）でも天体名でも指定できます（range_au="火星" → 1.65 AU／"木星まで" → 5.62 AU／"saturn" → 10.35 AU／"小惑星帯"／"内惑星"／"外惑星"。決め方は figure.notes と structuredContent.range_resolved に「木星の軌道（長半径 5.20 AU × 1.08 = 5.62 AU）」の形で出ます）。range_au="fit" はその呼び出しで指定した天体（小惑星・彗星・探査機・経路）が全部入る範囲を自動で選びます（最大値×1.10、下限 1.2 AU。例: asteroid="イトカワ", range_au="fit" → 1.52 AU）。解決できない名前は推測せず候補一覧つきでエラーを返します（range_targets）。solar_system_now(range_au=10) で太陽から 10 AU まで＝土星より内側だけを表示します。線形版（engine="accurate"）は縮尺が固定（実測 約12 px/AU）で、既定の ±45 AU では内惑星が太陽マーカー（半径 1.7 AU 相当）と重なって潰れていました。range_au を指定すると lim を固定し、px/AU が約4.5倍（10 AU なら 約51 px/AU）になり、太陽マーカーの誇張半径も 0.4 AU まで下がって水星〜土星が読める大きさになります（実測値は figure.scale.px_per_AU）。範囲外の天体は描かず、「表示範囲10 AU の外にあるため描いていない: 天王星 19.44 AU、海王星 29.88 AU…」のようにfigure.notes と structuredContent.out_of_range へ数値付きで列挙します（黙って消しません）。経路が範囲外へ出る彗星は対数版へ自動で落とし、その旨と範囲外の目印も注記します。
彗星の通過経路を俯瞰図に重ねる（route=True）: solar_system_now(comet="エンケ彗星", route=True) で、太陽系俯瞰図にその彗星の軌道（通過経路）を破線で重ねます（黄道面への正射影）。近日点・遠日点には◇と日付を添え、本文と figure.notes にも SBDB 軌道要素から数値で出します（近日点の日付は SBDB の2体近似に加えて JPL Horizons の n 体解も併記し、両者の差を日数で注記します。SBDB の要素は古いエポックの接触軌道なので、摂動の大きい彗星では2体近似が数か月ずれます＝実測: ハレー彗星 163.8日・67P 82.6日・エンケ彗星 0.8日。n 体解を取得できないときは取得できなかった旨と理由を注記し、2体近似だけを黙って出すことはしません）。対数縮尺の simple（既定）では線の長さと曲率は実際の楕円と一致しません（注記に自動生成。形そのものは view="comet_orbit"）。engine="accurate"（線形±45 AU）は経路が枠に収まる彗星なら自動で維持され、形が本当の軌道になります（収まらないときは対数版へ自動で落とします）。近日点が誇張した太陽の描画円盤の内側に来る彗星では目印を描かず、「この縮尺では図から位置を確認できない（数値は 0.339 AU）」を注記に数値から生成します。認証不要。
彗星の見え方チャート（view="apparition"）: comet と併せて指定すると、その彗星の観測の可否を時系列で示す3段パネル（横軸＝UTC の日付）を返します。上から 距離（日心距離 r＝黄／地心距離 Δ＝シアン、AU）・予想光度 m1（橙。JPL SBDB の全光度の式 m1 = M1 + 5·log10(Δ) + K1·log10(r)。値が小さい＝明るい方が上）・太陽離角（緑。0°＝太陽と同じ方向＝地球からは見えない）。今日・近日点・地球最接近を縦線で示し、期間内の極値は数値ラベル付きの点で示します（曲線や線に重なる位置にはラベルを描かず、描けなかったラベルは figure.notes に列挙）。位置は JPL Horizons の N 体解（期間ぶんを1リクエストでまとめて取得）、地球位置は JPL DE421+Skyfield。Horizons が使えないときだけ SBDB 要素の2体近似へ退避し、精度差を数値で注記します（実測: 169P/NEAT で N 体解と最大 0.0249 au・地球最接近の時刻が約1.2日ずれる）。期間の端で最小のときは「近日点」「地球最接近」とは呼びません（ハレー彗星は 2061 年まで太陽へ近づき続けるので、どの期間でも最小は端に来る）＝「期間の端で最小＝真の極値はこの期間の外」と数値付きで注記し、マーカーも「r 最小」「Δ 最小」に切り替えます。days（既定180日）で長さを変えられ、今日の30日前から描くので直前に過ぎた近日点・最接近も見えます（1天体ずつ。複数指定は「1天体ずつ指定してください」と返して停止）。
複数彗星を1枚に（1彗星=1パネル）: comet="ハレー彗星,C/2004 R2" のようにカンマ区切り（、/; も可）または comet2 を併用すると、最大4天体を縦に並べた1枚の画像で返します。彗星ごとに軌道面も縮尺も違うため、1つの座標系に重ねると嘘になる（＝軌道面が違えば「真横から見た形」は同時に成立せず、a が2桁違うと小さい軌道が点に潰れる）ので、パネルは独立した軌道面・独立した縮尺です。その旨（同じ長さの線でも距離が一致しないこと）と a の開き（例: 229倍）は figure.notes に数値から生成して入ります。1天体の取得に失敗しても他のパネルは描き、structuredContent.errors と注記に理由を残します（上限4件を超える要求も「要求N件のうちM件を描画」と明示）。figure.kind は orbit_plane_set で、パネルごとの円錐曲線・自己検証は figure.panels[]（conic / verify / px_per_AU / notes）、figure.verify は全パネルの集約です。
彗星（周期・C/）: comet/comet2 引数に ハレー彗星(halley/1P)・エンケ彗星(2P)・チュリュモフ・ゲラシメンコ(67P)・テンペル第1(9P)・ヴィルト第2(81P) 等の周期彗星、または 紫金山・アトラス(C/2023 A3)・ラブジョイ(C/2014 Q2) 等のC/彗星を指定。周期彗星は JPL SBDB 軌道要素のケプラー伝播、C/彗星（非周期・放物線/双曲線軌道）は JPL Horizons 状態ベクトルで 日心位置を計算。彗星はシアン色の輝く核＋太陽と反対方向に伸びる尾で描画し、黄緯が大きいものは 黄道面への正射影距離で配置・ラベルに真距離と黄緯を併記。遠方彗星は表示スケールを自動拡張。認証不要。
// route=True のときは彗星の通過経路（点列は入れず、目印と要素だけ）が付く
// "comet_routes": {"エンケ彗星": {"name": "2P/Encke", "e": 0.8470, "q_au": 0.3395,
// "period_days": 1207.0, "closed": true, "marks": [{"id": "perihelion", "label": "近日点",
// "r_au": 0.3395, "proj_au": 0.3393, "date": "2027-02-11", "px": [736, 755], "drawn": false}]}}
{"time_utc": "2026-09-09 05:32 UTC", "engine": "simple (Pillow, 対数縮尺)",
"asteroids": {"イトカワ": {"au": 1.60, "eclLon": 82.9}},
"probes": {"ボイジャー1号": {"au": 171.7, "proj_au": 140.4, "eclLat": 35.2}},
"comets": {"ハレー彗星": {"au": 35.1, "proj_au": 33.7, "eclLat": -16.6}}} // 惑星は全9天体// view="apparition" の応答例（169P/NEAT・120日＋直前60日）。Δ の最小値は JPL の公表値と一致
{"comet": "169P/NEAT", "positions_source": "horizons",
"window": {"from": "2026-07-24", "to": "2027-01-19", "days": 120, "days_before": 60, "samples": 437},
"features": {"closest_approach": {"utc": "2026-08-11 19:19", "delta_au": 0.167172, "inside_window": true},
"perihelion": {"utc": "2026-09-21 09:16", "r_au": 0.604348, "inside_window": true},
"brightest": {"utc": "2026-08-14 04:21", "mag": 13.6},
"next_close_approach": {"utc": "2026-09-17", "delta_au": 0.5634}},
"verify": {"ok": true, "label_overlap_px": 0, "worst_px_error": 0.0,
"marker_pixels": {"今日": 367, "近日点 09/21": 391, "地球最接近 08/11": 366}}}{"comet": "1P/Halley", "e": 0.967936, "q_au": 0.5749, "typ": "sbdb",
"figure": {"schema": "figure/1", "kind": "orbit_plane",
"primary": {"name": "太陽", "at": "focus", "center_offset_AU": 17.3537},
"conic": {"kind": "ellipse", "e": 0.967936, "q": 0.5748638313743413,
"apo": 35.282406265764116, "c": 17.35377121719489},
"verify": {"periapsis_error_pct": 7.13, "apoapsis_error_pct": 0.04,
"periapsis_check": "equality", "label_overlap_px": 0, "ok": true}}}
// view="comet_orbit" の応答例。超長距離の桁（C/2004 R2, a=4.1e3 AU）では
// {"periapsis_resolvable": false, "periapsis_check": "upper_bound", "periapsis_upper_bound": 4.0, "ok": true}solar_eclipse_series — 日食の時系列パネル（太陽が月に欠ける過程）「2035年9月2日の皆既日食を画像で」「東京で見える次の日食」「2019年の部分日食の進行」などに応答。指定した観測地・日付で、太陽と月の見かけの重なりを JPL DE421 + Skyfield で実測計算し、食の始まり〜最大〜終わりを7枚のパネルに並べて合成。サンプル画像（部分日食の時系列）と同じレイアウト。
太陽・月の視角半径と角距離を観測地の視位置(topocentric apparent)で計算し、**月の位置角(PA)**を反映して正しく欠ける位置に月を描画。パネル上部に▲（天の北）、各パネル下に現地時刻・食分。
最大食分から種別を自動判定：0.995以上は皆既(月視半径≥太陽)／金環(月<太陽)、それ以外は部分。
figure.verify は描いた画素から測り直した食分を各パネルで報告値と突き合わせます（PA軸の明部長 L から 食分 = 1 − L/2R）。実測誤差は 0.004 以内、パネル欠けやはみ出しはここで落ちます。
date 省略時は**「これから起こる次の日食」を約4年（1400日）先まで自動検索**（Skyfield almanac で新月を列挙し、食のありうる新月だけ高速絞り込み → 精密計算）。例: 東京の次に見える食は 2030-06-01 部分日食（食分0.80・太陽高度+19°） で、既定の引数だけでこれが返ります（800日＝約2年では可視の食が無く、常に「見つかりません」しか返せませんでした）。走査は「30分刻みで食の時間帯を特定 → その窓内だけ2分刻みで精密化」の2段構えで、初回は約28秒（同じ観測地・同じ日なら1日キャッシュで以後は即時）です。
見えない食は返しません — 描くのはその観測地で太陽が地平線より上にある時間帯だけで、最大食分も可視区間の中で求めます。日食が現地の日付をまたぐ場合（例: 23:25 開始 → 翌 00:37 終了）も前後6時間まで含めて計算します。全日食が地平線下なら「太陽が地平線下（最大高度 −67°）のため見えません」と明示します（例: 東京2028-01-26）。
max_magnitude=True で最大食のみの単一画像を返す。place/lat/lon で世界中の任意の観測地を指定可能（東京・ベルリン・ケープタウン・グリニッジ天文台・昭和基地 等。Open-Meteo + Nominatim で自動解決）。日食の現地時刻はその場所のタイムゾーン（DST込み）で表示。認証不要。
{"kind": "部分日食", "max_magnitude": 0.63, "date": "2028年1月26日",
"place": "東京", "lat": 35.68, "lon": 139.69} // 7パネル時系列画像を content に返すmoon_phase_map — 月齢マップ（月の満ち欠けの格子／朔望月パネル）「今月の月齢マップを見せて」「2026年9月の月相カレンダー」「次の朔望月の満ち欠けを画像で」などに応答。日食の時系列パネルと同じ幾何計算（JPL DE421 + Skyfield・認証不要）を使い、観測地から見た太陽と月の実位置から輝面の向き（位置角 PA）と照度を求めて月円盤を正しい向きに欠けさせます（月齢から向きを決め打ちしません）。
layout="calendar"（既定）— 指定した月を日月火水木金土の格子に並べ、各日に月齢・照度・月相（新月／三日月／上弦／十三夜／満月／下弦／有明月 etc）を描きます。朔・望・上弦・下弦が起きる日はイベント名と現地時刻を強調表示。
layout="lunation" — 1朔望月（朔→朔）を等間隔の時系列パネル（days で3〜12枚・既定8枚）に並べ、各パネルに日時・月齢・照度・月相・輝面の位置角を出します。
月齢=直前の朔（新月）からの経過日数、照度=円盤の輝面の割合（満月=100%）。カレンダーは各日現地正午時点、パネルは各パネルの現地時刻時点の値です。
figure.verify は描いた画素から明暗境界線の位置を測り直し、申告した照度と突き合わせます（照度 k の円盤は位置角軸上で縁から 2kR の幅が明るい）。走査軸が申告した位置角なので、満ち欠けの向きが違えば一致しません（実測誤差 0.02 以内）。
図と数値の食い違いを注記で明示 — 「円盤は模式図（実写ではなく月の海は乱数）」「天の北を上・東を左に置いた見え方で地平線からの見え方ではない」「朔・望の日は正午時点では前後になる（例: 9/11 は正午時点の月齢 29.4・新月の時刻は 12:26）」等を数値から生成します（figure.notes は要約せず引用してください）。
date（"2026-09" / "2026年9月16日"）と place/lat/lon で観測地・期間を指定。日付・時刻・曜日は現地時間（緯度経度から取得した UTC オフセット）で表示します。
{"layout": "calendar", "period": {"month": "2026-09", "days": 30},
"days": [{"date": "2026-09-11", "moon_age": 29.39, "illum_pct": 0, "phase_ja": "新月（正午時点の月齢 29.4）",
"bright_limb_pa_deg": 31.1, "events": ["新月"]}, "..."],
"events": [{"phase": "新月", "datetime_local": "2026-09-11 12:26"}, "..."],
"figure": {"kind": "moon_phase_calendar", "verify": {"ok": true, "worst_error": 0.0121}}}planetary_orbiter_track — 汎用・天体周回機マップ月・火星・水星・タイタン・ベスタ・ケレス等、NASA Trek が等角図法グローバル画像を持つ任意の天体を周回する探査機の現在位置と軌道トレイルを画像化します。JPL Horizons の状態ベクトルを IAU 自転モデルで天体固定座標（緯度経度・高度）に変換して正確に計算。認証不要。
対応天体（BODIES テーブル）: moon（LRO・ゲートウェイ）、mars（MRO・Mars Odyssey）等。新規天体は「中心天体ID・IAU回転定数・TrekタイルURL・半径」を1行追加するだけで対応可能。
span_deg=360 で天体全面表示（2:1グローバルビュー）、既定 120 で現在位置中心の局所表示。
高精度トレイル: step を秒単位（1/60分）まで細分化可能。JPL Horizons の TLIST を POST + 分割バッチで送るため、1400点超のトレイルも高速取得。
トレイルの一部が失敗した場合: 計算できなかった点数を content と figure.notes に出し、structuredContent.trail_errors に offset_min と理由を記録します（図に無い点を「無い」と誤読させないため）。
運用終了機（かぐや・MAVEN・あかつき等）は推測せず丁寧に案内（かぐやは JAXA 公表の落点＝南緯65.5°／東経80.4° Gill クレータ付近を出典つきで返す）。和名・英名・別名（かぐや/kaguya/selene）は同じ案内に着地。
着陸地点マップ（figure.kind="landing_site_map"）: sites="apollo" でアポロ6地点を天体全面図に番号付きマーカー＋凡例で、sites="apollo11" のように1地点を指定するとその地点中心の局所図で返します。座標は NASA NSSDC が公表した月着陸船(LM)の値（LRO 画像から決定・惑星中心 Mean Earth/Polar Axis、Wagner et al., Icarus 283 (2017)）で、旗そのものの座標は公開表に無いため「マーカーは着陸地点を指す」旨と各地点の旗の状態（下記）を注記に自動生成して入れます。地点マーカーは共通ルーチン surface_map.py の draw_markers / verify_markers（投影の逆変換＋全地点の画素検証）を使います。文字（タイトル・凡例・番号）は地図の外＝下の帯に置き、地図の上に重ねません（重ねるとマーカーが文字で隠れる）。複数地点では地点間の最小間隔からマーカー半径を決め、離隔が足りなければキャンバスを自動拡大します（markers_do_not_overlap を検証）。番号は他のマーカーに載らない位置へ機械配置し、置けなければ省略して注記に残します。
新しくできたクレーター（sites="newcrater"）: 月面で確認された「新しいクレーター」2点を返します。マクゲッチン（自然衝突・2024-04-11〜05-22 に形成、直径 222 m・深さ 43 m、1.3536°N 67.1765°E。LROC が 2025-10-24 に発見、IAU 命名 2026-05-04。この規模の衝突は月で平均 132 年に1回）と、ファルコン9上段の衝突痕（人工物・2026-08-05 06:35 UTC、直径 18 m・深さ 3 m 未満、19.4759°N 266.7138°E＝西経 93.2862°）。個別指定は "mcgetchin" / "falcon9"。figure.kind は impact_site_map で、注記には「記録上いちばん新しいのは人工物の衝突（ファルコン9上段）、自然衝突ではマクゲッチンが最新」を数値から生成し、0〜360°E で公表された経度は -180〜180° に折り返して描いた旨と等価な西経も出します。
地点種別と座標の返却: sites="all" は登録済み地点を種別混在で返すため、表示行ごとに着陸・形成・衝突を区別します。図の kind は着陸地点のみ=landing_site_map、クレーター／衝突地点のみ=impact_site_map、着陸地点と衝突系の混在=site_map です。構造化データの各地点には kind と event が入り、投影用経度は -180〜180° に正規化します（公表値が 266°E の場合は本文と注記に西経換算も併記）。
対応天体（sites= の地点マーカー図）: MAP_BODIES の18天体（月・火星・水星・金星・タイタン・ベスタ・ケレス・イオ・エウロパ・ガニメデ・カリスト・木星・土星・天王星・海王星・冥王星・ベンヌ・リュウグウ）。ベースマップは3種類を天体ごとに自動選択します。地点が登録されていない天体でも sites="map" で全球図そのものを返します。
trek … NASA Trek の全球等角図タイル（層IDを検証済みの5天体: 月・火星・水星・ベスタ・ケレス）
image … 1枚の全球等角図（金星＝USGS/NASA Magellan 合成図、タイタン＝NASA Cassini 全球図、イオ/エウロパ/ガニメデ/カリスト＝USGS/NASA のモザイク、木星・土星・天王星・海王星＝Hubble OPAL の全球図（MAST/STScI 公開・DOI 10.17909/T9G593。その年の大気の模様なので観測日を注記に出す）、冥王星＝New Horizons 全球カラー図、ベンヌ＝OSIRIS-REx 全球モザイク）。2:1 でない画像はアスペクト比を補正して描画（補正率と元の AR を注記に明示）
graticule … 全球等角図が確認できない天体（リュウグウ。USGS の全球モザイク倉庫に該当キー 0 件・NASA Trek のベースマップ層を配る索引サービスは HTTP 500＝実測）は緯度経度グリッド。注記に「地形画像は無い」と明示
全球等角図の経度原点は天体ごとに違うので、image 設定は画像の左端の経度を left_edge_lon で自己申告し、左端が東経 0° の図（USGS/PDS の全球モザイク・Hubble OPAL）は横に半周（180°）回して描きます（回した角度・px・元の px を注記に数値で出す。実測: 冥王星の .lbl は CenterLongitude=180、OPAL の readme は「left edge = 0 System III W」、金星の Magellan 図は左端 -180°＝回転不要）。
実測: NASA Trek に Jupiter は無い（404）。画像が取得できないときは自動でグリッドに落ち、その旨を注記に残します。
sites="map"（地点なし・地図のみ）: 地点マーカーを描かず全球図そのものを返します（イオ・エウロパ・ガニメデ・カリストのように着陸機が無い天体の全球図表示に使用。figure.kind="body_map"）。
地点データの内訳（2026-09 時点）: 月10（アポロ6＋嫦娥3号＋ルノホート1/2＋サーベイヤー3号）／タイタン1（ホイヘンス 10.573°S・192.335°W＝東向き正 167.665°E。旧 ESA 表記の 0〜360°W 慣例を変換）／金星9（ベネラ7・8・9・10・11・12・13・14号＋ベガ2号。出典: Venera 飛行データ表＝NSSDC 準拠。8/9/10号は「半径150km以内」の精度）／火星12（マルス2・3・6号、バイキング1号、パスファインダー、ビーグル2号、スピリット、オポチュニティ、フェニックス、キュリオシティ、インサイト、パーサヴィアランス。出典: The Planetary Society の着陸地点一覧が付す一次出典）／木星23（SL9）。経度は東向き正（−180〜180）に統一し、0〜360°表記や西経の値は自動で折り返します（実測: 金星351°Eをそのまま渡すと画面外に描かれた）。
木星の SL9 衝突地点: planetary_orbiter_track(body="jupiter", sites="all") でシューメーカー・レヴィ第9彗星の衝突地点23破片（1994-07-16〜22）を木星の全球図（Hubble OPAL 2025a・観測 2025-12-11〜12）に描きます。ベースマップは「その年の大気」で 1994 年当時の模様ではなく、衝突痕そのものも写っていない旨を注記に明示します。座標は PDS Atmospheres が公開する Chodas & Yeomans (1996) の表（緯度＝木星中心緯度、経度＝System III の西向き→東向き正に変換、衝突面は 100 mbar 面）。注記に「木星は固体表面が無いガス惑星で、衝突痕は数日〜数週間で大気に流されて消えた」ことを明示します。近すぎて重なる地点（例: 破片 D と S は同じ 33°W）は重ねて描かず、図示しなかった地点として注記と structuredContent に残します。
米国旗の状態（NASA ALSJ「Six Flags on the Moon」＋ LROC 時系列画像）: アポロ11号は倒れている（帰還時の上昇エンジン噴射で倒れた／LROC に旗の影なし）。12号・16号・17号は立っている（LROC 時系列で強い影）。14号・15号は LROC では旗の影が不明瞭（15号は LRV の TV カメラで離陸後も立っていたことを確認）。
落点マップ（figure.kind="impact_site_map"）: 落点が公表されている過去機は、その天体面の地図に地点マーカーを描いた図を返します（かぐや＝月面図）。注記には「公表座標に置いたマーカーであり、衝突でできた新クレータを画像から同定したものではない」旨を数値から生成して入れます。地点マーカーの描画・画素検証は共通ルーチン surface_map.py（draw_marker / verify_marker）を使い、投影の逆変換で座標を再計算＋マーカー色の画素数まで検査します。
planetary_rover_location_map — 汎用・天体面ローバー位置マップ任意の天体面を移動する探査ローバーの現在地・走行経路・着陸地点を、その天体の局所地図に重ねて画像化します。ベースマップ・タイル合成・切り出し・投影・マーカー・画素検証は共通ルーチン surface_map.py を再利用（周回機・ローバー・落点マップで同じ投影・同じ検証）。
走行経路(橙線)・現在地(赤●)・着陸地点(青●)を合成し、ローバーを画像中心に配置。
対応ローバー（ROVERS テーブル）: perseverance（パーサヴィアランス）・curiosity（キュリオシティ）。
正直な制約: ローバー位置データは NASA MMGIS（火星専用）のみ。月面ローバー等の現役位置データは公開されておらず、データ源ができればテーブル追加で対応可能。
外部APIへの呼び出し回数と再計算を抑えるため、データの性質ごとに3層でキャッシュします（cache.py）。
層 | 対象 | 方式 | TTL |
① 不変アセット | Trek 地図タイル / NASA 画像資産 / 星空マップ背景 | ディスク（ | 30日（実質無期限） |
② 揮発データ | RSS・打ち上げ(LL2)・STAC検索・天気・ESO | プロセス内メモリ | 10分 |
宇宙天気(DONKI) — カテゴリ単位（種別を変えても取り直さない） | プロセス内メモリ | 10分 | |
天体観測用天気・メディア検索・ALMA/CADC | プロセス内メモリ | 30分 | |
APOD・NEO・EO Dashboard（日次データ。 | プロセス内メモリ | 1時間 | |
高コスト計算 | 探査機・彗星の Horizons 状態ベクトル（分単位でキー化）／SBDB 軌道要素 | プロセス内メモリ | 24時間（キーが1分ごとに変わる＝実質1分） |
データセット一覧・ジオコーディング・NASA POWER・Wikidata逆引き | プロセス内メモリ | 24時間 | |
③ 高コスト計算 | 日食（次の日食探索＝約28秒／指定日の判定＝約1秒。探索窓は約4年＝1400日） | 緯度経度を丸めたキーでメモリ | 24時間 |
実測効果（1回目 → 2回目）
planetary_orbiter_track(LRO): 4.46s / 73リクエスト → 1.07s / 1リクエスト（タイル72枚を再取得しない）
solar_eclipse_series(東京): 28.4s → 0.7s（探索窓を1400日に拡大しても初回のみ）／ 指定日 0.4〜1.2s → 0.7s
satellite_status: 50.28s → 0.00s ／ astronomy_weather 2.56s → 0.00s
satellite_status（全1,044件の走査）: 初回 38.5s → 以後 0.07s（カタログをディスクにも保存し、プロセス再起動後も即時）
sky_map_with_satellites(simple) の画像: 992KB → 188KB（JPEG化）
search_space_images: インライン画像を3枚 → 1枚（inline_max で増やせる）
設計上の約束
同じ引数の並行呼び出しは1回の実行にまとめます（single-flight）。8並列で投げても実行は1回で、結果は全員に同じものが返ります（共有レート枠を N 倍消費しない）
エラー応答はキャッシュしません（一時的な障害やレート制限(429)が固定化しない）
取得失敗時は期限切れでもディスクの古い内容を返します（stale-if-error）
現在位置系（iss_now / tiangong_now / 各位置計算）はリアルタイム性を優先しキャッシュ対象外です（TLEは従来どおり6時間キャッシュ）
全ツールは CallToolResult を使い、次の2層で応答します。
content — 人間向け表示（テキストサマリ、画像は ImageContent）
structuredContent — LLM向けの純粋JSON（メディアURL・メタデータを構造化）
これにより、ホストLLMが表示テキストを要約しても元データ（URL等）を失わず、正確な情報を保持できます。
変更後は次の検証ゲートを通してください（scripts/check-tools.py は依存追加なしで同梱）。
# 1. 構文チェック
uv run python -m compileall -q src/space_finder_mcp
# 2. 全66ツールを実呼び出し（例外漏れ・structuredContent欠落・タイムアウトを検出。数分）
uv run python scripts/check-tools.py
# 3. ネットワーク全断を注入して「例外が外へ漏れないか」を検査
uv run python scripts/check-tools.py --offline
# 4. 未参照定義・未使用import の走査（0件を維持）
uv run python scripts/check-tools.py --dead-code
# 5. 数値引数へ不正値（"abc" など）を注入して例外漏れを検査
uv run python scripts/check-tools.py --fuzz
# 5a. 並列ツール呼び出し（LLM が同時に複数ツールを投げる前提）を検査
uv run python scripts/check-tools.py --concurrency
# 5a2. 実クライアント経路（stdio）で代表ツールが応答するか検査
uv run python scripts/check-tools.py --stdio
# 5b. 画像/音声/動画を返すツールが「リンク先行」を守っているか検査（0件を維持）
uv run python scripts/check-tools.py --media-links
# 5c. 描画系ツールの figure/1（図の注記・自己検証）を検査
uv run python scripts/check-tools.py --figures
# 6. 変更したツールだけ先に確認 / CI向けJSON出力
uv run python scripts/check-tools.py --only sat_tle,apod
uv run python scripts/check-tools.py --json終了コードは 0=正常 / 1=異常です（例外漏れ・structuredContent 欠落・タイムアウト・デッドコード・figure/1 の検証失敗 --figures・メディアのリンク先行違反 --media-links）。MCPサーバーはホットリロードがないため、src/ を変更したらクライアントを再起動してください。
Claude Code は CLAUDE.md と .claude/rules/、Codex は AGENTS.md、その他のエージェントは SKILL.md を参照します。
# Hermes で接続確認
hermes mcp test space-finder-mcpsrc/space_finder_mcp/
├── __init__.py # main() → mcp.run()
├── __main__.py # python -m space_finder_mcp 用の入口
├── server.py # FastMCP サーバー定義・66ツール登録
├── stac_common.py # STAC系共通の入力検証ヘルパー（bbox/雲量。ツール定義なし）
├── input_utils.py # 引数の防御的数値変換 as_int/as_float（不正値でも例外を漏らさない）
├── img_common.py # 画像合成の共通ヘルパー（フォント探索/JPEG化/アンチメリジアン分割。ツール定義なし）
├── name_common.py # 天体名・衛星名の解決（表記ゆれ/和名→英語/Sesame で名前→座標。ツール定義なし）
├── nasa_budget.py # api.nasa.gov のレート枠管理（投げる前の check/429 の記録/キーの伏せ字化）
├── satellite_map.py # sat_ground_track（衛星の地上軌道マップ, CelesTrak+SGP4+Blue Marble）
├── cache.py # キャッシュ基盤（TTLメモリ/ディスク資産キャッシュ。ツール定義なし）
├── env_config.py # リポジトリ直下 .env の読み込み（標準ライブラリのみ。ツール定義なし）
├── wikidata_lookup.py # reverse_lookup（逆引き歴史Q&A）
├── launch.py # upcoming_launches / china_launches / russia_launches（ロケット打ち上げ・中国・ロシア）
├── nasa.py # apod / neo_today（NASA日次）
├── media.py # search_space_images / audio / videos（メディア検索）
├── isro.py # isro_data（インド ISRO）
├── copernicus.py # copernicus_collections / copernicus_search（欧州 ESA）
├── jaxa.py # jaxa_datasets / jaxa_dataset_search（日本 JAXA）
├── csa.py # csa_dataset_search（カナダ CSA, システムCA検証アダプタ）
├── inpe.py # inpe_collections / inpe_search（ブラジル INPE STAC）
├── dlr.py # dlr_collections / dlr_search（ドイツ DLR EOC STAC）
├── roscosmos.py # roscosmos_collections / roscosmos_search（ロシア Roscosmos 静的STAC）
├── celestrak.py # sat_tle（CelesTrak 全衛星軌道TLE）
├── uk_datahub.py # uk_stac_collections / uk_stac_search（英国 EO DataHub）
├── cnes.py # cnes_status（フランス CNES THEIA/GEODES）
├── weather_astro.py # astronomy_weather（天体観測用天気, Open-Meteo, 月相＋気象庁雨雲画像）
├── jma_rain.py # 気象庁の雨雲・降水画像の合成（解析雨量・降水予報＋ナウキャスト/雷）
├── weather_sat.py # weather_satellite_now（GEO/LEO気象衛星の公開画像, 19機＋理由コード）
├── power.py # power_climate（NASA POWER 気候・太陽エネルギー統計）
├── eodashboard.py # eodashboard_collections / detail（EO Dashboard, NASA/ESA/JAXA）
├── donki.py # space_weather（NASA 宇宙天気 DONKI）
├── swpc.py # NOAA SWPC（宇宙天気のフォールバック・フレアイベント・認証不要）
├── ssd.py # fireball_reports / neo_close_approach / impact_risk（JPL CNEOS, 認証不要）
├── stac_search.py # stac_collections / stac_search（AWS Earth Search STAC）
├── iss.py # iss_now（ISS 現在位置, Open Notify）
├── oscar.py # satellite_status（WMO OSCAR 衛星カタログ）
├── cnsa.py # cnsa_status（中国 CNSA 系衛星データポータル到達状態）
├── tiangong.py # tiangong_now（天宮 中国宇宙ステーション位置, CelesTrak TLE + SGP4）
├── eso.py # eso_seeing（ESO パラナル大気・シーイング）
├── cadc.py # cadc_observations（CADC カナダ天文観測データ）
├── mast.py # mast_observations（MAST: JWST/HST/TESS の観測アーカイブ検索）
├── gcn.py # gcn_alerts（NASA GCN: 過渡天体速報 GCN Circulars）
├── literature.py # 学術文献（OpenAlex/Crossref/NTRS/JAXAリポジトリ/J-STAGE/CiNii/Zenodo/DataCite ＋ 任意キー ADS/S2/WoS）
├── alma.py # alma_search（ALMA 電波観測データ, Science Archive TAP）
├── tart.py # radio_sources_now（TART オープン電波望遠鏡 可視電波源）
├── skyfield_pos.py # constellation_now（天体位置・星座, Skyfield）
├── news.py # astronomy_news（Sky & Telescope 天文ニュース）
├── sky_overlay.py # sky_map_with_satellites（星図+人工衛星, 天頂中心の円形図 / matplotlib+Pillow）
├── ground_view.py # sky_map_with_satellites(engine="ground") 地上視点パノラマ（実星表・天の川・街並み・方位目盛り）
├── solar_system.py # solar_system_now（太陽系俯瞰図, JPL DE421+SBDB / matplotlib+Pillow）
├── solar_eclipse.py # solar_eclipse_series（日食の時系列パネル, JPL DE421+Skyfield）
├── moon_phase.py # moon_phase_map（月齢マップ: 月齢カレンダー/朔望月パネル, JPL DE421+Skyfield）
├── mars_rover.py # mars_rover_status（火星ローバー状況・天気）
├── surface_map.py # 天体面地図の共通描画（タイル合成・等角投影・地点マーカー・画素検証）
├── planetary_map.py # planetary_orbiter_track（汎用・天体周回機マップ／落点マップ）
├── calendar_store.py # 蓄積ストア（正規化レコード＋来歴／ユーザー予定・原子書き込み・月別TTL・prune）
├── space_calendar.py # space_calendar / calendar_events / calendar_event_add / calendar_event_remove
└── planetary_rover.py # planetary_rover_location_map（汎用・ローバー位置マップ）リポジトリ直下（エージェント・クライアント向け）:
space-finder-mcp/
├── CLAUDE.md # Claude Code 用プロジェクトガイド
├── AGENTS.md # Codex など AGENTS.md を読むエージェント向け
├── SKILL.md # エージェント向けスキル定義（66ツール仕様）
├── mcp.json # MCPクライアント設定の例
├── .env.example # 環境変数の例（NASA_API_KEY は任意）
├── .claude/rules/ # 開発規約（coding-conventions / testing-and-verification / data-and-sources）
├── scripts/check-tools.py # 回帰検証ゲート（全ツール実行 / --offline / --dead-code / --fuzz
│ # / --figures / --media-links / --concurrency / --stdio）
├── tests/ # 回帰テスト（unittest discover -s tests。並列・起動import・遮断時の挙動）
├── pyproject.toml # 依存・バージョン（uv 管理）
└── README.md / LICENSEライセンス: MIT License（本リポジトリの LICENSE を参照）
データソース: NASA・NASA Image & Video Library・Launch Library 2・Wikidata(Wikimedia)・ISRO・ESA Copernicus Data Space・JAXA Earth API・CSA Open Data・INPE BDC・CelesTrak（遮断時は tle.ivanstanojevic.me / SatNOGS へフォールバック）・UK EO DataHub・CNES THEIA/GEODES・CNSA（NSMC/CNSA-GEO/CRESDA）・CelesTrak（天宮TLE）・ESO ASM・ALMA Science Archive(NAOJ)・TART・CADC・JPL/Skyfield(de421)・NASA MMGIS・NASA Trek WMTS・Open-Meteo(CC BY 4.0)・EO Dashboard・NASA CCMC/DONKI・NOAA SWPC・NASA POWER・AWS Earth Search STAC・Open Notify・WMO OSCAR は、それぞれの利用条件・ライセンスに従います。
宇宙データは科学的な内容を含みます。応答時は引用元（Wikipedia / NASA / ISRO / ESA / JAXA / CSA / CNSA 等）へのリンクを必ず表示してください。
画像・動画・音声の著作権・クレジット表記は各ソースの指示に従ってください（NASA素材は NASA Media Usage Guidelines を参照）。
逆引き歴史Q&A（Wikidata）
ロケット打ち上げ・NASA日次
画像・音声・動画の検索・表示
他国の宇宙機関データ（ISRO・ESA/Copernicus・JAXA・CSA・INPE・CelesTrak・UK EO DataHub・CNES）
天体観測用天気（Open-Meteo）
EO Dashboard（NASA/ESA/JAXA 共同地球観測カタログ）
宇宙天気（NASA DONKI: 太陽フレア・CME・地磁気嵐）
AWS Earth Search STAC（Sentinel/Landsat/NAIP 検索）
ISS 現在位置（Open Notify + Googleマップ表示）
WMO OSCAR 衛星カタログ（運用ステータス）
中国 CNSA 系衛星データポータル（風雲/高分/CBERS 到達状態）
中国のロケット打ち上げ（china_launches）・天宮リアルタイム位置（tiangong_now）
天体観測の強化（astronomy_weather に月相・月明かり統合）・NASA POWER 気候データ（power_climate）
世界の天文観測データ（ESO パラナルシーイング・CADC カナダ天文データ・MAST/JWST・HST アーカイブ）
ロシア（Roscosmos）の打ち上げデータ（russia_launches）
天体位置・星座計算（constellation_now, Skyfield + JPL）
天文ニュース（astronomy_news, Sky & Telescope RSS）
火星探査ローバー状況（mars_rover_status, Mars Weather）
地球リアルタイム画像（EPIC/DSCOVR）
惑星の3D地図（NASA Trek WMTS）
多言語（en/zh）応答の全面対応
ALMA（アルマ望遠鏡, 電波干渉計）の観測データを検索する（認証不要）。
ALMA Science Archive（NAOJ 東アジア鏡, IVOA TAP）の観測メタデータを ADQL で検索する。
mm/サブmm電波観測なので、赤外・可視の望遠鏡とは異なる低温ガス・塵の観測が特徴。
例:「アルマで観測されたM100」「HL Tau のALMA観測（バンド7）」「アルマのキューブデータ」
天体名は **表記ゆれを自動で吸収**する（"HL Tau" / "HL_Tau" / "HLTau" 等。アーカイブは
観測者の入力そのままの名前を持つため完全一致だけでは 0 件になりやすい）。それでも
0 件のときは推測せず、アーカイブにある候補名を提示して停止する。
Args:
object_name: 天体名（例 "M100", "HL Tau", "TW Hya", "Orion"）。
ra: 赤経（度）。object_name 省略時、dec と併用（円錐検索）。
dec: 赤緯（度）。
radius: 座標検索の半径（度, 既定 0.3）。
band: ALMA 受信バンドで絞り込み（1〜10。3≈100GHz帯, 6≈230GHz帯, 7≈345GHz帯）。
product_type: "cube"（三次元分光データ）/ "image"（二次元画像）/ "visibility" /
"all"（既定）。obscore は校正済み製品のみを収録する。
public_only: True で公開データ（data_rights=Public）だけに絞る。
with_products: True で datalink を引き、実データ製品（校正済み tar・生データ ASDM・
README・パイプライン製品）の URL 一覧を先頭3件まで添える。
content にはアイコン付きのクリック可能リンクとして出す。
limit: 返す件数（既定 8、最大 20）。
メタデータ検索は認証不要。FITS 本体のダウンロードは data_rights=Public のみ可
（Restricted はプロポーザル権限が必要）。
| Name | Required | Description | Default |
|---|---|---|---|
| ra | No | ||
| dec | No | ||
| band | No | ||
| limit | No | ||
| radius | No | ||
| object_name | No | ||
| public_only | No | ||
| product_type | No | ||
| with_products | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and does so richly: metadata search needs no auth, FITS download works only for data_rights=Public (Restricted needs proposal rights), obscore contains only calibrated products, name matching auto-absorbs spelling variants, and with_products appends datalink URLs (top 3) as clickable content links.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose, protocol, and a query example are front-loaded before args and caveats. It is dense rather than padded, though the multi-paragraph layout with a long Args block is somewhat heavier than strictly necessary for an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 9-parameter, no-annotation, no-output-schema tool, the description covers purpose, all parameters, auth/permission boundaries, zero-result handling, and the with_products enrichment path. Nothing an agent needs to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 for all 9 parameters: object_name examples, ra/dec pairing for cone search, radius default 0.3, band 1–10 with frequency mapping (3≈100GHz, 6≈230GHz, 7≈345GHz), product_type enum meanings (cube/image/visibility/all), public_only, with_products, and limit default 8 / max 20.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb (検索) and resource (ALMA 観測データ / ALMA Science Archive 観測メタデータ) and even identifies the access protocol (IVOA TAP, ADQL). It distinguishes ALMA from infrared/optical telescopes by noting mm/submm radio capability, which separates it from siblings like cadc_observations or jaxa_dataset_search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives concrete query examples (M100, HL Tau band 7, cube data) and clarifies the object_name-vs-ra/dec alternative for coordinate cone search. It also defines the 0-result fallback (present candidate names, do not guess). It stops short of explicitly naming when to prefer a different archive sibling, so not a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
今日（または指定日）の NASA の今日の天文写真(APOD)を返す。NASA_API_KEY が必要。
| Name | Required | Description | Default |
|---|---|---|---|
| date | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It usefully discloses a prerequisite (NASA_API_KEY が必要), which is real behavioral context, but says nothing about rate limits, error behavior, or response shape for a network-backed read.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the core purpose and followed by the auth prerequisite. No filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read tool this is nearly sufficient, but with no output schema and no annotations, the missing date format and any hint about what the response contains (image URL, title, explanation) leave a small but real gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 conveys that the date is optional and defaults to today's picture ('今日（または指定日）'), adding genuine semantics, but it omits the expected date format (e.g. YYYY-MM-DD), which is the key detail an agent needs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('返す' / returns) and a specific resource (NASA's Astronomy Picture of the Day), plus the scope (today or a specified date). It is clearly distinguishable from siblings like astronomy_news or search_space_images, though it does not explicitly name any sibling to route against.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase '今日（または指定日）' implies that the date parameter is optional and that the tool is the right choice when you want the APOD for a particular day, but there is no explicit when-to-use/when-not guidance or named alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
天文ニュース・観測ガイドを返す（複数フィードのフォールバック付き・認証不要）。
「今日の天文ニュース」「今週の星空ガイド」「惑星観測の見どころ」など。
第一候補は Sky & Telescope の公式RSS。取得できない場合は他ソース
(Universe Today / NASA / Phys.org) に自動でフォールバックする。
content に表示用サマリ、structuredContent に JSON を返す。
Args:
limit: 返す件数（既定 8、最大 15）。
section: 絞り込み（"all"=全部, "observing"=観測ガイド, "news"=ニュース）。
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| section | No | all |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With zero annotations the description carries the full burden, and it delivers substantive behavioural detail: multi-source fallback order (Sky & Telescope RSS → Universe Today / NASA / Phys.org), the fact that no authentication is required, and the dual return shape (display summary in content, JSON in structuredContent). Freshness, caching, and failure behaviour when all feeds fail are not stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose is front-loaded in the first sentence, followed by examples, fallback behaviour, return format, and a compact argument list. Every element is relevant, though the parenthetical asides make it slightly denser than strictly necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter, read-only retrieval tool with no annotations and no output schema, the description covers what is fetched, from where, the fallback chain, the no-auth requirement, the return shape, and both parameters. Only edge behaviours (feed exhaustion, limit bounds handling) remain unaddressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and no enums are declared, so the description must supply all parameter meaning. It documents limit (default 8, maximum 15) and section with the allowed values all/observing/news, which the schema does not encode. It adds clear value but omits e.g. what happens for out-of-range limits.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('天文ニュース・観測ガイドを返す') and enumerates concrete content types (daily news, weekly sky guide, planetary observing highlights), so an agent knows exactly what it retrieves. It does not explicitly distinguish itself from near-neighbours like apod, astronomy_weather, or sky_map_with_satellites, which keeps it short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The example phrasings ('今日の天文ニュース', '今週の星空ガイド', '惑星観測の見どころ') imply when the tool is appropriate, and the section parameter hints at query routing. However, no explicit when-not condition or named alternative sibling is given, so usage is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
天体観測に最適な時間帯を予報する（Open-Meteo, 認証不要・全世界対応）。
指定した地点の今後数日間で「夜間かつ雲が少なく・視程が良い」時間帯を抽出し、
観測のチャンスと注意点を AI からのアドバイス形式で返す。
例:「東京で今夜天体観測できる?」「シドニーの晴れ予報」「富士山頂の雲量」
場所は緯度経度(latitude/longitude)または地名(place)で指定。
Args:
latitude: 緯度（例 東京 35.68）。place 指定時は省略可。
longitude: 経度（例 東京 139.69）。
place: 地名（緯度経度より優先）。Open-Meteo のジオコーディングで解決。
days: 予報日数（1〜7、既定 3）。
max_cloud: 「観測可」とみなす雲量の上限%（既定 40）。
include_rain: 日本国内の地点に限り、気象庁の雨雲・降水画像
（解析雨量・降水短時間予報のパネル＋ナウキャスト＝雨雲の動き）を
添付する（既定 True。取得失敗時は添付なしで続行）。
⚠️ structuredContent.figure.notes は要約せずそのまま引用すること。
（添付した雨雲・降水画像は content に「🖼️ [◯◯を開く](URL)」のリンク付きで出します。
インライン画像を描画しないハーネスでは、回答にこのリンクをそのまま提示してください。）
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | ||
| place | No | ||
| latitude | No | ||
| longitude | No | ||
| max_cloud | No | ||
| include_rain | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses no authentication needed, global coverage, advice-style output, the rain-imagery attachment behavior, the failure fallback, and the instruction to preserve structuredContent.figure.notes and image links. It does not mention rate limits or explicitly state read-only behavior, but the forecast nature makes this mostly implicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, followed by examples and then a structured Args list. It is longer than minimal, but the extra detail, especially the rain-image handling notes, is operationally useful rather than filler. The organization keeps it readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with six parameters and no output schema, the description covers location specification, parameter semantics, output behavior, and edge cases such as failed image retrieval. It does not explain the exact output format beyond 'AI advice' and optional image links, and it avoids discussion of timezone handling or validation errors, but the agent has enough to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no property descriptions, but the description compensates thoroughly by documenting all six parameters: latitude, longitude, place precedence over coordinates, days range with default, max_cloud threshold meaning, and include_rain behavior plus fallback. This adds substantial meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear purpose: forecasting the best time windows for astronomical observation based on nighttime, low cloud, and good visibility. It names the data source (Open-Meteo), authentication requirement, and global scope, and the examples (e.g., 'Can I stargaze in Tokyo tonight?') make the resource and intent unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives concrete usage context through examples, explains how to specify location via coordinates or place name, and documents parameter ranges and precedence rules. It does not explicitly compare this tool to any sibling tool or state when not to use it, so there is a slight gap in exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
CADC（カナダ天文データセンター）の観測データを検索する（認証不要）。
HST(ハッブル)・ジェミニ望遠鏡・NEOSSat 等の観測メタデータを、
天体名または座標（ra/dec）で ADQL 検索する。
例:「ハッブルが撮ったNGC 300」「オリオン星雲の観測データ」「ジェミニの観測一覧」
パブリックメタデータは認証不要。画像ダウンロードは一部要認証。
Args:
object_name: 天体名（例 "M31", "Orion", "NGC 300", "M104", "Sombrero", "HL Tau"）。
座標指定より優先。内蔵テーブルに無い名前は **SIMBAD/NED（Sesame）で座標解決**し、
和名（オリオン大星雲 等）も英語名に展開して解決する（推測では検索しない）。
ra: 赤経（度）。object_name 省略時、dec と併用。
dec: 赤緯（度）。
radius: 検索半径（度, 既定 0.5）。
telescope: 望遠鏡で絞り込み（例 "HST", "Gemini-North", "TESS"）。
limit: 返す件数（既定 8、最大 20）。
| Name | Required | Description | Default |
|---|---|---|---|
| ra | No | ||
| dec | No | ||
| limit | No | ||
| radius | No | ||
| telescope | No | ||
| object_name | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and does well: it discloses that lookup is unauthenticated for public metadata but partially restricted for image download, that unresolved names are resolved via SIMBAD/NED (Sesame) with Japanese-name expansion and no guessing, and that results are capped (limit default 8, max 20). It does not describe the returned record structure or pagination, so it is strong but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose, then scope, then examples, then per-argument semantics, so an agent can stop reading at any level. It is slightly long-winded in the object_name entry, where five example names plus the SIMBAD explanation could be trimmed, but every block still carries usable information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a six-parameter tool with no annotations and no output schema, the description covers selection logic, auth requirements, resolution behavior, and result caps. The only real gap is what a returned observation record contains, though with no output schema that gap is not fully avoidable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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: every one of the six parameters is defined with units (degrees), defaults (radius 0.5, limit 8), a max (20), value examples ('HST', 'Gemini-North', 'TESS'), and a precedence rule between object_name and ra/dec. This is exactly the semantic detail the bare schema lacks.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('CADCの観測データを検索する') and scopes it to concrete holdings (HST, Gemini, NEOSSat metadata) retrieved via ADQL by object name or coordinates. The example queries ('ハッブルが撮ったNGC 300', 'オリオン星雲の観測データ') make the intended use unmistakable and clearly separate it from generic image search siblings like search_space_images.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear operational conditions: object_name takes precedence over coordinates, and ra/dec are only used together when object_name is omitted. Auth context ('パブリックメタデータは認証不要。画像ダウンロードは一部要認証') tells the agent when the tool works unauthenticated. It stops short of explicitly naming an alternative (e.g. alma_search or eso_seeing) for overlapping archive queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
カレンダーに自分の予定を追加する（ローカルの蓄積ストアに保存。外部へは送信しません）。
追加した予定は `space_calendar` の図と本文、`calendar_events` の一覧に現れます。予定は
**フローティングなローカル日時**で保存するので、`place` を変えても予定の日付は動きません
（海外の予定を入れるときは note に現地時刻を書いてください）。
Args:
title: 予定の名前（例: 「すばる望遠鏡 観測提案の締切」）。
date: 開始日。"2026-10-24" / "2026/10/24" / "2026年10月24日" / "10/24"（年は今年と解釈）。
time: 開始時刻（例 "10:30" / "10時30分"）。省略すると終日予定になります。
date_end: 終了日（複数日の予定・展覧会など）。省略すると1日。
repeat: 繰り返し: none / daily / weekly / monthly / yearly（既定 none）。
note: 補足メモ（任意）。
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | ||
| note | No | ||
| time | No | ||
| title | Yes | ||
| repeat | No | ||
| date_end | No |
カレンダーの自分の予定を削除する（id か title[+date] で指定）。
既に無い場合や既に削除済みの場合はエラーにせず「該当なし」を返します（冪等）。
title だけで複数該当したときは**削除せず候補を提示**します（推測して消さない）。
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | ||
| date | No | ||
| title | No |
蓄積済みのイベント一覧を返す（図を描かず、外部APIも呼ばない軽い経路）。
蓄積ストア（`space_calendar` が取得したものと `calendar_event_add` で入れた予定）だけを読みます。
呼び出し時に保持期限（カレンダーと同じ日数＝過去データの自動削除）も適用します。
「今月の予定は？」「10月の公開イベントは？」のように、まず一覧だけ見たいときに使ってください。
打ち上げ・天文現象の鮮度は `structuredContent.sources` に取得時刻として入ります。
Args:
year: 対象年（既定: 基準地の今年）。
month: 対象月（既定: 基準地の今月）。
place: タイムゾーン決定のための基準地（既定 東京）。
kinds: カテゴリの絞り込み: user/launch/sky/neo/fireball/public/holiday（カンマ区切り）。
all で全部。neo / fireball は `neo_close_approach` / `fireball_reports` の呼び出しで
蓄積されたレコードだけが出ます。
| Name | Required | Description | Default |
|---|---|---|---|
| year | No | ||
| kinds | No | all | |
| month | No | ||
| place | No | 東京 |
VizieR（CDS）の観測星表を「その位置にある天体」で検索する（認証不要）。
VizieR は世界最大の天文観測星表アーカイブで、2MASS（赤外）・Gaia DR3・AllWISE・
Pan-STARRS1・SDSS・ヒッパルコス・NGC などを、指定した天体のまわりで円錐検索できる。
値は星表ごとの生の列名で返し、列名と単位も同時に返す（LLM が意味を推定せずに済む）。
例:「M31 のまわりの 2MASS の天体」「シリウスの Gaia DR3 の値」「NGC カタログで
オリオン大星雲を調べる」
Args:
object_name: 天体名（和名可。Sesame/CDS で座標へ解決してから検索する）。
ra: 赤経（度）。object_name 省略時に dec と併用。
dec: 赤緯（度）。
catalog: 星表（既定 2mass）。指定できる名前は 2mass / gaia / gaia-edr3 /
hipparcos / allwise / unwise / ps1 / sdss16 / sdss12 / ngc、または
VizieR の生の表名（例 "II/246/out"）。未知の名前は候補一覧を返して停止する。
radius_arcmin: 円錐検索の半径（分角, 0.1〜60, 既定 1.0）。VizieR の c.rm は
分角単位（秒角指定は無視されるため 0.1 未満は 0.1 に丸める）。
max_rows: 返す行数（既定 10, 最大 50）。
注意: VizieR の ASU は星表名を省略すると世界中の全星表を走査して 57 MB を返すため、
このツールは星表名の指定を前提にしている。
| Name | Required | Description | Default |
|---|---|---|---|
| ra | No | ||
| dec | No | ||
| catalog | No | 2mass | |
| max_rows | No | ||
| object_name | No | ||
| radius_arcmin | No |
中国のロケット打ち上げ予定（長征シリーズ・LandSpace等の民間企業を含む）を返す。
Launch Library 2 を「search=China」で絞り込み、長征（Long March）シリーズや
Shenzhou（有人）/Tianzhou（補給）、Hyperbola-3（LandSpace）等を取得する。
認証不要。content に表示用サマリ、structuredContent に JSON を返す。
Args:
limit: 返す件数（既定 8、最大 15）。
status: 状態で絞り込み（例 "Go for Launch", "To Be Determined"）。省略で全状態。
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| status | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does disclose key traits: it names the upstream source (Launch Library 2 with search=China), states auth is not required, and explains the dual return channels (content summary vs structuredContent JSON). It omits error/rate-limit behavior, but the essential behavioral context is present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The purpose is front-loaded in the first line, followed by data source, output format, and args. Slightly verbose with the upstream-source explanation, but each block serves a purpose and nothing is filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 2-parameter tool with no output schema and no annotations, the description covers what it does, the source, the return structure, and both parameters' behavior. An agent has what it needs to call it correctly, though it could note the global-scope alternative for completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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: it documents limit (default 8, max 15) and status with example values ('Go for Launch', 'To Be Determined') plus the omit-for-all behavior. The max-15 cap and status examples are meaning the schema itself does not convey.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('returns Chinese rocket launch schedule') and scopes it precisely to China, naming the Long March series and private firms (LandSpace). This clearly distinguishes it from siblings like upcoming_launches and russia_launches without the agent needing to open a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The China-only scope implicitly differentiates it from upcoming_launches and russia_launches, and the status filter use is explained. However, it never explicitly names an alternative or states when to prefer this over the global launch tool, leaving routing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
フランス CNES の地球観測データポータル（THEIA / GEODES）の到達状態と概要を返す。
例:「フランスのCNES衛星データ」「THEIAポータル」
画像ダウンロードには CNES アカウント登録が必要。ここではポータルの状態と
提供データの概要を確認する。
Returns:
CallToolResult: 表示用サマリ + JSON。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so the description carries the full burden. It discloses the return shape (display summary + JSON) and the meaningful boundary that no downloads/account are involved, but says nothing about authentication needs, failure behavior when the portal is unreachable, 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the core purpose, then examples, then the account/download caveat, then the return note. Information is well ordered, though the Japanese wording is slightly verbose for what is a no-argument status check.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only status tool with no output schema, the description covers what it does, when to reach for it, the download limitation, and the return format. Nothing essential is missing, though it remains silent on error behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the schema has nothing to document and there is no parameter semantics to compensate for; the baseline of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific resource (the French CNES Earth observation portal, THEIA/GEODES) and a specific verb (returns reachability status and overview). An agent can distinguish it from the sibling cnsa_status (Chinese agency) and from satellite_status without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives example trigger phrases ("French CNES satellite data", "THEIA portal") and implicitly draws a boundary by noting that image downloading requires a CNES account and that this tool only checks portal status and data overview. It does not name an explicit alternative tool, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
中国 CNSA 系衛星データポータル（風雲/NSMC・高分/CNSA-GEO・CBERS/CRESDA）の到達状態と概要を返す。
例:「中国の衛星データ」「風雲衛星」「高分」「CBERS」
画像ダウンロードには各ポータルへのアカウント登録が必要。ここではポータルの状態と
提供データの概要、および認証不要の代替データ源を確認する。
Returns:
CallToolResult: 表示用サマリ + JSON。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full behavioral burden. It discloses that the tool reports portal reachability, provides data overviews, and notes that downloading images requires account registration while the tool itself focuses on status and auth-free alternatives. This is useful context, but it doesn't specify return format details beyond 'summary + JSON' or any 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, followed by examples and a note about account requirements. It is reasonably concise, though the parenthetical listing of agencies is slightly dense and the 'Returns' block is boilerplate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description covers the essential aspects: what the tool does, what it returns broadly (summary + JSON), and important context about account requirements and auth-free alternatives. It is nearly complete, missing only explicit routing to sibling tools or detailed output structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters (parameter count 0, required 0), so the baseline is 4. The description correctly implies that no input is needed—it is a status-checking tool—and adds no misleading parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific purpose: returning the reachability status and overview of three Chinese satellite data portals (FY/NSMC, GF/CNSA-GEO, CBERS/CRESDA). It also provides example queries that reflect the intended use. It is clear, though its distinction from siblings like cnes_status, jaxa_datasets, or copernicus_collections relies on the national/agency scope rather than explicit differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied through examples ('中国の衛星データ', etc.) and the note about needing portal accounts for image downloads. However, it does not explicitly state when to use this tool versus alternatives, nor does it name a sibling tool for cross-portal search.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
指定した観測地・日時で太陽・月・惑星の位置（高度・方位角・星座）を返す。
「今夜東京で見える惑星は?」など。NASA JPL 天体暦 + Skyfield でローカル計算（認証不要）。
Args:
latitude: 観測地の緯度（例 東京 35.68）。place 指定時は省略可。
longitude: 観測地の経度（例 東京 139.69）。
place: 観測地名（既知テーブル）。緯度経度より優先。
time_utc: 観測時刻 "YYYY-MM-DD HH:MM"（UTC）。省略で現在。
| Name | Required | Description | Default |
|---|---|---|---|
| place | No | ||
| latitude | No | ||
| time_utc | No | ||
| longitude | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does a decent job: it discloses local computation via NASA JPL ephemeris + Skyfield, that no authentication is needed, and that omitting time_utc defaults to 'now'. It does not discuss response format or numeric precision/frame, but the key operational traits are covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded summary, then a concrete query example, then an Args block — well organized with no filler. The example sentence and the ephemeris note each earn their place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-parameter read/compute tool with no output schema, the description names the returned quantities (altitude, azimuth, constellation) and the input semantics fully. It could say slightly more about the return structure, but nothing required to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, yet the description documents all four parameters — latitude/longitude with a Tokyo example, place as a known-name lookup, and time_utc with its format and default. It even states the precedence rule that place overrides latitude/longitude, adding meaning absent from the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (返す) and precise resource — altitude, azimuth, and constellation of Sun/Moon/planets for a given site and time. It is distinguishable from most siblings, though it does not explicitly contrast itself with the nearby solar_system_now tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The '「今夜東京で見える惑星は?」' example gives a concrete use case, which implies when to reach for it. However, there is no explicit when-not guidance and no routing to alternatives such as solar_system_now, leaving comparison to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ESA Copernicus の利用可能な衛星データコレクション一覧を返す（認証不要）。
例:「Copernicusの衛星データ」「Sentinelのコレクション」
content に表示用サマリ、structuredContent に JSON を返す。
Args:
limit: 返す件数（既定 20、最大 100）。
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does well: it discloses that no authentication is needed, that content holds a display summary while structuredContent holds JSON, and that the limit caps at 100. It does not mention pagination or rate limits, but the key behavioral traits for a read-only listing tool are covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The entry is compact and front-loads the core purpose before examples, return-format notes, and the limit argument. Every sentence contributes information; only the example phrases feel slightly redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no output schema, the description covers purpose, auth requirements, return shape (content summary plus structuredContent JSON), and the single argument's bounds. Nothing essential for correct invocation appears to be missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and only one parameter exists, so the description must carry meaning. It explains that limit is the number of items to return, with a default of 20 and a maximum of 100 — the max is not present anywhere in the schema, so this adds genuine value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 list of available ESA Copernicus satellite data collections. This distinguishes it functionally from sibling tools like copernicus_search (which presumably searches within collections), though it does not name that sibling explicitly. Clear but lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description notes it requires no authentication and gives example query phrasings (e.g. 'Copernicus satellite data', 'Sentinel collections'), which implies when to use it. However, it never explicitly states when to prefer this over copernicus_search or other collection-listing siblings, leaving the choice to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ESA Copernicus（Sentinel ほか）の衛星画像を STAC で検索する（検索は認証不要）。
例:「東京のSentinel-2画像」「関東の最近の衛星画像」
content に表示用サマリ、structuredContent に JSON（id/日時/bbox/雲量/プレビューURL）を返す。
画像のダウンロードには CDSE アカウント（OAuth2）が必要だが、検索・プレビューURL取得は無料。
Args:
collection: STAC コレクションID（既定 "sentinel-2-l2a"）。copernicus_collections で確認可。
bbox: 空間範囲（"lon_min,lat_min,lon_max,lat_max"、例 東京: "139.6,35.5,139.9,35.8"）。
datetime: 時間範囲（"YYYY-MM-DD" または "start/end"、例 "2026-01-01/2026-03-31"）。省略で最新。
max_cloud_cover: 雲量の上限（%）（Sentinel-2 等 eo:cloud_cover を持つ場合）。
limit: 返す件数（既定 5、最大 10）。
| Name | Required | Description | Default |
|---|---|---|---|
| bbox | No | ||
| limit | No | ||
| datetime | No | ||
| collection | No | sentinel-2-l2a | |
| max_cloud_cover | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses that search and preview-URL retrieval need no authentication, while downloading images requires a CDSE OAuth2 account. It also states the return payload shape (content summary, structuredContent JSON with id/datetime/bbox/cloud cover/preview URL). It doesn't mention rate limits or failure modes, but the auth and return-format disclosure is substantial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well front-loaded: one-line purpose, auth caveat, return shape, then an Args block per parameter. Every section earns its place. The natural-language example lines are slightly redundant given the Args block, but they aid intent matching, so the size is justified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 5-parameter STAC search with no annotations, no output schema, and 0% schema coverage, the description supplies everything needed: purpose, auth behavior, return payload contents, and per-parameter formats with examples. Nothing critical is missing for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and there are 5 parameters, so the description must compensate fully — and it does. Every parameter gets meaning: collection ID with default and cross-reference to copernicus_collections, bbox format 'lon_min,lat_min,lon_max,lat_max' with a Tokyo example, datetime format 'YYYY-MM-DD' or 'start/end' with a concrete range, max_cloud_cover in percent and its applicability condition, and limit default 5 / max 10.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (search/検索) and resource (ESA Copernicus satellite imagery via STAC) and gives concrete examples (東京のSentinel-2画像). The sibling copernicus_collections is explicitly named as the way to discover collection IDs, distinguishing the two tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Clearly explains when this tool applies (searching Sentinel imagery), notes that search requires no auth, and points to the sibling copernicus_collections for valid IDs. Also gives examples of natural-language intents it serves. It does not, however, contrast with stac_search or uk_stac_search, so the agent must infer which STAC endpoint to choose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
CSA（カナダ宇宙庁）オープンデータポータルでデータセットを検索する（認証不要）。
例:「カナダのRADARSATデータ」「CSAの宇宙データセット」
content に表示用サマリ、structuredContent に JSON（ID/タイトル/概要/ライセンス/URL）を返す。
Args:
query: 検索語（例 "radarsat", "space", "earth observation"）。省略で先頭のデータセット。
limit: 返す件数（既定 10、最大 20）。
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden; it usefully discloses that no authentication is required and describes the return shape (display summary in content, JSON with ID/title/summary/license/URL in structuredContent). It omits pagination behavior beyond limit and any rate-limit notes, but for a read-only public search endpoint this is solid disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the purpose, then examples, then return format, then args. Reasonably tight, though the example-query block and Args listing add some repetition that could be trimmed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 2-parameter, no-annotation, no-output-schema tool, the description covers purpose, auth, parameters, defaults, limits, and return structure. An agent has enough to call it correctly; only explicit sibling routing is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 documents both parameters: query's meaning and example terms plus the omission behavior (returns leading datasets), and limit's default of 10 with a maximum of 20 — the max is not in the schema, so this adds real value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('search datasets' on the CSA open data portal) plus example queries, which is clearer than a bare name. However, with ~40 sibling search tools it never names or contrasts an alternative (e.g. jaxa_dataset_search, copernicus_search), so differentiation relies on the reader noticing the agency name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives example queries and notes 認証不要 (no auth needed), which implies the usage context. It does not say when to prefer this over the many other dataset-search siblings or state any exclusion conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
DLR（ドイツ航空宇宙センター）EOC の地球観測コレクション一覧を返す（認証不要）。
例:「ドイツの地球観測データ」「DLRのSentinel-2コレクション」
content に表示用サマリ、structuredContent に JSON（id/説明/ライセンス）を返す。
Args:
limit: 返す件数（既定 40、最大 100）。
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
DLR（ドイツ）の地球観測データを STAC で検索する（認証不要）。
例:「ドイツのSentinel-2画像」「ベルリン周辺のEnMAPデータ」「TROPOMIの二酸化窒素」
content に表示用サマリとプレビュー/メタデータのリンク、structuredContent に JSON
（id/日時/雲量/bbox/プラットフォーム/処理レベル/ライセンス/アセットURL）を返す。
Args:
collection: STAC コレクションID（既定 "S2_L2A_MAJA"）。dlr_collections で確認可。
bbox: 空間範囲（"lon_min,lat_min,lon_max,lat_max"）。
datetime: 時間範囲（"YYYY-MM-DD" または "start/end"）。⚠️ DLR の API は `sortby` を
無視する（実測: `sortby=-datetime` を送っても並びが変わらない）ため、新しい順に
得たい場合は `datetime` で期間を指定してください。
max_cloud_cover: 雲量上限（%）。⚠️ DLR の API はサーバー側フィルタ未対応（実測 400）のため、
取得後にクライアント側で絞り込む（雲量情報の無いアイテムは除外し、件数を返す）。
limit: 返す件数（既定 5、最大 10）。
| Name | Required | Description | Default |
|---|---|---|---|
| bbox | No | ||
| limit | No | ||
| datetime | No | ||
| collection | No | S2_L2A_MAJA | |
| max_cloud_cover | No |
EO Dashboard（NASA・ESA・JAXA共同）の地球観測データセットを検索する（認証不要）。
3機関の衛星データ（大気・海洋・陸域・雪氷・農業・社会経済など173件）の
一覧・検索を返す。content に表示用サマリ、structuredContent に JSON を返す。
例:「NASAの大気データ」「気候変動の衛星データ」「NO2 のデータセット」
テーマで絞る: agriculture / atmosphere / biomass / covid-19 / cryosphere /
economy / extreme-events / oceans
Args:
themes: テーマ（例 "atmosphere", "oceans"）。カンマ区切りで複数可。
agency: 機関（例 "NASA", "ESA", "JAXA"）。
keyword: キーワード（タイトル・説明に部分一致）。
limit: 返す件数（既定 20、最大 50）。
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| agency | No | ||
| themes | No | ||
| keyword | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and usefully discloses no-auth access, output format split between content and structuredContent, and the default/maximum limit. It still does not describe rate limits, result ordering, or pagination behavior beyond the limit cap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the purpose, followed by output behavior, examples, filter values, and parameter semantics. Every section adds useful information for invocation, with no redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given four optional parameters, no annotations, and no output schema, the description is mostly complete: it covers purpose, auth, output channels, filtering, and parameter limits. It could further describe the shape of the returned structuredContent JSON or the semantics of combining multiple themes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain all parameters, and it does. It documents themes with examples and comma-separated multi-value support, agency with examples, keyword matching against title and description, and limit with default and maximum values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb and resource: searching EO Dashboard earth observation datasets jointly provided by NASA, ESA, and JAXA. It also gives scale and domain context (173 datasets across atmosphere, ocean, land, etc.). However, it does not explicitly differentiate this collection-search tool from the sibling eodashboard_detail tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear usage context through example queries and theme-based filtering, and notes that authentication is not required. It does not state when not to use this tool or explicitly direct the agent to a preferred alternative such as eodashboard_detail.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
EO Dashboard の1つのデータセットの詳細（衛星・センサー・説明・参照リンク・画像）を返す。
例:「NO2データセットの詳細」「EO Dashboardの海面水温の情報」
content に表示用サマリ＋サムネイル画像(インライン)、structuredContent に JSON を返す。
インライン画像を表示できないハーネス（CLI系・Android系の codex / opencode など）向けに、
画像本体より前に「🖼️ [画像を開く: … のサムネイル](URL)」というアイコン付きリンクを必ず出します
（同じURLを structuredContent.image_url にも入れます）。
回答時はこのリンクをそのまま提示してください（画像が描画されない環境では唯一の導線）。
Args:
identifier: コレクションIDまたは名前（例 "N1_NO2", "NO2_daily", "sea_ice"）。
大まかな名前でも探す。
show_image: サムネイルをチャットにインライン表示するか（既定 True）。
| Name | Required | Description | Default |
|---|---|---|---|
| identifier | Yes | ||
| show_image | No |
ESO パラナル天文台（チリ, VLT）のリアルタイム大気・シーイング観測データを返す。
例:「パラナル天文台のシーイング」「VLTの観測コンディション」「赤外線観測の水蒸気」
認証不要。シーイング(arcsec)・可降水量(PWV)・気温・湿度・風速を返す。
Args:
hours: 過去何時間分を取得するか（既定 12、最大 48）。
fields: カンマ区切りの観測フィールド。省略で主要フィールド。
| Name | Required | Description | Default |
|---|---|---|---|
| hours | No | ||
| fields | No | dimm_paranal-fwhm,lhatpro_paranal-pwv0,meteo_paranal-temp1,meteo_paranal-rhum1,meteo_paranal-wind_speed1,meteo_paranal-press_inst |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden, and it does disclose notable behavior: no authentication required, real-time observational data, and the specific fields returned (seeing arcsec, PWV, temp, humidity, wind). It omits data cadence, rate limits, and error behavior, but the auth and return-value context is genuinely useful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded purpose followed by example queries, auth/return summary, and an Args block — well structured and free of padding. Slightly longer than strictly needed but every section carries information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter, no-output-schema, no-annotation tool, the description covers purpose, invocation examples, authentication, return fields, and both parameter constraints. An agent has enough to call it correctly; only field enumeration and freshness/cadence details are missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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: hours is described as lookback window with default 12 and max 48, and fields as a comma-separated list where omission means the main fields. It stops short of enumerating valid field names beyond the schema's default string.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a concrete verb and resource: returns real-time atmospheric/seeing observation data from ESO Paranal (Chile, VLT). The observatory/instrument scoping makes it distinguishable from the generic sibling astronomy_weather, though it never explicitly names that sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The three example queries (Paranal seeing, VLT conditions, IR water vapor) imply the user intents this tool serves, giving implied usage rather than explicit when/when-not guidance. With 40+ siblings including astronomy_weather, it should say which queries belong to those tools instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
太陽系外惑星を NASA Exoplanet Archive から検索する（認証不要）。
系外惑星の確定カタログ（複合パラメータ表 pscomppars）を検索し、軌道周期・
軌道長半径・半径・質量・平衡温度・恒星放射・主星の型・距離・TIC/Gaia ID を返す。
例:「TRAPPIST-1 の惑星は？」「地球くらいの温度の系外惑星を探す」「2020年以降に
見つかった近い系外惑星」「トランジット法で見つかった惑星」
Args:
object_name: 主星名または惑星名（例 "TRAPPIST-1", "Proxima Cen", "Kepler-22",
和名 "ケプラー22"）。部分一致で探し、和名は英語名＋番号に展開して試す。
discovery_method: 発見手法で絞り込み（部分一致。例 "transit", "radial velocity",
"microlensing"、和名は トランジット / 視線速度 / マイクロレンズ など）。
max_distance_pc: 主星系までの距離の上限（パーセク）。
since_year: 発見年（disc_year）の下限。
earth_like: True で地球サイズ（0.5〜2.0 地球半径）かつ平衡温度 200〜320 K に絞る
（2026-09 時点で 61 件）。
limit: 返す惑星数（既定 10, 最大 50）。
0 件のときは推測せず、主星名の候補を提示して停止する。数値引数は不正でも既定値に落ちる。
出典: NASA Exoplanet Archive（NExScI/Caltech, DOI: 10.26133/NEA12）。
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| earth_like | No | ||
| since_year | No | ||
| object_name | No | ||
| max_distance_pc | No | ||
| discovery_method | No |
JPL CNEOS の火球（大気圏突入）観測記録を返す（認証不要・APIキー不要）。
火球とは**大気圏に突入して光った現象**の観測記録です（NASA/JPL CNEOS の
Fireball Data）。米国政府のセンサ（衛星・赤外）や地上観測の報告に基づきます。
隕石（地上に落下した石）の回収情報ではないため、**落下物の推定はしません**。
例:「最近の火球」「今月の大きな火球」「火球はどこで観測された?」「隕石は落ちた?」
content に表示用サマリ、structuredContent に JSON を返します。
Args:
days: 何日前までをさかのぼるか（1〜1825、既定 30）。UTC の日付で絞り込みます。
min_impact_energy_kt: 衝突エネルギーの下限（kt TNT 換算。例 0.5）。省略時は全件。
limit: 表示する最大件数（1〜50、既定 10）。新しい順。
require_location: True なら緯度経度が報告されている記録だけを返します。
放射エネルギー(J)・衝突エネルギー(kt)・突入高度(km)・緯度経度・突入速度
（速度成分 vx,vy,vz から算出。**欠測が多い**）を返します。位置が未報告の記録は
「位置不明」と明示します。緯度経度・高度は**最大光度（ピーク）時点**の値で、
落下地点ではありません（落下物の推定はしません）。
出典: NASA/JPL CNEOS Fireball Data API（ssd-api.jpl.nasa.gov）
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | ||
| limit | No | ||
| require_location | No | ||
| min_impact_energy_kt | No |
NASA GCN（General Coordinates Network）の過渡天体速報（GCN Circulars）を返す（認証不要）。
GCN は GRB・重力波・ニュートリノ・X線新星などの速報を世界の観測所から集めて配る
NASA GSFC のサービスです。本ツールは **Circulars（人が書く速報）** を期間・キーワードで
新しい順に一覧し、`circular_id` を指定すればその1件の本文（投稿者・観測時刻・本文）まで返します。
例:「直近1週間のGRB速報」「今日のGCN速報」「重力波の続報」「EP（アインシュタイン探査機）のアラート」
Args:
days: 何日前までを対象にするか（1〜60、既定 7）。UTC 日付で絞り込みます。
query: キーワード（例 "GRB", "neutrino", "GW", "SVOM", "EP"）。省略時は全件。
circular_id: Circular 番号（例 "45640"）。指定すると1件の本文を返します（一覧は返しません）。
limit: 一覧で返す最大件数（既定 25、最大 100）。
注意: ここで返すのは人が書く Circular です。機械可読の **Notices** は Kafka
（kafka.gcn.nasa.gov:9092・`gcn.notices.*`）配信のみで、本ツールの対象外です。
出典: NASA GCN (gcn.nasa.gov)。回答時は Circular のリンクをそのまま提示してください。
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | ||
| limit | No | ||
| query | No | ||
| circular_id | No |
JPL Sentry による「将来の衝突リスク」を返す（認証不要・APIキー不要）。
小天体が将来の100年規模で地球に衝突する**確率の推算**（CNEOS Sentry）です。
確率は観測が増えると下がり、0 になれば Sentry から削除されます。数値はあくまで
推算で、進路が確定した「衝突予報」ではありません。
例:「衝突確率の高い小惑星」「Sentry に載っている天体」「2024 YR4 の衝突リスク」
content に表示用サマリ、structuredContent に JSON を返します。
Args:
designation: 小惑星の仮符号または番号（例 "2024 YR4"、"2000 SG344"、"99942"）。
指定すると、その天体の詳細（累積確率・想定時期・仮想衝突(VI)の一覧）を返します。
**和名・愛称は JPL 側が受け付けません**。推測せず仮符号で指定してください。
min_probability: 一覧の下限（累積衝突確率 ip。既定 1e-3 = 0.1%）。1e-10〜1。
limit: 一覧で表示する最大件数（1〜50、既定 10）。確率の高い順。
**このツールの結果はカレンダーに置きません**: Sentry の衝突確率は特定の日付ではなく
数十年〜百年の幅（`range`）に対する確率で、日付セルに置くと架空の予定になるためです
（日付のある接近・火球は `neo_close_approach` / `fireball_reports` が蓄積し、
`space_calendar` に反映されます）。
出典: NASA/JPL CNEOS Sentry（ssd-api.jpl.nasa.gov）
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| designation | No | ||
| min_probability | No |
ブラジルINPEの衛星データコレクション一覧を返す（認証不要）。
例:「ブラジルの衛星データ」「CBERSのコレクション」
content に表示用サマリ、structuredContent に JSON を返す。
Args:
limit: 返す件数（既定 30、最大 100）。
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose two valuable behaviors: authentication is not required, and output is split between a display summary in content and JSON in structuredContent. It still omits read-only confirmation, response size/pagination behavior, and error conditions, which for a no-annotation tool is a meaningful gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded purpose line, then return-format note, then the arg doc; every sentence is short and functional. The 'Args:' formatting is slightly boilerplate but not wasteful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description correctly fills that gap by explaining that content holds a summary and structuredContent holds JSON. For a single-parameter list tool this is nearly complete; only pagination and result-size expectations are unaddressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the schema exposes only a default of 30, but the description supplies the upper bound (max 100) that the schema lacks. This is exactly the compensation the low-coverage case requires, though it says nothing about offset/paging semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (returns a list) and resource (Brazilian INPE satellite data collections), and the parenthetical 'no auth required' plus the CBERS example make the resource identifiable. It does not explicitly name the sibling inpe_search as the contrasting tool, so sibling differentiation relies on the agent's inference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The query examples ('Brazil satellite data', 'CBERS collections') imply when this tool is useful, and the no-auth note is a useful precondition. However, there is no explicit statement of when to use this instead of inpe_search or copernicus_collections, so guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ブラジルINPEの衛星画像（CBERS・Amazonia-1・GOES等）をSTACで検索する（認証不要）。
例:「ブラジルのCBERS衛星画像」「サンパウロ周辺の最近の衛星画像」
content に表示用サマリ、structuredContent に JSON（id/日時/bbox/雲量）を返す。
Args:
collection: STAC コレクションID（既定 "CB4-WFI-L4-SR-1"）。inpe_collections で確認可。
bbox: 空間範囲（"lon_min,lat_min,lon_max,lat_max"）。
datetime: 時間範囲（"YYYY-MM-DD" または "start/end"）。省略で最新。
max_cloud_cover: 雲量上限（%）（eo:cloud_cover を持つ場合）。
limit: 返す件数（既定 5、最大 10）。
| Name | Required | Description | Default |
|---|---|---|---|
| bbox | No | ||
| limit | No | ||
| datetime | No | ||
| collection | No | CB4-WFI-L4-SR-1 | |
| max_cloud_cover | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses no auth requirement, the return shape (display summary in content, JSON with id/日時/bbox/雲量 in structuredContent), the default limit 5 with max 10, that omitted datetime means latest, and that max_cloud_cover only applies when eo:cloud_cover exists. It omits error/pagination/rate-limit behavior, so not a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads purpose and the no-auth constraint, follows with two illustrative examples and the return-shape note, then a compact Args block. Every sentence carries information about routing, format, or defaults; nothing is filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 5-param, no-output-schema, no-annotation tool the description is nearly self-sufficient: params, defaults, return shape, and auth are covered. The remaining gap is routing against the numerous other STAC/imagery siblings, which is only implicitly handled via the INPE framing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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: it documents all five parameters with format and defaults — bbox as "lon_min,lat_min,lon_max,lat_max", datetime as "YYYY-MM-DD" or "start/end" with latest fallback, collection default with a pointer to inpe_collections, max_cloud_cover as % conditional on the field, and limit default/max.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (検索) and a specific resource (ブラジルINPEの衛星画像 via STAC), and names the concrete satellite families (CBERS, Amazonia-1, GOES). This clearly separates it from the many other STAC/imagery siblings such as copernicus_search, uk_stac_search, and generic stac_search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives concrete example queries ("ブラジルのCBERS衛星画像", "サンパウロ周辺の最近の衛星画像"), states that no authentication is required, and routes the agent to inpe_collections for valid collection IDs. It lacks explicit when-not-to-use guidance against neighboring search tools, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ISRO（インド宇宙研究機関）の公式データを返す（認証不要）。
「インドの人工衛星」「ISROのロケット」「インドの宇宙センター」など。
content に表示用サマリ、structuredContent に JSON を返す。
Args:
kind: データ種別
- "spacecrafts": ISROが打ち上げた人工衛星一覧（既定）
- "launchers": ISROのロケット(打ち上げ機)一覧
- "customer_satellites": ISROが外国向けに打ち上げた顧客衛星一覧
- "centres": ISROのセンター/施設一覧
query: 部分一致検索語（例: "cartosat", "chandrayaan"）。省略で全件。
limit: 返す件数（既定 20、最大 100）。
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | spacecrafts | |
| limit | No | ||
| query | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It usefully discloses that no authentication is needed and that results arrive as a display summary in content plus JSON in structuredContent. It does not state that the operation is read-only, nor anything about rate limits, pagination behavior beyond the limit cap, or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the core purpose and authentication fact, then organizes parameters in a clean Args block. Slightly padded by the redundant Japanese example topics line that repeats information implied by the kind values.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-optional-parameter read tool with no output schema and no annotations, the definition covers purpose, auth, return channels, and every parameter's semantics and defaults. Only the absence of any read-only assurance and richer return-shape detail keeps it from being fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must do all the work, and it does: it enumerates all four allowed kind values with the default, explains query as a partial-match term with examples and the omit-for-all behavior, and gives limit's default (20) and maximum (100).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: returns official ISRO (Indian Space Research Organisation) data, with concrete example queries (satellites, rockets, centres). The name plus description cleanly separates it from agency siblings like jaxa_datasets, cnsa_status, and inpe_search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear context for use (ISRO-specific data, no authentication required) and enumeration of the four data kinds, which tells the agent when this tool applies. However, it names no alternative sibling and gives no when-not guidance, so it stops short of explicit routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ISS（国際宇宙ステーション）の現在位置を返し、Googleマップで表示できるURLを生成する。
例:「ISSは今どこ?」「国際宇宙ステーションの現在位置」
content に表示用サマリ＋Googleマップリンク、structuredContent に JSON（緯度経度）を返す。
Returns:
CallToolResult: ISS の現在位置情報。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It usefully discloses the response shape (content = summary + Google Maps link, structuredContent = JSON lat/long), which compensates for the absent output schema, but says nothing about data source, freshness/latency of a 'now' reading, or caching — meaningful gaps for a positional tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose is front-loaded, followed by example queries and return-format notes in a logical order. The trailing 'Returns: CallToolResult: ISS の現在位置情報' largely restates the opening sentence, a minor redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description steps in to explain the return payload (display summary + map link in content, JSON coordinates in structuredContent), which is the main thing an agent needs. It is adequate for a zero-param read tool, though source/freshness details remain unspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so per the rubric the baseline is 4. There is nothing for the description to clarify beyond what the empty schema already conveys.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: returns the ISS's current position and generates a Google Maps URL. The resource (ISS) is inherently distinct from siblings like tiangong_now or sat_ground_track, though the description never names an alternative to route against. Clear but without explicit sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The two example utterances ('Where is the ISS now?') imply when the tool applies, giving an agent intent-matching cues. However, there is no explicit when-not guidance and no mention of the closest alternative (tiangong_now for the Chinese station, satellite_status for general tracking), so usage is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
JAXA Earth の地球観測データセット（ALOS/GSMaP/GCOM等）一覧を返す（認証不要）。
例:「JAXAの地球観測データ」「GSMaP降雨データセット」
content に表示用サマリ、structuredContent に JSON を返す。
Args:
limit: 返すデータセット件数（既定 30、最大 100）。
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does add real behavioral context: 認証不要 (no authentication required) and the return shape (content holds a display summary, structuredContent holds JSON). It does not mention rate limits or pagination behavior for large result sets, so it stops short of full disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Very compact and front-loaded: purpose first, then example queries, then the return contract, then the single argument. Every line earns its place with no repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-optional-parameter listing tool with no output schema and no annotations, the description covers purpose, auth, return channels, and the argument's range. The main missing piece is how it relates to the sibling jaxa_dataset_search.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (the schema documents only the default of 30), so the description must compensate, and it does: it explains limit is the number of datasets returned, with a default of 30 and a maximum of 100. The max value is information the schema entirely lacks.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource (returns a list of JAXA Earth observation datasets) and names concrete examples (ALOS/GSMaP/GCOM), which makes the scope unambiguous. It does not, however, distinguish itself from the sibling jaxa_dataset_search, which an agent must choose between.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The sample queries (「JAXAの地球観測データ」「GSMaP降雨データセット」) imply when the tool is appropriate, giving implied usage guidance. But there is no explicit statement of when to use this list tool versus the sibling jaxa_dataset_search, nor any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
JAXA Earth のデータセットをキーワード検索する（認証不要）。
例:「GSMaPの降雨データ」「ALOSの標高データ」「GCOMの海面水温」
content に表示用サマリ、structuredContent に JSON を返す。
Args:
query: 検索語（例 "GSMaP", "ALOS", "GCOM", "precip", "rain", "FNF", "AW3D"）。
limit: 返す件数（既定 10、最大 100）。
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It usefully discloses that authentication is not required and describes the return structure (content summary plus structuredContent JSON), but omits pagination, rate limits, and error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with purpose, followed by example queries, return format, and an Args section. Every sentence adds useful information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple no-auth search tool with no output schema, the description covers purpose, parameters, and return format well. It lacks only sibling differentiation and pagination behavior, which are minor gaps for calling the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must document parameters. It does so fully: query is explained with domain-specific examples, and limit is documented with its default (10) and maximum (100), adding constraints not present in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('キーワード検索') and resource ('JAXA Earth のデータセット'), plus notes authentication is not required. It does not explicitly differentiate this from the sibling jaxa_datasets or other dataset search tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied through query examples ('GSMaP', 'ALOS', 'GCOM') and the no-auth note. No explicit when-to-use versus alternatives or when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
NASA 火星探査ローバーの現在の状況・天気・最新写真を返す。
「キュリオシティの現在の状況」「火星探査ローバーの今」「パーサヴィアランスの天気」
など。火星の天気（気温・気圧・風速・ソル・地球日付・季節）を認証不要で取得。
Args:
rover: ローバー名（"curiosity"=キュリオシティ既定, "perseverance"=パーサヴィアランス）。
天気フィードが稼働しているのは現状 MSL(キュリオシティ) のみ。
show_photos: 保持（互換用。Mars Rover Photos API は廃止済みのため取得しない）。
| Name | Required | Description | Default |
|---|---|---|---|
| rover | No | curiosity | |
| show_photos | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full behavioral burden, and it does disclose meaningful traits: auth-free access, the fact that only MSL/Curiosity currently has a working weather feed, and that the Photos API is deprecated so photos are not retrieved. It does not describe the return format or rate limits, leaving a small gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose is front-loaded, followed by usage examples and then a tidy Args block separated from the body. It is efficient overall, though the leading 'photos' claim adds a misleading line that a leaner description would have dropped.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description covers what is needed to call the tool and even enumerates returned weather fields (temperature, pressure, wind, sol, Earth date, season). The deprecated-parameter explanation closes the main ambiguity, leaving only minor gaps around response format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 fully: 'rover' is explained with its default ('curiosity') and the caveat that 'perseverance' weather is unavailable, and 'show_photos' is explained as a deprecated compatibility no-op. This adds substantial meaning beyond the bare schema titles and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence gives a specific verb and resource ('NASA Mars rover current status/weather/photos'), which clearly separates it from location-oriented siblings like planetary_rover_location_map. However, the headline promises 'latest photos' while the Args section states photos are no longer fetched, so the stated purpose is partially self-contradictory.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Concrete trigger examples are provided ('Curiosity current status', 'Perseverance weather'), which give clear context for invocation. It also notes no authentication is required. It stops short of naming an alternative tool or stating when not to use it, so exclusions are absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
MAST（NASA/STScI の宇宙望遠鏡アーカイブ）の観測データを検索する（認証不要）。
JWST・ハッブル(HST)・TESS・Kepler・GALEX などの**科学アーカイブ**を、天体名（和名可）・
座標・装置・観測日で横断検索し、観測ID・装置・観測日・校正レベル・データ製品（FITS の
ダウンロードURL）まで返します。NASA の広報画像を探す search_space_images とは別物で、
「その天体がどの装置でいつ観測されたか」を調べる用途です。
例:「M31 を JWST が観測したデータ」「ハッブルが撮ったオリオン大星雲の観測ログ」
「2026年に NIRCam で撮られた画像」「TESS の観測一覧」
Args:
object_name: 天体名（例 "M31", "Orion Nebula", "NGC 300", "アンドロメダ"）。
内蔵/SIMBAD/NED（Sesame）で座標解決し、その周囲をコーン検索します。座標より優先。
解決できない名前は target_name のワイルドカード検索（`*` は `%` 扱い）に切り替えます。
ra: 赤経（度）。object_name 省略時、dec と併用。
dec: 赤緯（度）。
radius: コーン検索の半径（度, 既定 0.05・最大 5）。
mission: ミッション/望遠鏡（例 "JWST", "HST", "TESS", "ハッブル", "ウェッブ", "Kepler"）。
instrument: 装置名の**部分一致**（例 "NIRCam", "MIRI", "WFPC2", "NIRSPEC"）。
product_type: データ種別（image / spectrum / cube / timeseries / catalog、部分一致可）。
start_date: 観測日の下限（例 "2024-01-31"、"2024"）。t_min（MJD）に変換して絞り込み。
end_date: 観測日の上限。
include_products: true で上位3観測のデータ製品（ファイル名・サイズ・DLリンク）も返す。
include_calibration: true で校正用露出（BIAS/DARK 等の intentType=calibration）も含める。
既定 false（科学観測だけ）。
preview_image: true で先頭観測のプレビュー画像（.jpg/.png）を content にインライン表示する
（データ製品を取得し、画像1枚を保存してリンクと併せて返す）。
limit: 返す観測件数（既定 10、最大 50）。
| Name | Required | Description | Default |
|---|---|---|---|
| ra | No | ||
| dec | No | ||
| limit | No | ||
| radius | No | ||
| mission | No | ||
| end_date | No | ||
| instrument | No | ||
| start_date | No | ||
| object_name | No | ||
| product_type | No | ||
| preview_image | No | ||
| include_products | No | ||
| include_calibration | No |
月齢マップ（月の満ち欠けを1か月ぶん並べた図）を返す（認証不要・ローカル計算）。
例:「今月の月齢マップを見せて」「2026年9月の月相カレンダー」「9月の満月はいつ？」
日食の時系列パネル（solar_eclipse_series）と同じ幾何計算を使い、観測地から見た
太陽と月の実位置から「輝面の向き（位置角 PA）」と照度を求め、月円盤を正しい向きに
欠けさせて描きます（月齢から向きを決め打ちしない）。月齢は直前の朔（新月）からの
経過日数、照度は円盤の輝面の割合です。描いた画素から輝面の面積比を測り直し、
申告した照度と突き合わせて自己検証します（figure.verify）。
layout="calendar"（既定）は指定した月の日別セル（日月火水木金土の格子）、
layout="lunation" は1朔望月（朔→朔）を等間隔の時系列パネルで返します。
月齢・照度は地球規模の見え方なので観測地には依存しませんが、日付・時刻・曜日は
現地時間（緯度経度から取得した UTC オフセット）で表示します。
Args:
date: 年月（"2026-09" / "2026年9月"）または年月日（"2026-09-16"）。省略時は現在の月。
place: 観測地（例 "東京","大阪","new york"）。lat/lon 指定時は無視。省略時は東京。
lat: 観測地の緯度。lon と併用時は place より優先。
lon: 観測地の経度。
layout: "calendar"（既定・1か月の格子）または "lunation"（朔望月の時系列パネル）。
days: layout="lunation" のパネル枚数（3〜12・既定8）。calendar では無視。
インライン画像を表示できないハーネス（CLI系・Android系の codex / opencode など）向けに、
content の先頭へ「🖼️ [生成した画像を開く: …](file:///…) ｜ 保存先: `…`」という
アイコン付きリンクを必ず出します（画像は出力ディレクトリに保存し、同じパスを
structuredContent.image_path にも入れます）。
回答時はこのリンクをそのまま提示してください（画像が描画されない環境では唯一の導線）。
| Name | Required | Description | Default |
|---|---|---|---|
| lat | No | ||
| lon | No | ||
| date | No | ||
| days | No | ||
| place | No | ||
| layout | No | calendar |
小惑星・彗星の地球接近（近地球天体の接近イベント）を返す（認証不要・APIキー不要）。
JPL SBDB の接近データ（CAD）から、これから接近する小天体を返します。
**接近は衝突ではありません**。距離は地球中心からの距離（地心距離）で、慣例的に
月距離（1 LD = 384,400 km）も併記します。`neo_today`（今日の接近を api.nasa.gov
から取得）より広い期間・距離を扱え、DEMO_KEY の共有枠も消費しません。
例:「今日/今週地球に接近する小惑星」「危険な小惑星の接近予報」「月距離以内に来る天体」
content に表示用サマリ、structuredContent に JSON を返します。
Args:
days: 何日先までを見るか（1〜365、既定 7）。
max_distance_au: 接近距離の上限（au、既定 0.05 ≒ 19.5 月距離。0.00256 au ≒ 1 LD）。
limit: 表示する最大件数（1〜50、既定 10）。接近時刻の早い順。
hazardous_only: True なら「潜在的に危険な小惑星(PHA)」だけに絞ります。
既知の直径がある天体はそれを、無い天体は絶対等級 H から**推定**した直径
（アルベド0.14 仮定）を返します。接近時刻の不確かさ（3σ）も返します。
出典: NASA/JPL CNEOS SBDB Close-Approach Data API（ssd-api.jpl.nasa.gov）
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | ||
| limit | No | ||
| hazardous_only | No | ||
| max_distance_au | No |
今日地球に接近する小惑星(NEO)を返す。NASA_API_KEY が必要。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden; it usefully discloses that a NASA_API_KEY credential is required, which is real behavioral context. However, it says nothing about rate limits, caching, failure modes, or the shape of the returned data, leaving significant gaps for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short, front-loaded sentences with zero waste: the first states what is returned, the second states the prerequisite. Nothing is padded or redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only lookup with no output schema, the description covers the essential facts: what it returns, the temporal window, and the credential requirement. It could say slightly more about the return content, but it is adequate to call the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, which is the baseline-4 case. The description correctly implies there is nothing to configure, so no parameter explanation is needed or missing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('returns asteroids (NEO) approaching Earth today'), which is unambiguous and distinct from nearby siblings like solar_system_now or sky_map_with_satellites. It does not explicitly name an alternative sibling, but the scope is narrow enough that confusion is unlikely.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The word 'today' implies the temporal scope, but there is no guidance on when to pick this over related tools (e.g. sky_map_with_satellites, planetary_orbiter_track) or any stated exclusions. Usage is left entirely to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
天体の基本情報を SIMBAD（CDS）から取得する（認証不要）。
SIMBAD は天文で最も使われる天体同定データベースで、天体の種別・スペクトル型・
年周視差（距離）・固有運動・視線速度と、周辺天体（円錐検索）を返す。
Sesame（planetary_evidence / mast_observations 等が使う名前解決）は
「名前 → 座標」しか返さないため、このツールは「その天体が何か」を補う。
例:「M31 ってどんな天体？」「シリウスの距離とスペクトル型」「プレアデス星団の周辺天体」
Args:
object_name: 天体名（Messier 番号・英語名・和名・星表名。例 "M31", "Sirius",
"オリオン大星雲", "HD 48915"）。和名は英語名に展開して試す。
neighbors: 0 より大きいと、その天体の周辺天体をこの件数だけ円錐検索して返す。
radius_arcmin: 周辺天体を探す半径（分角, 0.1〜30, 既定 2.0）。
数値引数は不正な値でも既定値に落ちる（例外は返さない）。0 件のときは推測せず、
SIMBAD が持つ候補を提示して停止する。
| Name | Required | Description | Default |
|---|---|---|---|
| neighbors | No | ||
| object_name | Yes | ||
| radius_arcmin | No |
天体（惑星・衛星・小天体・探査機）の文献的な裏づけをまとめて返すツール。
1つの天体名から、①名前解決（Sesame/CDS: 和名→英語名→座標）と、②その天体に関する文献を
**英語圏（OpenAlex・Crossref・NASA NTRS）と日本語（JAXAリポジトリ・J-STAGE・CiNii）の両方**から
集めて、被引用数の多い順に返します。「Wikipedia の説明を、一次文献で裏づけたい／さらに深掘りしたい」
ときに使います。
例:「火星」「エウロパ」「タイタン」「はやぶさ2」「リュウグウ」「ベスタ」
Args:
object_name: 天体・ミッション名（日本語可）。
limit: 返す最大件数（1〜25、既定 8）。
include_japanese: 日本語文献（JAXAリポジトリ・J-STAGE・CiNii）も検索するか（既定 true）。
sort: "citations"（既定・被引用数順）/ "date"（新しい順）/ "relevance"。
planetary_only: OpenAlex の検索を「惑星科学」概念に限定する（既定 **true**）。裸の天体名でも
惑星科学の文献が上位に来ます（実測: "Mars" 単独だと R 言語マニュアルが 35万引用で
1位になるが、限定すると THEMIS / MSL / MAVEN が上位）。銀河・恒星など**太陽系外**の
天体を調べるときは false にするか space_literature_search を使ってください。
⚠️ 返すのは**文献（書誌）**で、観測データではありません。観測は mast_observations /
alma_search / cadc_observations、現在位置は solar_system_now / planetary_orbiter_track です。
⚠️ **太陽系天体は時刻で位置が変わるため固定座標を持ちません**。Sesame が解決できるのは
恒星・銀河・星雲・小惑星などの固定天体です（解決できない場合はその旨を `caveats` に出し、文献
検索は名前で続行します）。
**回答時は DOI リンク・出典の「出典:」行・`caveats` をそのまま提示してください。**
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | citations | |
| limit | No | ||
| object_name | No | ||
| planetary_only | No | ||
| include_japanese | No |
任意の天体（月・火星・水星・タイタン等）を周回する探査機の現在位置と軌道を、その天体の地図にプロットした画像を返す。
例:「LROの現在位置を月面地図で」「MROの火星での現在地」「火星周回機の位置」
「かぐやの月面落下地点は？」（過去機は運用終了を案内し、落点が公表されていれば
その地点を月面図にマーカーで示した図を返す）
「アポロの着陸地点を月面図で」「アポロ11号の着陸地点は？」（sites 指定＝地点マーカー図）
「月に出来た一番新しいクレーターの位置は？」（sites="newcrater"＝新クレーター2地点）
JPL Horizons が返す中心天体の状態ベクトルを IAU 自転モデルで天体固定座標
(緯度経度・高度) に変換し、NASA Trek の等角図法地図に重ねて描画。認証不要。
全面表示にするには span_deg=360（既定 120）。zoom 省略時は全面(1)に自動設定。
Args:
body: 天体名（moon, mars, mercury, venus, titan, vesta, ceres, io, europa,
ganymede, callisto, jupiter, saturn, uranus, neptune, pluto, bennu, ryugu）。
地点が登録されていない天体（ガス惑星・小天体）は sites="map" で全球図を返す。
orbiter: 周回機名（月: lro, gateway／火星: mro, odyssey）または
JPL Horizons の負の天体ID（例 "-74"）。和名（"かぐや"/"あかつき" 等）も可。
過去機（kaguya 等）は運用終了のため現在位置は返さず、**落点が公表されている
機体（かぐや）は落点の緯度経度・時刻・出典を structuredContent.impact_site に返す**。
when: 観測時刻 ISO8601（例 "2026-09-10T00:00:00Z"）。省略で現在。
minutes: 現在位置の前後何分の軌道を表示するか（既定 90, 最大 1440）。
step: トレイルの時間刻み（分。既定 5, 最小 1）。
zoom: 地図ズーム 1〜最大（既定: span_deg>=360 なら1=全面, それ未満は3）。
span_deg: 表示する経度幅（度。360=天体全面, 既定 120, 最大 360）。
out_px: 出力画像の長辺ピクセル（既定 900, 最大 1600）。
sites: **地点マーカー図**にする場合の地点指定（例 "apollo"=アポロ6地点すべて、
"apollo11"="apollo17"=個別、"map"=地図のみ、"newcrater"=月に新しくできた
クレーター2点）。指定すると周回機の計算を行わず、公表座標にマーカーを置いた図を
返す（1地点なら局所図、複数なら天体全面図＋凡例）。旗の位置は公開表に無いため、
注記でその旨を明示する。sites="newcrater" は **マクゲッチン**（2024-04-11〜
05-22 に自然衝突で形成。直径 222 m・1.3536°N 67.1765°E）と **ファルコン9上段の
衝突痕**（2026-08-05 06:35 UTC。直径 18 m・19.4759°N 266.7138°E）を返す。
記録上いちばん新しいのは人工物の衝突（ファルコン9上段, 2026-08-05）、
**自然衝突ではマクゲッチンが最新**（この規模は月で平均 132 年に1回）。
インライン画像を表示できないハーネス（CLI系・Android系の codex / opencode など）向けに、
content の先頭へ「🖼️ [生成した画像を開く: …](file:///…) ｜ 保存先: `…`」という
アイコン付きリンクを必ず出します（画像は %LOCALAPPDATA%\Temp\space_finder_mcp\out に
保存し、同じパスを structuredContent.image_path にも入れます）。
回答時はこのリンクをそのまま提示してください（画像が描画されない環境では唯一の導線）。
| Name | Required | Description | Default |
|---|---|---|---|
| body | No | moon | |
| step | No | ||
| when | No | ||
| zoom | No | ||
| sites | No | ||
| out_px | No | ||
| minutes | No | ||
| orbiter | No | lro | |
| span_deg | No |
任意の天体面を移動する探査ローバーの現在地を、その天体の地図上に示した画像を返す（認証不要）。
例:「パーサヴィアランスの現在地を火星地図で」「キュリオシティが今どこにいるか地図で」
ローバーの現在地データ（現状は 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 にも入れます）。
回答時はこのリンクをそのまま提示してください（画像が描画されない環境では唯一の導線）。
| Name | Required | Description | Default |
|---|---|---|---|
| body | No | mars | |
| zoom | No | ||
| rover | No | perseverance | |
| out_px | No | ||
| span_deg | No |
NASA POWER API で任意地点の過去の気候・太陽エネルギー統計を返す（認証不要）。
例:「東京の過去1年間の日射量」「ハワイの気温データ」「太陽光発電の立地評価」
過去の日別データ（通常数日〜数ヶ月前まで）の期間平均を計算して返す。
Args:
latitude: 緯度（例 東京 35.68）。
longitude: 経度（例 東京 139.69）。
start: 開始日 "YYYY-MM-DD"。省略で1年前。
end: 終了日 "YYYY-MM-DD"。省略で直近データ。
parameters: カンマ区切りのパラメータ（例 "T2M,ALLSKY_SFC_SW_DWN"）。
省略で主要パラメータ（気温・日射量・風速）。
| Name | Required | Description | Default |
|---|---|---|---|
| end | No | ||
| start | No | ||
| latitude | Yes | ||
| longitude | Yes | ||
| parameters | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It discloses that no authentication is required and that data is typically several days to months old and returned as a period average, but omits rate limits, error conditions, and response format details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with purpose, then examples, then parameter details. It is appropriately sized and structured for a data-retrieval tool, with each section serving a clear purpose, though the Japanese prose is slightly repetitive.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description covers the main invocation needs: purpose, authentication, data latency, averaging behavior, and all parameters. It does not describe the exact return fields or units, but is sufficient for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for all five parameters, so the description must compensate. It documents every parameter: latitude and longitude with examples, start/end as YYYY-MM-DD with defaults, and parameters as a comma-separated list with a default set, adding substantial meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (returns) and resource (past climate/solar energy statistics) and specifies the source API (NASA POWER) and no authentication. It distinguishes the tool from space-focused siblings by describing climate/solar data for arbitrary points, but does not explicitly name or contrast with any sibling tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied through examples such as “Tokyo’s solar irradiance over the past year” and “temperature data for Hawaii,” and the data scope is described as period averages of past daily data. There is no explicit guidance on when to use this tool versus alternatives or 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.
みちびき（準天頂衛星システム QZSS）の軌道・補強信号データを取得する（認証不要）。
内閣府の公開アーカイブ API を使う。既定（kind="orbit"）では最新の超速報 SP3
（48 時間分・15 分間隔の精密軌道）を解析し、みちびき各機の現在位置（緯度・経度・
高度）と準天頂軌道の 8 の字の振れ幅、東京からの仰角・方位を返す。
例:「みちびきは今どのあたりにある？」「準天頂衛星の軌道データ」「みちびきの
アルマナック」「安否確認サービス（Q-ANPI）の最新ファイル」
Args:
kind: データ種別。既定 "orbit"（QZU 超速報 軌道 SP3）。他に rapid-orbit /
final-orbit / clock / erp / almanac / ephemeris / ephemeris-qzss /
l1s / l6 / anpi（安否確認サービス）/ naqu。
orbit 以外は最新ファイルの一覧とダウンロードURLを返す（本体は取得しない）。
未知の種別は候補一覧を返して停止する。
count: 一覧に出すファイル数（既定 5, 最大 20）。orbit 以外で使う。
product_id: 特定のファイル ID（例 "qzu24373_18.sp3"）。省略時は最新。
注意: この API は非商用利用のみ（提供元の明記）で、データの正確性は保証されない。
出典: 内閣府 準天頂衛星システム（https://sys.qzss.go.jp/dod/api.html）。
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | orbit | |
| count | No | ||
| product_id | No |
TART オープン電波望遠鏡が「いま観測できる電波源」を返す（認証不要）。
教育・研究用にオープンソース公開されている電波干渉計 TART の可視電波源
カタログから、指定した観測地点の地平線より上にある電波源（GNSS・静止衛星等の
人工衛星）をリアルタイムに取得する。電波天文・衛星追尾の学習用。
例:「いま上空に何が見える？」「ダニーデンの電波望遠鏡が見ている衛星」
「いま観測できる電波源」 認証不要。
Args:
lat: 観測地点の緯度（度）。省略時は TART 本体のある NZ（-45.87）。
lon: 観測地点の経度（度）。省略時は NZ（170.60）。
alt: 観測地点の標高（m, 既定 100）。
elevation: 地平線からの最小仰角（度, 既定 10。高いほど地平線近くを除外）。
limit: 返す件数（既定 15、最大 50）。
| Name | Required | Description | Default |
|---|---|---|---|
| alt | No | ||
| lat | No | ||
| lon | No | ||
| limit | No | ||
| elevation | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose meaningful behavior: no authentication required (stated twice), real-time retrieval, and the default observing site when lat/lon are omitted. It still omits return format, latency/freshness of the catalog, and any rate limits, which is a real gap for an unannotated data tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the one-line answer before elaboration, then an examples block, then an Args block that maps cleanly to the parameters. Slightly repetitive ('認証不要' appears twice) but every sentence carries content, so only minor trimming is possible.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema and no annotations, so the description is the only source of truth. It names the source categories returned but never describes the response shape (fields, ordering, units), leaving the agent guessing about what comes back from this data-returning tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates fully: lat/lon (degrees, default TART site -45.87/170.60), alt (meters, default 100), elevation (minimum elevation above horizon, default 10, higher excludes near-horizon sources), and limit (default 15, max 50). The max-50 cap and the semantic effect of elevation are information not present anywhere in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: it returns radio sources currently observable by the TART open radio telescope, with the source types (GNSS, geostationary satellites) named explicitly. An agent can distinguish this from siblings like sat_tle or sky_map_with_satellites because the scope (real-time over-the-horizon sources from the TART catalog) is stated up front.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives example queries ('what's overhead now?', 'satellites Dunedin's telescope sees') and frames it as educational/research use, which implies when it fits. However, it never names an alternative tool or an explicit when-not-to-use condition, so routing versus sat_tle, iss_now, or sky_map_with_satellites is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
逆引き歴史Q&A — カテゴリ+国 で絞り込んだ最初/記録の宇宙オブジェクトを Wikidata から探す。
例: 「米国で最初に打ち上げた宇宙望遠鏡は?」→ category="宇宙望遠鏡", country="United States"
例: 「日本初の人工衛星は?」→ category="人工衛星", country="Japan"
Args:
category: 探す対象のカテゴリ（宇宙望遠鏡/space probe/satellite/astronaut など）。
launch_date: 打ち上げ日(P619)で並べる場合は True。False にすると対象を列挙する。
country: 国名（例 "United States", "Japan", "India"）。Wikidata 上で Q-id に自動解決する。
country_qid: 国の Q-id を直接指定する場合（例 "Q30"=米国, "Q17"=日本）。country より優先。
limit: 返す件数（既定 5）。
order: "asc"=古い順(最初のもの), "desc"=新しい順。
language: ラベル表示言語（ja/en/zh など）。
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| order | No | asc | |
| country | No | ||
| category | Yes | ||
| language | No | ja | |
| country_qid | No | ||
| launch_date | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full behavioral burden. It discloses the Wikidata source, that launch_date=True sorts by launch date while False lists objects, and that country_qid takes priority over country. However, it omits read-only nature, permissions, rate limits, error behavior, and 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with purpose, then examples, then an Args block. Every part earns its place: the examples illustrate usage and the Args block compensates for the zero schema description coverage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 7-parameter lookup with no annotations and no output schema, the description covers all inputs and key behavioral details. It is nearly complete, but it does not describe the return shape or what fields the Wikidata results contain, which matters because no output schema is provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain all parameters. It does: category with examples, launch_date sorting vs listing, country with example values and auto Q-id resolution, country_qid priority, limit default, order asc/desc meaning, and language for labels.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource: reverse-looking up first/record space objects from Wikidata filtered by category and country, with concrete examples. It is clear what the tool does, though it does not explicitly differentiate itself from the many sibling search/lookup tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The examples ('米国で最初に打ち上げた宇宙望遠鏡は?' → category/country) clearly establish when to use the tool for historical 'first/record' queries. It gives no explicit exclusions or named alternatives among siblings, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Roscosmos オープンデータ STAC のコレクション一覧を返す（認証不要）。
例:「ロシアの気象衛星の公開データ」「Elektro-L の全球画像コレクション」
content に表示用サマリ、structuredContent に JSON（パス/説明/収録期間/観測機器）を返す。
このカタログは /collections を持たないため、カタログ木を辿って列挙します。
Args:
level: 辿る深さ（1=最上位のみ、2=観測機器まで〈既定〉、3=処理レベルまで。最大 3）。
| Name | Required | Description | Default |
|---|---|---|---|
| level | No |
Roscosmos の気象衛星画像（Elektro-L・Arktika-M・Meteor-M）を検索する（認証不要）。
例:「ロシアの静止気象衛星エレクトロLの全球画像」「今日のMeteor-Mモザイク」
content に表示用サマリとクイックルック/データのリンク、structuredContent に JSON
（id/日時/衛星/機器/処理レベル/解像度/bbox/クイックルックURL/GeoTIFF URL）を返す。
⚠️ このカタログは検索APIを持たない静的 STAC のため、`collection` のパスと
日付（UTC）から木を辿って列挙します。日付を省略すると、今日から最大 `lookback` 日
さかのぼって**データがある最新日**を使います。
Args:
collection: コレクションのパス（例 "Electro-L/MSU-GS/L2_RGB_VIS_IR"、
"MM/MSU-MR/L3MD"、"EL_ARCM/MSU-GS/L3BT9"、"Arctic-M/MSU-GS-A/L2_RGB_VIS_IR"）。
roscosmos_collections で確認できます。未知のパスは候補を返して停止します。
date: 日付（"YYYY-MM-DD"・UTC）。省略でデータがある最新日。
limit: 返す件数（既定 3、最大 8）。
lookback: 日付省略時にさかのぼる最大日数（既定 7、最大 30）。
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | ||
| limit | No | ||
| lookback | No | ||
| collection | No | Electro-L/MSU-GS/L2_RGB_VIS_IR |
ロシア（Roscosmos）のロケット打ち上げ予定を返す（ソユーズ・プロトン・アンガラ等）。
Launch Library 2 を「search=Roscosmos」で絞り込み、ソユーズ（Soyuz）による
Progress（補給）・Soyuz MS（有人）・Luna 等の打ち上げを取得する。
ロシア直のオープンAPIは存在しないため（Roscosmos REST は404）、グローバル集約API経由。
認証不要。content に表示用サマリ、structuredContent に JSON を返す。
Args:
limit: 返す件数（既定 8、最大 15）。
status: 状態で絞り込み（例 "Go for Launch"）。省略で全状態。
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| status | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. It discloses the data source (Launch Library 2 with search=Roscosmos), that authentication is not required, and the return format (content summary plus structuredContent JSON). It lacks rate-limit or error-handling details, but covers key behavioral traits well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the purpose, then provides source/auth/output context, then a compact Args section. Every sentence contributes useful information, though the justification for using the aggregator API is slightly verbose and could be tightened.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with two optional parameters and no output schema, the description covers purpose, data source, authentication, return format, and parameter behavior. Minor gaps like error handling or pagination are unlikely to impede correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 documents both parameters: limit (default 8, maximum 15) and status (filter by state, example "Go for Launch", omitted returns all states). This adds meaningful constraints and semantics beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (returns) and resource (Russian/Roscosmos rocket launch schedule), naming example vehicles (Soyuz, Proton, Angara) and the data source. An agent can immediately tell this is the Russia-focused launch tool, distinct from global or other national launch siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the country scope: use this for Russian/Roscosmos launches. However, it never explicitly states when to use it versus siblings like upcoming_launches or china_launches, nor does it provide exclusions. The note about no direct Russian API explains the source choice but is not usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
世界気象機関（WMO）OSCARの衛星カタログから、気象・地球観測衛星の運用ステータスを返す。
ロシアのMeteor-M・Resurs・Kanopus等、世界中の気象衛星の運用状況・軌道・打ち上げ日を確認できる。
例:「ロシアの気象衛星」「Meteor-Mの運用状況」「世界の気象衛星一覧」
content に表示用サマリ、structuredContent に JSON を返す。
カタログ**全件（約1,000件）を走査**し、query は一致度順（acronym の完全/前方一致 →
名称の語境界一致 → 名称の部分一致のみ）に並べて返す。`query="meteor"` のような入力でも
Meteor-M が「Meteorological」を含む他衛星に埋もれない。一致件数の内訳
（acronym・語境界 / 部分一致のみ）と、取得できなかったページ数も数値で返す。
初回の呼び出しは全件取得のため40秒ほどかかります（1ページ30件固定・約4.5秒 ×
35ページ）。取得したカタログはディスクにも保存するため、以後はプロセスを
再起動しても即時に応答します（24時間で更新）。
Args:
query: 検索語（衛星名・略称）。**和名は英語名に自動展開**する
（"ひまわり"→himawari, "だいち"→alos, "宇宙ステーション"→iss）。
例 "meteor", "resurs", "goes", "himawari", "だいち"。
agency: 機関名（例 "Roscosmos", "NOAA", "EUMETSAT", "JAXA"）。
limit: 返す件数（既定 10、最大 20）。
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | No | ||
| agency | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the behavioral disclosure burden. It discloses the full-catalog scan (~1,000 entries), match ordering for queries, the ~40-second first-call latency, disk caching, 24-hour refresh behavior, and the content vs. structuredContent return split.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with purpose and structured with examples, behavioral notes, and an Args section. Although long, every sentence provides actionable information for correct invocation, especially the performance caveat and matching behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description is remarkably complete: it explains return formats, query semantics, parameter constraints, performance expectations, and edge-case reporting such as unmatched pages. An agent has enough context to invoke the tool correctly and interpret its results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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: query is explained with matching rules and Japanese-to-English expansion, agency is given with concrete examples, and limit is fully specified with default and maximum values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('返す' / returns), a clear resource (WMO OSCAR satellite catalog), and a distinct domain (weather and Earth observation satellite operational status). It includes concrete examples and differentiates itself from sibling tools focused on TLE, positions, or imagery.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use the tool: when querying operational status, orbit, or launch dates of WMO OSCAR catalog satellitesтное. It provides example queries and parameter usage, though it does not explicitly name alternative tools or state 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.
任意の人工衛星の現在位置と地上軌道を地球地図にプロットした画像を返す。
例:「ISSの現在位置を地球地図で」「ひのでの位置を地図で」「ハッブルの軌道」
CelesTrak の最新 TLE（遮断中は代替源の公開ミラー。本文と structuredContent.tle_source に
実際の出典を表示）を Skyfield（SGP4）で伝播し、衛星の真下の点（緯度経度・高度）
とその前後の軌道トレイルを NASA Blue Marble 地球地図に重ねる。認証不要。
精度: 軌道トレイルは step 分刻み（デフォルト 1分）で描画し、経度±180度境界で
線を分割するため、世界地図上で正確に表示される。subpoint() は地球自転・歳差・
極運動を考慮した真の地上点を返す。
Args:
norad_id: NORAD カタログ番号（例 25544=ISS, 29479=ひので）。name より優先。
name: 衛星名または省略名（例 "iss", "hubble", "hinode"）。既知の衛星は
ID に解決、それ以外は TLE を直接検索。
when: 観測時刻 ISO8601（例 "2026-09-10T03:30:00Z"）。省略で現在。
minutes: 現在位置の前後何分の軌道を表示するか（既定 45、最大 1440=24時間）。
準天頂衛星(みちびき)の8の字軌道を見るには 720 前後を指定。
step: トレイルの時間刻み（分。既定 1、最小 0.5）。小さいほど滑らか。
out_px: 出力画像の幅ピクセル（既定 1200、最大 2048）。
インライン画像を表示できないハーネス（CLI系・Android系の codex / opencode など）向けに、
content の先頭へ「🖼️ [生成した画像を開く: …](file:///…) ｜ 保存先: `…`」という
アイコン付きリンクを必ず出します（画像は %LOCALAPPDATA%\Temp\space_finder_mcp\out に
保存し、同じパスを structuredContent.image_path にも入れます）。
回答時はこのリンクをそのまま提示してください（画像が描画されない環境では唯一の導線）。
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | ||
| step | No | ||
| when | No | ||
| out_px | No | ||
| minutes | No | ||
| norad_id | No |
任意の人工衛星（ISS・ハッブル・気象衛星・中国宇宙ステーション等）の軌道要素(TLE)を返す。
例:「ISSの軌道要素」「ハッブル宇宙望遠鏡のTLE」「気象衛星の軌道」
認証不要。CelesTrak（NORADカタログ）から取得。**CelesTrak が遮断中（403・接続不可）の
ときは認証不要の公開ミラー（tle.ivanstanojevic.me → db.satnogs.org）へ自動で切り替え**、
実際の出典を structuredContent.source / 本文の「出典:」行に出します（`group=` の
グループ検索は代替源に無いため、遮断中はその旨を案内します）。
content に表示用サマリ、structuredContent に JSON（軌道パラメータ）を返す。
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）。
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | ||
| group | No | ||
| limit | No | ||
| norad_id | No |
宇宙関連の音声を検索し、再生可能な音声URLを返す。
content には表示用サマリ、structuredContent にはJSON（タイトル/再生URL/種別/尺など）を返す。
「宇宙の音・惑星の音・打ち上げの効果音」のような短い音声を探すなら kind="sound_effect"、
「ポッドキャスト・解説・飛行士インタビュー」のような長い音声なら kind="podcast" を指定。
既定 kind="auto" は両方を探す。
例:
- 「スプートニクの音を聞きたい」→ query="sputnik", kind="sound_effect"
- 「アポロのポッドキャスト」→ query="apollo", kind="podcast"
- 「火星の音」→ query="mars", kind="auto"
Args:
query: 検索語（juno, saturn, sputnik, launch, apollo など）。
limit: 返す件数（既定 3、最大 10）。
kind: "auto"(両方) / "podcast"(NASA Image Library の長尺トーク・解説) /
"sound_effect"(短い宇宙の音・効果音)。
content の各項目には、メディア本体より前に「🖼️ [画像を開く: タイトル](URL)」
「🎧 [音声を開く: タイトル](URL)」「🎬 [動画を開く: タイトル](URL)」というアイコン付き
リンクを出します（インライン表示を描画できない CLI/Android 系ハーネスでも開けるように）。
回答時はこのリンクをそのまま提示してください。
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | auto | |
| limit | No | ||
| query | Yes |
惑星・人工衛星・宇宙ミッションの画像を NASA Image & Video Library から検索し表示する。
LLM向けに structuredContent へJSON（title/date/nasa_id/image_url など）を返し、
content にはチャット表示用のサマリ+インライン画像を返す。
例: 「火星の画像を見せて」「ハッブルの写真」「アポロの画像」
Args:
query: 検索語（mars, jupiter, hubble, apollo など英語が確実）。
limit: 返す画像件数（既定 3、最大 10）。
show_inline: 画像をチャットにインライン表示するか（既定 True）。
inline_max: チャットに埋め込む画像の枚数（既定 1、最大 5）。
転送量を抑えるため既定は先頭1枚のみ。全件のURLは
structuredContent.results[].image_url に入る。
content の各項目には、メディア本体より前に「🖼️ [画像を開く: タイトル](URL)」
「🎧 [音声を開く: タイトル](URL)」「🎬 [動画を開く: タイトル](URL)」というアイコン付き
リンクを出します（インライン表示を描画できない CLI/Android 系ハーネスでも開けるように）。
回答時はこのリンクをそのまま提示してください。
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | ||
| inline_max | No | ||
| show_inline | No |
宇宙関連の動画（打ち上げ・ミッション映像・解説など）を検索し、再生用MP4 URLを返す。
content には表示用サマリ＋ポスター画像(インライン)を返し、
structuredContent にはJSON（タイトル/再生URL/解像度別URL/字幕など）を返す。
動画自体は巨大なのでbase64埋め込みせず、クライアント/LLMがURLから再生する。
例: 「火星の動画」「ロケット打ち上げ映像」「ハッブルの映像」
Args:
query: 検索語（mars, launch, hubble, artemis など英語が確実）。
limit: 返す動画件数（既定 3、最大 10）。
show_poster: ポスター画像をチャットにインライン表示するか（既定 True）。
content の各項目には、メディア本体より前に「🖼️ [画像を開く: タイトル](URL)」
「🎧 [音声を開く: タイトル](URL)」「🎬 [動画を開く: タイトル](URL)」というアイコン付き
リンクを出します（インライン表示を描画できない CLI/Android 系ハーネスでも開けるように）。
回答時はこのリンクをそのまま提示してください。
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | ||
| show_poster | No |
東京（または指定地）の空を地上から見上げた図（恒星・惑星・天の川・人工衛星）を返す。
例:「東京の空に惑星と人工衛星を重ねた図」「今見えるISSを星空マップで」「木星はどこに見える？」
天体位置は JPL de421 + Skyfield、衛星位置は CelesTrak TLE + SGP4 で実測計算。
学生・観賞用途では視認性の高い Pillow 版(既定)を推奨。正確な座標プロットが必要な場合は
matplotlib 版も選択できる。
engine で描画方法を選択:
- "ground"(既定): 地上から見上げた空（正距円筒・方位-高度）。地平線が下・方位が横軸で、
下部に街並みと方位目盛り、恒星は Hipparcos 実星表（Vmag<8.5）、天の川は銀経・銀緯から
描く。太陽高度で昼/夕方/朝焼け/薄明/夜の空色と見える限界等級が変わる。今は見えない
惑星・主要恒星・銀河は○の輪郭で位置だけを示す（昼でも位置が分かる）。
span / az0 / lp / show はこのエンジンで使う。
- "simple": 従来の天頂中心の円形図（Pillow・実写背景の簡易合成）。
- "accurate": 従来の正確な星図（matplotlib 極座標）。座標グリッド・軌道予測線を
精確表示（科学・教育の詳細用途向け）。
画像は content に base64 インライン表示、座標は structuredContent に JSON。
Args:
place: 観測地（例 "東京","大阪","new york"）。lat/lon 指定時は無視。省略時は東京。
lat: 観測地の緯度。lon と併用時は place より優先。
lon: 観測地の経度。
when: 観測時刻 ISO8601（例 "2026-09-09T11:00:00Z"）。省略時は現在時刻。
engine: "ground"(既定/地上視点パノラマ) / "simple" / "accurate"。
span: 横方向の視野（度, 30〜360）。360 で全天。engine="ground" のみ。
az0: 左端の方位（度）。span=180, az0=225 なら南西→北東。engine="ground" のみ。
lp: 光害の程度 "city"（都心）/ "suburb"（郊外, 既定）/ "dark"（山間・離島）。ground のみ。
show: 依頼表示する天体名（カンマ区切り。例 "木星,ベガ,M31"）。省略時は主要天体すべて。ground のみ。
インライン画像を表示できないハーネス（CLI系・Android系の codex / opencode など）向けに、
content の先頭へ「🖼️ [生成した画像を開く: …](file:///…) ｜ 保存先: `…`」という
アイコン付きリンクを必ず出します（画像は %LOCALAPPDATA%\Temp\space_finder_mcp\out に
保存し、同じパスを structuredContent.image_path にも入れます）。
回答時はこのリンクをそのまま提示してください（画像が描画されない環境では唯一の導線）。
| Name | Required | Description | Default |
|---|---|---|---|
| lp | No | suburb | |
| az0 | No | ||
| lat | No | ||
| lon | No | ||
| show | No | ||
| span | No | ||
| when | No | ||
| place | No | ||
| engine | No | ground |
日食の時系列パネル画像（太陽が月に欠ける過程）を返す（認証不要）。
例:「2035年9月2日の皆既日食を画像で」「東京で見える次の日食」「2019年の部分日食の進行」
指定した観測地・日付で太陽と月の視位置を JPL DE421 + Skyfield で実測計算し、
食の始まり〜最大〜終わりを複数パネルに並べて合成。月の位置角も正確に反映。
date を省略した場合は、その観測地で「これから起こる次の日食」を約4年（1400日）先まで自動検索（800日では可視の食が無い観測地があるため）。
描画するのは、その観測地で太陽が地平線より上にある時間帯だけ。最大食分も可視区間の中で
求める。全日食が地平線下なら「見えません」と明示して図は返さない（見えない食を図にして
誤解させないため。日付をまたぐ食も前後6時間まで含めて計算する）。
max_magnitude=True で最大食のみの単一画像を返す（進行でなく最も欠けた瞬間だけ見たい時）。
Args:
date: 日付（例 "2035-09-02" / "2035/09/02" / "2035年9月2日"）。省略時は次の日食を検索。
place: 観測地（例 "東京","大阪","new york"）。lat/lon 指定時は無視。省略時は東京。
lat: 観測地の緯度。lon と併用時は place より優先。
lon: 観測地の経度。
max_magnitude: True で最大食のみの単一パネルを返す（既定 False=時系列）。
インライン画像を表示できないハーネス（CLI系・Android系の codex / opencode など）向けに、
content の先頭へ「🖼️ [生成した画像を開く: …](file:///…) ｜ 保存先: `…`」という
アイコン付きリンクを必ず出します（画像は %LOCALAPPDATA%\Temp\space_finder_mcp\out に
保存し、同じパスを structuredContent.image_path にも入れます）。
回答時はこのリンクをそのまま提示してください（画像が描画されない環境では唯一の導線）。
| Name | Required | Description | Default |
|---|---|---|---|
| lat | No | ||
| lon | No | ||
| date | No | ||
| place | No | ||
| max_magnitude | No |
太陽を中心とした太陽系の惑星・小惑星・探査機・彗星の現在位置図を返す（認証不要）。
例:「太陽系を上から見た図」「今の惑星の位置」「イトカワの今の位置を図で」
「ボイジャー1号の現在位置を図で」「ハヤブサ2は今どこ？」「ハレー彗星は今どこ？」
「紫金山・アトラス彗星の位置」
惑星(8惑星＋冥王星)は JPL DE421 暦表、小惑星は JPL SBDB 軌道要素のケプラー伝播、
遠方探査機(ボイジャー/パイオニア等)は JPL Horizons の状態ベクトル、
彗星は周期彗星(ハレー等)を SBDB 軌道要素、非周期C/彗星を Horizons 状態ベクトルで計算。
学生・観賞用途では視認性の高い Pillow 版(既定)を推奨。対数縮尺で内惑星から
百数十AUの遠方天体までを一枚に収める。探査機・遠方彗星を指定すると表示範囲を
自動拡張し、それぞれ色付き菱形マーカー・シアン色の尾を持つ彗星マーカーで強調する。
遠方天体は線形の matplotlib 版では枠外のため、指定時は対数縮尺の Pillow 版を自動選択。
engine で描画方法を選択:
- "simple"(既定): Pillow による視認性重視の合成。惑星を色アイコン、小惑星を緑十字、
探査機を色付き菱形、彗星をシアンの核＋尾で強調。距離は対数縮尺。
- "accurate": matplotlib による線形距離の正確な俯瞰図（近距離のみ）。
**「1光日」（光が24時間で進む距離＝173.1446 AU＝25,902,068,371 km）を図に重ねる**:
真距離の目安として破線の1光日リングを描き、1光日に達していない探査機を指定したときは
それぞれの探査機について**黄道面投影**での1光日リングと、到達時の方向（◇＝黄経/黄緯）・到達予測日を
出す。全リングは structuredContent.light_day.projected_rings と figure.verify.light_day.rings に列挙する。
俯瞰図は正射影なので真距離の円と投影の円は別物で、その旨は figure.notes に
数値付きで入る（重ねて読むと誤る）。structuredContent.probes[] に light_days（何光日）・
light_hours（光の所要時間）・to_light_day_au（1光日までの残り）・light_day_eta_date /
light_day_eta_method（到達予測＝現在の日心視線速度による線形外挿・数日の幅あり）が入る。
**距離の基準は日心距離（真距離）で統一**している（地心距離での1光日は地球の公転で
最大 ±1 AU 変わり日付が異なる）。
画像は content に base64 インライン表示、座標は structuredContent に JSON。
structuredContent.figure には「この図をどう描いたか」の注記（figure/1）が入る。
⚠️ figure.notes は図の誤読を防ぐための注記なので、要約・言い換えせずそのまま引用すること。
Args:
when: 時刻 ISO8601（例 "2026-09-09T11:00:00Z"）。省略時は現在時刻。
asteroid: 小惑星（例 "イトカワ"/"itokawa"/"25143", "ベンヌ", "アポフィス"）。view="asteroid_orbit" では楕円軌道全体を描く。
asteroid2: 2つ目の小惑星。
probe: 遠方探査機（例 "ボイジャー1号"/"voyager1"/"パイオニア10号"/"はやぶさ2"/
"hayabusa2"）。1光日に達していない探査機では、投影での1光日リング・到達時の
方向（◇）・到達予測日も図と structuredContent に出る。
はやぶさ2 は JPL Horizons ID -37。
probe2: 2つ目の探査機。
comet: 彗星（例 "ハレー彗星"/"halley"/"1P", "エンケ彗星", "67P",
"紫金山・アトラス"/"C/2023 A3", "ラブジョイ"/"C/2014 Q2"）。
comet2: 2つ目の彗星。
engine: "simple"(既定/Pillow) / "accurate"(matplotlib)。
view: "system"(既定)=太陽系俯瞰図 / "comet_orbit"=彗星の軌道面ビュー /
"asteroid_orbit"=小惑星の閉じた楕円軌道面ビュー /
"apparition"=彗星の見え方チャート（地心距離・日心距離・予想光度・太陽離角の
推移。comet の指定が必須で、1天体ずつ）。
comet_orbit は comet の指定が必須で、彗星自身の軌道面を真横から見た図
（太陽＝円錐曲線の焦点）を返す。e>=1 の C/彗星は閉じない双曲線の枝として描く。
asteroid_orbit は asteroid の指定が必須で、JPL SBDB の osculating elements に基づく
小惑星の楕円全体と指定時刻の現在位置を軌道面から描く（1天体ずつ）。
**comet にカンマ区切りで複数（または comet2 を併用、最大4天体）指定すると、
1彗星=1パネルで並べた1枚の画像**を返す（パネルごとに軌道面と縮尺が異なる。
その旨は figure.notes に数値から生成して入る）。
days: view="apparition" の表示日数（1〜3650、既定 180）。今日の 30 日前から
days 日後までを描く（直前に過ぎた近日点・最接近も見えるようにするため）。
route: view="system" で、指定した彗星の**通過経路（軌道）を俯瞰図に重ねる**
（破線）。近日点・遠日点には◇と日付を添える。**近日点の日付は SBDB の2体近似に
加えて JPL Horizons の n 体解も併記する**（2体近似はずれることがある。ハレー
彗星では約164日）。既定 False。
線形の "accurate" では形は本当の軌道と一致するが、対数縮尺の "simple" では
線の長さと曲率が実際の楕円と一致しない（その旨は figure.notes に入る）。
形そのものを見たいときは view="comet_orbit"。
range_au: view="system" の表示範囲（太陽からの距離の上限）。既定 0＝自動
（対数版は 60 AU 起点、線形版は ±45 AU 起点で、遠方の天体・経路に合わせて拡張）。
**数値（AU）でも天体名でも指定できる**（「火星まで」「木星まで」のように
LLM が判断して縮尺を選ぶ用途を想定）。
数値: 10=土星(9.58 AU)より内側／2=火星まで／5.62=木星まで／30=海王星まで。0.5 未満はエラー。
天体名: "火星"（→1.65 AU）／"木星"（→5.62）／"土星"（→10.35）／"海王星"（→32.5）／
"冥王星"／英語名（mars, jupiter…）／"小惑星帯"／"内惑星"／"外惑星"。
その呼び出しで指定した小惑星・彗星・探査機の名前も使える（例: asteroid="イトカワ"
に対して range_au="イトカワ"）。**天体名は「その天体の軌道の円が入る」ように
長半径×1.08 で決める**（決め方は figure.notes と structuredContent.range_resolved に
数値付きで出る）。
"fit"（＝指定天体に合わせる）: その呼び出しで指定した天体・経路がすべて入る範囲
（最大値×1.10、下限 1.2 AU）。天体を指定せず "fit" にすると自動（45 AU 起点）。
解決できない名前は**推測せずエラーで候補一覧を返す**。
**範囲外の天体・目印・軌道の円は描かず**、figure.notes と structuredContent
に出典付きで列挙する（黙って消さない）。対数版は下限も範囲に合わせて下がる。
インライン画像を表示できないハーネス（CLI系・Android系の codex / opencode など）向けに、
content の先頭へ「🖼️ [生成した画像を開く: …](file:///…) ｜ 保存先: `…`」という
アイコン付きリンクを必ず出します（画像は %LOCALAPPDATA%\Temp\space_finder_mcp\out に
保存し、同じパスを structuredContent.image_path にも入れます）。
回答時はこのリンクをそのまま提示してください（画像が描画されない環境では唯一の導線）。
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | ||
| view | No | system | |
| when | No | ||
| comet | No | ||
| probe | No | ||
| route | No | ||
| comet2 | No | ||
| engine | No | simple | |
| probe2 | No | ||
| asteroid | No | ||
| range_au | No | ||
| asteroid2 | No |
宇宙・天文イベントの月間カレンダー（打ち上げ・天文現象・公開イベント・自分の予定）を画像とJSONで返す。
打ち上げは Launch Library 2 の API（月範囲）から、日付が確定した行だけを日付セルに置きます。
天文現象は JPL DE421 + Skyfield のローカル計算（月相・二十四節気・惑星の衝/合/内合・最大離角・
日食月食・流星群）、公開・イベントは国立天文台のイベント一覧と JAXA の施設公開（一般公開・特別公開）、
自分の予定はローカルの蓄積ストア
（`calendar_event_add` で追加）から取ります。取得結果は蓄積ストアに溜め、要求月 M に対して
窓 [M-1, M+2] を確保して**未取得・期限切れの月だけ**取りに行きます（月が進むと差分は1ヶ月）。
**回答時は content に含まれる画像リンク（🖼️ [◯◯を開く](file:///…)）をそのまま提示してください。**
**`figure.notes` は要約・言い換えせず、そのまま引用してください。**
Args:
year: 対象年（既定: 観測地の今年）。
month: 対象月 1〜12（既定: 観測地の今月）。
place: 基準地（既定 東京）。任意の地名をジオコーダで解決し、その現地時刻で描きます。
kinds: 表示するカテゴリ（カンマ区切り）: user/launch/sky/neo/fireball/public/holiday。
all で全部。**neo（小惑星接近）と fireball（火球観測）は、`neo_close_approach` /
`fireball_reports` を呼んで蓄積されたぶんだけ表示されます**（カレンダー自身は
JPL を叩かないので、未取得の月は「イベントが無い」のではなく「まだ蓄積が無い」）。
lat: 緯度（place の代わりに数値で指定）。
lon: 経度（同上）。
| Name | Required | Description | Default |
|---|---|---|---|
| lat | No | ||
| lon | No | ||
| year | No | ||
| kinds | No | all | |
| month | No | ||
| place | No | 東京 |
宇宙・惑星科学の一次文献（論文・技術報告）を横断検索して根拠を返すツール。
惑星・衛星・小天体・探査ミッションについて「その記述の根拠となる文献」を DOI 付きで返します。
Wikipedia / Wikidata の要約ではなく、**査読論文・技術報告そのもの**を根拠として提示したいときに使います。
例:「火星の大気流出の研究」「Europa 地下海の証拠」「金星のホスフィン」「はやぶさ2 リュウグウ」
「月の永久影の水氷」「惑星形成 シミュレーション」
Args:
query: 検索語（天体名・現象・ミッション名など）。**日本語可**。
sources: 検索先。"auto"（既定・日本語クエリなら JAXAリポジトリ・J-STAGE・CiNii＋OpenAlex、
英語クエリなら OpenAlex・Crossref・NASA NTRS）/"all"/カンマ区切りで明示。
指定できる名前: openalex, crossref, ads, semanticscholar, wos, ntrs,
jaxa_repo, jstage, cinii, zenodo, datacite
limit: 返す最大件数（1〜25、既定 10）。
year_from: 出版年の下限（例 2015）。
year_to: 出版年の上限（例 2026）。
sort: "relevance"（既定）/ "citations"（被引用数順）/ "date"（新しい順）。
min_citations: 被引用数の下限。⚠️ 被引用数を持たないソース（NTRS・JAXAリポジトリ・
J-STAGE・CiNii）の文献は除外されます。
open_access_only: OpenAlex でオープンアクセス文献だけに絞る（既定 false）。
include_abstract: 要旨を返すか（既定 true）。長さを抑えたいときは false。
planetary_only: OpenAlex の検索を「惑星科学」概念（`concepts.id:C152551177`）に限定する
（既定 false）。**裸の天体名（例「火星」）で関連性を上げたいときに true**にすると、
全文一致で拾われる無関係な高被引用論文（実測: "Mars" で R 言語マニュアル）を排除できます。
銀河・恒星など太陽系外の天体では false のままにしてください。
⚠️ 返すのは**文献（書誌）**であり観測データではありません。観測（画像・スペクトル）は
mast_observations / alma_search / cadc_observations を使ってください。
⚠️ OpenAlex / Crossref は**日本語クエリを解釈できない**ため、日本語入力は語彙辞書で英語へ置換して
から投げます（無関係な文献が返るのを防ぐため。`translation` に置換内容を入れます）。日本語文献は
JAXAリポジトリ・J-STAGE・CiNii が得意です。
⚠️ APIキーが必要なソース（ADS_API_KEY / S2_API_KEY / WOS_API_KEY）は未設定ならスキップし、
理由を `sources[].note` に残します（結果は残りのソースで返します）。
**回答時は DOI リンクと「出典:」行をそのまま提示してください。要旨は要約せず、そのまま引用して
ください**（図の注記と同じく、LLM が書き換えると一次情報と食い違うため）。
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | relevance | |
| limit | No | ||
| query | No | ||
| sources | No | auto | |
| year_to | No | ||
| year_from | No | ||
| min_citations | No | ||
| planetary_only | No | ||
| include_abstract | No | ||
| open_access_only | No |
NASA DONKI の宇宙天気（太陽フレア・CME・地磁気嵐・太陽粒子現象）を返す。
天体観測や通信・衛星運用に影響する太陽活動を確認できる。
**DONKI（ccmc.gsfc.nasa.gov/DONKI-API・認証不要・専用のレート枠）が障害のときは、認証不要の NOAA SWPC（Kp・NOAA スケール・
GOES X線・フレアイベント（直近7日）・太陽風・陽子・警報・黒点相対数）に自動で切り替えて返す**（どちらの出典かを
content と structuredContent.source に明記する）。API キーは不要（`NASA_API_KEY` は apod / neo_today のみで使用）。
**予報（`kind="forecast"`）は DONKI に存在しない**（DONKI は観測・警報の記録）ので、
フレア発生確率・活動領域別確率・NOAA 3日予報を返す NOAA SWPC を**通常経路**として使う
（障害時のフォールバックとは別物）。
例:「最近の太陽フレア」「CME(コロナ質量放出)の情報」「地磁気嵐は起きてる?」
content に表示用サマリ、structuredContent に JSON を返す。
Args:
kind: データ種別
- "all": 太陽フレア・CME・地磁気嵐・太陽粒子をまとめて表示（既定）
- "flare": 太陽フレア(FLR)
- "cme": コロナ質量放出(CME)
- "gst": 地磁気嵐(GST)
- "sep": 太陽高エネルギー粒子現象(SEP)
- "forecast": **予報**（フレアの発生確率 C/M/X 級・活動領域（黒点群）別の確率・
NOAA 3日予報の予想最大 Kp と S/R スケール確率・公式の根拠文）。
**DONKI は予報を提供しないため NOAA SWPC から取得**する（出典を明記）
start_date: 開始日（YYYY-MM-DD）。省略時は既定（最近）。**forecast では使わない**。
end_date: 終了日（YYYY-MM-DD）。省略時は既定。**forecast では使わない**。
limit: 各カテゴリの返す件数（既定 10、最大 20）。forecast では活動領域の表示数。
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | all | |
| limit | No | ||
| end_date | No | ||
| start_date | No |
AWS Earth Search で利用可能な衛星データコレクション一覧を返す（認証不要）。
例:「AWSの衛星データ」「利用できるLandsatコレクション」
Args:
（なし）
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden itself. It usefully discloses that no authentication is required, which is real behavioral context, and "returns a list" implies a read-only, non-destructive call. However it says nothing about the return shape, result volume, or pagination for a collection-listing endpoint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Short and front-loaded: the core purpose and source come first, with examples and the auth note immediately after. The trailing "Args: (none)" is redundant given the empty schema and slightly dilutes an otherwise tight definition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only listing tool with no output schema, the description covers what it returns, from which source, and that no auth is needed. About the only missing element is guidance on what the returned collection identifiers are for (e.g. feeding stac_search), which would strengthen routing to the sibling search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters and the schema is empty, so the baseline of 4 applies. The description's "Args: (none)" simply restates what the schema already shows, adding no extra meaning, but there is nothing to document.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource (returns a list of satellite data collections) scoped to a named source, AWS Earth Search, which partly separates it from the many sibling *_collections tools. It could go further by explicitly contrasting with uk_stac_collections, copernicus_collections, inpe_collections, and eodashboard_collections, but the named endpoint is enough for an agent to distinguish it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The examples ("AWS satellite data", "available Landsat collections") imply when an agent would reach for this tool, but there is no explicit when-to-use vs when-to-use-an-alternative guidance and no exclusions. Usage is inferable rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
AWS Earth Search で衛星データ（Sentinel-2 / Landsat / NAIP / DEM）をSTAC検索する（認証不要）。
例:「東京のLandsat画像」「関東のSentinel-2の雲が少ない画像」
場所は bbox（"lon_min,lat_min,lon_max,lat_max"）または place（地名）。
content に表示用サマリ、structuredContent に JSON（id/日時/雲量/bbox/アセットURL）を返す。
Args:
collection: コレクションID（既定 "sentinel-2-l2a"）。stac_collections で確認可。
例: "landsat-c2-l2", "sentinel-2-l1c", "sentinel-1-grd", "naip"。
bbox: 空間範囲（"lon_min,lat_min,lon_max,lat_max"）。
place: 地名（bbox より優先。Open-Meteo のジオコーディングで解決）。
datetime: 時間範囲（"YYYY-MM-DD" または "start/end"）。省略で最近。
max_cloud_cover: 雲量上限（%）（eo:cloud_cover を持つ場合）。
limit: 返す件数（既定 5、最大 10）。
| Name | Required | Description | Default |
|---|---|---|---|
| bbox | No | ||
| limit | No | ||
| place | No | ||
| datetime | No | ||
| collection | No | sentinel-2-l2a | |
| max_cloud_cover | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It usefully declares authentication-free operation, describes the return shape (display summary in content, JSON in structuredContent with id/date/cloud cover/bbox/asset URL), notes that max_cloud_cover only applies when eo:cloud_cover exists, and sets a hard limit of 10. Missing details like rate limits or error behavior keep it from a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose, then examples, location handling, return format, and finally a clearly labeled Args section. Each part is useful, though the description is somewhat long; it remains well-organized and free of filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given six parameters, no annotations, no output schema, and 0% schema coverage, the description is largely complete: it covers purpose, usage examples, alternatives, return structure, auth, and every parameter. It omits potential error cases or pagination behavior, but no output schema exists to cover those, so the gap is minor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by documenting all six parameters: collection (default and examples), bbox (format), place (priority and geocoding source), datetime (accepted formats and default recency), max_cloud_cover (meaning and applicability condition), and limit (default 5, maximum 10).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (STAC検索する) and resource (衛星データ from AWS Earth Search), names supported collections, and explicitly points to the sibling stac_collections for collection ID lookup. An agent can distinguish it from other search tools by the AWS Earth Search source and satellite data focus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides concrete example queries, explains the bbox/place alternative (place prioritized over bbox), and notes that stac_collections can be used to find collection IDs. It does not explicitly state when to prefer this over sibling search tools like uk_stac_search or copernicus_search, so it stops short of full when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
天宮（Tiangong）中国宇宙ステーションの現在位置を返す。
例:「天宮の現在位置」「中国宇宙ステーションは今どこ？」
CelesTrak の最新 TLE を SGP4 で伝播して現在の緯度・経度・高度・速度を計算
（CelesTrak 遮断中は代替源の公開ミラーから取得し、本文の「軌道要素エポック」行に
実際の出典を表示。structuredContent.tle_source にも入る）。
認証不要。content に表示用サマリ＋Googleマップリンク、structuredContent に JSON。
Returns:
CallToolResult: 表示用サマリ + JSON。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
英国 EO DataHub の利用可能なコレクション一覧を返す（認証不要）。
例:「英国の衛星データコレクション」
Args:
limit: 返す件数（既定 20、最大 100）。
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, but it does add useful behavioral context: authentication is not required and the limit has a maximum of 100. It still does not explicitly state that the operation is read-only/side-effect free or describe result format/pagination beyond the limit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loads purpose, auth, and the limit. The 'Args:' block partly duplicates the schema and the example line is of unclear relevance for a list-only tool, but overall it is compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity list tool, the description covers purpose, auth, and the one parameter. However, with no annotations, no output schema, and 0% schema coverage, it could do more to distinguish itself from uk_stac_search/stac_collections and clarify what a returned collection entry contains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must carry parameter meaning. It documents the sole parameter's purpose, default (20), and maximum (100), adding the max value that the schema lacks.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (返す) and resource (英国 EO DataHub の利用可能なコレクション一覧), with the provider scope distinguishing it from generic or other national collection tools. It does not explicitly contrast with sibling uk_stac_search or stac_collections, so sibling differentiation is implicit rather than spelled out.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance or alternatives are given. '認証不要' is a behavioral note, not routing guidance; it never says to use this instead of uk_stac_search when browsing UK collections.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
英国 EO DataHub の衛星・気候データをSTACで検索する（公開カタログは認証不要）。
例:「英国の気候モデルデータ」「UKのSentinel画像」
content に表示用サマリ、structuredContent に JSON（id/日時/bbox/コレクション）を返す。
Args:
collection: コレクションID（例 "sentinel2_ard", "ukcp"）。省略で全コレクション。
query: キーワード検索（例 "climate", "sentinel"）。
bbox: 空間範囲（"lon_min,lat_min,lon_max,lat_max"）。
datetime: 時間範囲（"YYYY-MM-DD" または "start/end"）。省略で最新。
limit: 返す件数（既定 5、最大 10）。
| Name | Required | Description | Default |
|---|---|---|---|
| bbox | No | ||
| limit | No | ||
| query | No | ||
| datetime | No | ||
| collection | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does disclose that auth is not required for the public catalog, and describes the return shape (content summary + structuredContent JSON with id/datetime/bbox/collection). However it omits rate limits, error behavior, and pagination nuances of the STAC API.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded purpose sentence, followed by examples, return-shape note, and a compact Args block. Efficient and well organized, though the Japanese/English mix and slightly redundant example lines keep it from a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a 5-parameter search tool with no annotations and no output schema, the description covers purpose, examples, auth requirement, return format, and all parameter semantics. It could still state behavior on empty results or rate limits, but the essentials are present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 well: it explains each of the five parameters with examples, formats (bbox as lon_min,lat_min,lon_max,lat_max; datetime as YYYY-MM-DD or start/end), defaults, and limits (limit default 5, max 10). This is strong value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states a specific verb and resource (STAC search of UK EO DataHub satellite/climate data) and gives example queries. It doesn't explicitly differentiate itself from the many sibling search tools (stac_search, copernicus_search, eodashboard_detail), which is a missed opportunity given the dense sibling set.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied via examples ('英国の気候モデルデータ', 'UKのSentinel画像') and notes that the public catalog needs no auth, but there is no when-to-use-vs-alternatives guidance among the many sibling search tools. Adequate but with a clear gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
今後予定されているロケット打ち上げの一覧を返す。
認証不要。content に表示用サマリ、structuredContent に JSON を返す。
Args:
limit: 返す件数（既定 5、最大 15）。
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It explicitly states no authentication required and describes the return format (content summary, structuredContent JSON), which is valuable behavioral context. However, it doesn't disclose rate limits, error behavior, or data recency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise: one sentence for purpose, one for auth/return format, and a short args section. Front-loaded with core functionality, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given one optional parameter and no output schema, the description covers the essentials: what it returns, auth need, and parameter constraints. However, it lacks guidance on usage context relative to siblings and doesn't mention pagination or data freshness, leaving minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It explains the 'limit' parameter with its purpose (number of results), default (5), and maximum (15), which fully clarifies the parameter beyond the schema's bare type and default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (返す/return) and resource (今後予定されているロケット打ち上げ/upcoming rocket launches). Clearly scoped to future launches, distinguishing it from siblings like china_launches, russia_launches which are agency-specific and likely past-oriented.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this vs alternatives. It doesn't mention how it differs from china_launches, russia_launches, or other launch-related siblings, leaving the agent to infer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| band | No | visible | |
| size | No | ||
| satellite | No | himawari9 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.39.0calendar_event_addcalendar_event_removecalendar_eventscatalog_searchdlr_collectionsdlr_searchexoplanet_searchfireball_reportsgcn_alertsimpact_riskmast_observationsneo_close_approachobject_lookupplanetary_evidenceqzss_statusroscosmos_collectionsroscosmos_searchsky_map_with_satellites5 fields changedInput schema / properties / az0Added value: +{
+ "default": 0,
+ "title": "Az0",
+ "type": "number"
+}Input schema / properties / engine / defaultPrevious value: -"simple"New value: +"ground"Input schema / properties / lpAdded value: +{
+ "default": "suburb",
+ "title": "lp",
+ "type": "string"
+}Input schema / properties / showAdded value: +{
+ "default": null,
+ "title": "show",
+ "type": "string"
+}Input schema / properties / spanAdded value: +{
+ "default": 360,
+ "title": "Span",
+ "type": "number"
+}solar_system_now3 fields changedInput schema / properties / daysAdded value: +{
+ "default": 180,
+ "title": "Days",
+ "type": "integer"
+}Input schema / properties / range_auAdded value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "string"
+ }
+ ],
+ "default": 0,
+ "title": "Range Au"
+}Input schema / properties / routeAdded value: +{
+ "default": false,
+ "title": "Route",
+ "type": "boolean"
+}space_calendarspace_literature_searchv0.30.1astronomy_weather2 fields changedInput schema / properties / include_chartRemoved value: -{
- "default": true,
- "title": "Include Chart",
- "type": "boolean"
-}Input schema / properties / include_rainAdded value: +{
+ "default": true,
+ "title": "Include Rain",
+ "type": "boolean"
+}moon_phase_mapv0.29.1astronomy_weather1 field changedInput schema / properties / include_chartAdded value: +{
+ "default": true,
+ "title": "Include Chart",
+ "type": "boolean"
+}planetary_orbiter_track1 field changedInput schema / properties / sitesAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Sites"
+}weather_satellite_nowv0.27.0alma_search3 fields changedInput schema / properties / product_typeAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Product Type"
+}Input schema / properties / public_onlyAdded value: +{
+ "default": false,
+ "title": "Public Only",
+ "type": "boolean"
+}Input schema / properties / with_productsAdded value: +{
+ "default": false,
+ "title": "With Products",
+ "type": "boolean"
+}solar_system_now1 field changedInput schema / properties / viewAdded value: +{
+ "default": "system",
+ "title": "View",
+ "type": "string"
+}v0.25.2alma_searchapod1 field changedOutput schema / (root)Previous value: -{
- "properties": {
- "result": {
- "title": "Result",
- "type": "string"
- }
- },
- "required": [
- "result"
- ],
- "title": "_nasa_apodOutput",
- "type": "object"
-}New value: +nullastronomy_newsastronomy_weathercadc_observationschina_launchescnes_statuscnsa_statusconstellation_nowcopernicus_collectionscopernicus_searchcsa_dataset_searcheodashboard_collectionseodashboard_detaileso_seeinginpe_collectionsinpe_searchisro_dataiss_nowjaxa_dataset_searchjaxa_datasetsmars_rover_statusneo_today1 field changedOutput schema / (root)Previous value: -{
- "properties": {
- "result": {
- "title": "Result",
- "type": "string"
- }
- },
- "required": [
- "result"
- ],
- "title": "_nasa_neo_todayOutput",
- "type": "object"
-}New value: +nullplanetary_orbiter_trackplanetary_rover_location_mappower_climateradio_sources_nowreverse_lookup1 field changedOutput schema / (root)Previous value: -{
- "properties": {
- "result": {
- "title": "Result",
- "type": "string"
- }
- },
- "required": [
- "result"
- ],
- "title": "reverse_lookupOutput",
- "type": "object"
-}New value: +nullrussia_launchessat_ground_tracksat_tlesatellite_statussearch_space_images1 field changedInput schema / properties / inline_maxAdded value: +{
+ "default": 1,
+ "title": "Inline Max",
+ "type": "integer"
+}sky_map_with_satellitessolar_eclipse_seriessolar_system_nowspace_weatherstac_collectionsstac_searchtiangong_nowuk_stac_collectionsuk_stac_searchupcoming_launches1 field changedOutput schema / (root)Previous value: -{
- "properties": {
- "result": {
- "title": "Result",
- "type": "string"
- }
- },
- "required": [
- "result"
- ],
- "title": "upcoming_launchesOutput",
- "type": "object"
-}New value: +nullv0.1.0apodneo_todayreverse_lookupsearch_space_audiosearch_space_imagessearch_space_videosupcoming_launchesScored across 47 tools
While many tools target distinct providers, there are large clusters of near-identical tools: four STAC search tools (stac_search, copernicus_search, inpe_search, uk_stac_search) and many collections/list tools that differ only by provider. Position tools like iss_now, tiangong_now, and sat_ground_track also overlap in purpose, making mis-selection likely.
All names use snake_case and are generally readable, but there is no consistent verb_noun or search_* pattern across the set. Names like apod, neo_today, iss_now, and weather_satellite_now follow different conventions than stac_search, copernicus_collections, or eodashboard_detail.
At 47 tools, this server is well past the 'too many' threshold for coherent tool selection. The broad space domain partially justifies the count, but many tools are provider-specific variants of the same operations and should be consolidated.
The server covers an impressively wide range of space-related needs: imagery, video, audio, launches, satellite tracking, space weather, astronomical observations, and earth observation datasets. Minor gaps exist, such as the empty weather_satellite_now tool and inconsistent auth handling for downloads, but agents can usually find a working path.
Live space data for AI agents - rocket launches, ISS passes, launch news. Free, no auth.
Search Google straight from your AI agent. Web results, images, videos, news, products, scholarly ar
Web data for agents: YouTube transcripts, screenshots, Google News, WHOIS, jobs, tech stack, more.
Give your agent live data from Twitter, Reddit, the web and GitHub. No API keys, no scraping stack.
