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., "@jaxa-earth-mcp What's the daily rainfall in Uonuma for the last 30 days?"
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.
JAXA Earth API を Claude Code / Claude Desktop から対話的に扱うための軽量 MCP ラッパー。
個人開発者が作成した再利用可能な MCP(Model Context Protocol)ツールです。
JAXA が公開している衛星観測データ配信サービス JAXA Earth API
の Python パッケージ（jaxa-earth）を薄くラップし、地点の時系列取得・データセット情報照会・
領域画像生成を AI エージェントから呼び出せるようにします。
追加の API キー・ユーザー登録・課金は不要（JAXA Earth API は登録不要・無償）
依存は最小限（jaxa-earth / mcp / numpy / requests）
サーバーは標準入出力（stdio）で動作
本リポジトリは JAXA 公式のものではありません。データの権利は JAXA に帰属します （利用上の注意 参照）。
ツール | 概要 |
| データセットを検索。 |
| 分解能・提供期間・単位・出典（citation/DOI）・ライセンス・クレジット表記例・利用上の注意を返す。 |
| 地点の時系列（日付・値の配列＋統計）。 |
| 指定領域・日付の PNG を |
bbox 自動拡張: get_point_timeseries は点まわりの矩形を データセットの分解能
（STAC の je:ppu_max）から動的に算出します。粗い ~5km 級（GSMaP/SMC など）は
±0.3° 程度に広げて地域平均を取り、高分解能（DSM 30m）は点に近い矩形を使います。
固定値ではありません。
長期間の自動分割: JAXA Earth API は 1 リクエスト最大 100 日の制約があります。 期間がこれを超える場合、内部で 90 日ごとに分割取得し、結合して 1 本の時系列で返します。
静的データの単発取得: 標高（ALOS DSM）のような時間変化しないデータは、
start_date/end_date を無視して単発取得します。
欠測は補間しない: 雲などで観測が欠けた場合、その値は null（NaN）のまま返します
（前後の値でつなぎません）。
取得失敗はそのまま返す: 想定外のエラーは握りつぶさず、内容を返します。
Related MCP server: JMA Data MCP
略称 | 内容 | 単位 | 分解能(概算) | 備考 |
GSMaP | 降水（日次） | mm/hr | 約11km (0.1°) | 値は日平均降水強度。日積算量[mm]=値×24（JAXA GSMaP FAQ Q4）。時系列取得時に |
GCOM-C LST | 地表面温度（日中・日次） | Kelvin | 約2.8km (1/40°) | 地表面温度であり気温ではない。雲欠測あり。 |
GCOM-C NDVI | 植生指数（日中・半月） | 無次元 | 約2.8km (1/40°) | 分解能が粗く圃場単位でなく地域傾向。雲欠測あり。 |
ALOS AW3D30 | 数値表層モデル（標高） | m | 約30m | 静的データ（2024年4月版 / v4.1）。 |
GCOM-W SMC | 土壌水分量（日中・日次） | %（体積含水率） | 約11km (0.1°) | マイクロ波観測で雲を透過。 |
単位は jaxa-earth が COG メタデータから読む値（cinfo.unit）を実測で確認しています。
keyword 検索で上記以外のデータセット（GCOM-C は 39 種など、全体で 100 以上）も利用できます。
分解能の注記: GCOM-C LST/NDVI の API 配信グリッドは COG の GeoTIFF タグ （
ModelPixelScale=0.025°、90°タイル=3600px）を実測して 1/40°（約2.8km） と確認しました。 一部のデータセットで STAC のcitationに「1/24 deg」等の実グリッドと異なる表記や、descriptionの取り違え（NDVI に「Land surface temperature」と記載）が見られます。 本ツールは分解能をppu_max／COG 実測値から算出しており、get_dataset_infoのresolution.noteにこの不一致を明記します。
前提: Python 3.10 以上、macOS / Linux / Windows。
git clone <this-repo> jaxa-earth-mcp
cd jaxa-earth-mcp
python3 -m venv .venv
source .venv/bin/activate # Windows: .venv\Scripts\activate
pip install -e .インストール確認:
python -c "import jaxa_earth_mcp, mcp, jaxa.earth; print('OK')"claude mcp add jaxa-earth \
--env JAXA_MCP_OUTPUTS="$(pwd)/outputs" \
-- "$(pwd)/.venv/bin/jaxa-earth-mcp"
# 確認（Status: ✔ Connected になれば成功）
claude mcp get jaxa-earth登録後、Claude Code のプロンプトから自然文で呼び出せます。例:
「2026年4月から今日までの魚沼の日次降水量の推移と合計を出して」
「魚沼の8月のNDVIとその分解能・注意事項を教えて」
設定ファイル（macOS: ~/Library/Application Support/Claude/claude_desktop_config.json、
Windows: %APPDATA%\Claude\claude_desktop_config.json）に以下を追加します。
パスは環境に合わせて絶対パスで記述してください。
{
"mcpServers": {
"jaxa-earth": {
"command": "/absolute/path/to/jaxa-earth-mcp/.venv/bin/jaxa-earth-mcp",
"env": {
"JAXA_MCP_OUTPUTS": "/absolute/path/to/jaxa-earth-mcp/outputs"
}
}
}
}Windows の command は ...\\.venv\\Scripts\\jaxa-earth-mcp.exe を指定します。
設定後、Claude Desktop を再起動してください。
python -m jaxa_earth_mcp.serverでも起動できます。その場合はcommandに venv のpythonを、argsに["-m", "jaxa_earth_mcp.server"]を指定します。
get_point_timeseriesdataset_id : データセットID（list_datasets で確認）
lat, lon : 省略時は魚沼（37.2250, 138.9689）
start_date : "YYYY-MM-DD"（時系列データで必須）
end_date : "YYYY-MM-DD"（時系列データで必須）返り値には series（{date, value} の配列、欠測は value: null）、stats
（count / missing / mean / min / max）、aggregation（使用した bbox と分解能）、
unit、credit が含まれます。
降水強度[mm/hr]の単純合計は物理的に無意味なため stats に sum は持ちません。
GSMaP（mm/hr）の場合のみ derived に日積算量[mm/day]への換算
（series_mm と total_mm_estimated、換算根拠付き）を返します。
get_area_imagedataset_id : データセットID
bbox : [min_lon, min_lat, max_lon, max_lat]
date : "YYYY-MM-DD"（最も近い観測日を自動選択。静的データでは無視）outputs/ に PNG を保存し、image_path を返します。
コード: MIT License。
データ: JAXA Earth 研究データ利用規約に従います。商用利用は同規約適用データで可能です。
各データセットの詳細ライセンスは STAC の license / providers に定義されています。
クレジット表記例（get_dataset_info が各データセットの表記例を返します）:
データ: Credit: <データセット名> (JAXA)（例: Credit: GSMaP (JAXA)）
API 利用: Image: Created using the JAXA Earth API
出典・規約の一次情報: JAXA Earth API / 利用規約
本リポジトリは個人開発による非公式ツールです。JAXA が提供・保証するものではありません。 データの内容・可用性については JAXA Earth API の提供状況に依存します。
指定領域・日付の PNG を outputs/ に保存し、保存パス等を返す。
bbox=[min_lon, min_lat, max_lon, max_lat]、date=YYYY-MM-DD。 静的データは date を無視して当該データを描画する。
| Name | Required | Description | Default |
|---|---|---|---|
| bbox | Yes | ||
| date | Yes | ||
| dataset_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals key behavior: it saves a file to 'outputs/' and returns a path. It also explains that static data ignores the date. No annotations are provided, so the description carries the burden, and it sufficiently covers basic behavior, though it lacks details on overwrite behavior or permissions.
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 extremely concise with two sentences. The first sentence states the core purpose, and the second details parameter formats. Every word adds value, with no 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?
Given no output schema or annotations, the description is minimal but covers basic functionality and parameter formats. It lacks details on the return structure (only 'save path etc.'), error handling, and any additional constraints, making it complete enough for simple use but not comprehensive.
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 adds meaning for two of three parameters: it defines 'bbox' format as [min_lon, min_lat, max_lon, max_lat] and 'date' format as YYYY-MM-DD. However, 'dataset_id' is not explained, reducing the overall semantic contribution.
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 it saves a PNG of a specified area and date to 'outputs/' and returns the save path. This distinguishes it from sibling tools like get_dataset_info, get_point_timeseries, and list_datasets, which do not involve image generation.
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 provides context on when to use the tool (when needing an area image) and notes that static data ignores the date, guiding usage. However, it does not explicitly state when not to use it or provide alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
データセットの詳細情報を返す。
分解能(ppu_max / ピクセル度・メートル概算)、提供期間、静的判定、単位、 出典(citation/DOI)、ライセンス、クレジット表記例("Credit: <名> (JAXA)")、 利用上の注意(気温ではない/雲欠測/分解能の粒度など)を含む。
| Name | Required | Description | Default |
|---|---|---|---|
| dataset_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the burden of behavioral disclosure. It details what information is returned (resolution, period, etc.) but omits side effects, authentication needs, or error conditions. The read-only nature is implied but not explicit.
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 concise, starting with the core purpose and listing key contents in a structured way. It is not overly verbose, though the bullet list could be more formalized. Front-loaded with the main action.
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 or annotations, the description provides a comprehensive list of returned information (resolution, period, citation, license, usage notes). It covers most necessary context for an info tool, though return format is not specified.
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 only parameter dataset_id lacks schema description (0% coverage). The tool description does not add meaning to this parameter, leaving the agent unclear on how to obtain or format the ID. Some compensation is needed but absent.
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 tool returns detailed dataset information, listing specific contents like resolution, period, sources, etc. It distinguishes from siblings such as get_area_image, get_point_timeseries, and list_datasets, which serve different purposes.
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 does not provide explicit guidance on when to use this tool versus alternatives. It only implies usage for retrieving dataset metadata, but lacks when-not-to-use or references to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
地点の時系列(日付・値の配列＋基本統計)を返す。
lat/lon 省略時は魚沼(37.2250, 138.9689)。日付は YYYY-MM-DD。
bbox はデータセットの分解能に応じて自動拡張し領域平均を返す。
期間が 100 日を超える場合は内部で自動分割し結合する。
静的データ(DSM 等)は日付を無視して単発取得する。
雲欠測は value=null(NaN)のまま返し、補間しない。
| Name | Required | Description | Default |
|---|---|---|---|
| lat | No | ||
| lon | No | ||
| end_date | No | ||
| dataset_id | Yes | ||
| start_date | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses key behaviors: default coordinates, auto-bbox expansion for area averaging, automatic splitting of periods over 100 days, ignoring dates for static data, and returning null for cloud gaps without interpolation. This is comprehensive and transparent.
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 main purpose, followed by bullet points that cover key details concisely. Each point adds value, though a few could be slightly tighter. Overall it is efficient and well-structured.
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?
The description covers input defaults, date handling, automatic behaviors, and edge cases like static data and cloud gaps. However, it does not specify the exact structure of the output (e.g., format of basic statistics or the array), which would be helpful given no output schema. Still, it is largely complete for a tool of moderate complexity.
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?
Given 0% schema description coverage, the description adds significant meaning: lat/lon defaults, date format YYYY-MM-DD (applies to start_date/end_date), and behaviors like bbox auto-expansion (though bbox is not a parameter). It does not explicitly explain dataset_id or the output statistics, but it compensates well for the schema gap.
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 clearly states the tool returns time series (date-value array + basic statistics) for a point location, with specific examples like default coordinates and date format. It is easily distinguishable from siblings such as get_area_image which focuses on area imagery, get_dataset_info for metadata, and list_datasets for listing datasets.
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?
Description provides usage context like default lat/lon, date format, automatic bbox expansion and period splitting, and handling of static data. However, it does not explicitly mention when to use this tool over alternatives or when not to use it, though the sibling tools cover different functionalities.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
JAXA Earth API のデータセットを検索する。
keyword を省略すると主要データセット(降水/地表面温度/植生/地形/土壌水分)を返す。 keyword を与えると STAC カタログ全体を ID 部分一致で検索する (例: "GSMaP", "GCOM-C LST", "AW3D30")。
| Name | Required | Description | Default |
|---|---|---|---|
| keyword | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses the two operational modes and references the STAC catalog, sufficiently covering behavioral traits for a read-only list 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?
Three sentences with no wasted words; purpose stated first, then details, all in a clear and efficient structure.
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 single-parameter search tool with no output schema, the description covers all necessary aspects: when to use each mode, example inputs, and implicit return of dataset lists.
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 description fully compensates for 0% schema coverage by explaining the keyword parameter's effect in both modes and providing concrete examples, adding substantial meaning.
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 tool searches JAXA Earth API datasets, distinguishes behavior with and without keyword, and provides examples, effectively differentiating from sibling 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 description tells when to use keyword (to search specific datasets) and when not (to get major datasets), but does not explicitly exclude other scenarios or compare with siblings.
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.1.0get_area_imageget_dataset_infoget_point_timeserieslist_datasetsScored across 4 tools
Each tool has a clearly distinct purpose: image download, metadata retrieval, point timeseries, and dataset search. No overlap in functionality.
All tool names follow a consistent verb_noun pattern in snake_case (get_area_image, get_dataset_info, get_point_timeseries, list_datasets).
Four tools is well-scoped for a geospatial data server, covering essential operations without unnecessary clutter.
Covers search, metadata, point and area data retrieval. Minor omission: no direct tool for listing available dates or data coverage, but dataset info includes period.
17+ Japan MCP tools (weather/calendar v2/local-pack/enrich). x402 on Base, wallet-free trial.
Interact with climate metrics via Riskthinking.AI's CDT Express API in supported AI chat experiences
Geospatial AI MCP server — satellite imagery, embeddings, weather, GNS governance
Weather, climate, terrain, fire and flood risk data for any point or polygon on Earth. Free tier.
