Skip to main content
Glama

power_climate

Retrieves historical climate and solar energy statistics for a latitude/longitude via NASA POWER, enabling past-condition analysis and solar site assessment.

Instructions

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")。 省略で主要パラメータ(気温・日射量・風速)。

Input Schema

NameRequiredDescriptionDefault
endNo
startNo
latitudeYes
longitudeYes
parametersNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed15 schema fields changedv0.41.4
    • removedInput schema / properties / end / anyOf
      Removed value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • removedInput schema / properties / end / default
      Removed value: -null
    • removedInput schema / properties / end / title
      Removed value: -"End"
    • addedInput schema / properties / end / type
      Added value: +[
      +  "string",
      +  "null"
      +]
    • removedInput schema / properties / latitude / title
      Removed value: -"Latitude"
    • removedInput schema / properties / longitude / title
      Removed value: -"Longitude"
    • removedInput schema / properties / parameters / anyOf
      Removed value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • removedInput schema / properties / parameters / default
      Removed value: -null
    • removedInput schema / properties / parameters / title
      Removed value: -"Parameters"
    • addedInput schema / properties / parameters / type
      Added value: +[
      +  "string",
      +  "null"
      +]
    • removedInput schema / properties / start / anyOf
      Removed value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • removedInput schema / properties / start / default
      Removed value: -null
    • removedInput schema / properties / start / title
      Removed value: -"Start"
    • addedInput schema / properties / start / type
      Added value: +[
      +  "string",
      +  "null"
      +]
    • removedInput schema / title
      Removed value: -"power_climateArguments"
  2. Addedv0.25.2

TDQS

A4/5.0
Behavior3/5

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

アノテーションがないため説明が動作面の情報を担う必要があります。認証不要であることや日付・パラメータ省略時のデフォルトは説明されていますが、レート制限、データ粒度、単位、応答形式などの挙動は開示されていません。

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

冒頭で目的を述べ、続いて代表的な利用例、最後に Args を構造化して示しており、無駄がありません。情報量は適切で、前段に重要情報が配置されています。

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

Completeness3/5

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

入力パラメータは網羅的に説明されていますが、出力スキーマがなく、返される統計の形式・単位・頻度についての説明がありません。データ取得ツールとしては、呼び出し後の結果を解釈するための情報がやや不足しています。

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

スキーマ説明カバレッジが0%であるにもかかわらず、latitude、longitude、start、end、parameters の全5パラメータについて形式・例・省略時のデフォルトを説明しています。スキーマだけでは分からない意味を十分に補完しています。

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

明確に「NASA POWER API で任意地点の過去の気候・太陽エネルギー統計を返す」と述べており、動作と対象リソースが具体的です。認証不要という特徴も示していますが、類似する天文・気象系の兄弟ツールとの使い分けには触れていません。

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

Usage Guidelines4/5

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

「東京の過去1年間の日射量」「ハワイの気温データ」「太陽光発電の立地評価」といった例により、どのような場面で使うかが明確です。ただし、代替ツールや使うべきでない条件には明示的に触れていません。

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