Check the reachability and data overview of Chinese CNSA satellite portals like Fengyun, Gaofen, and CBERS, plus account-free alternatives.
中国 CNSA 系衛星データポータル（風雲/NSMC・高分/CNSA-GEO・CBERS/CRESDA）の到達状態と概要を返す。
例:「中国の衛星データ」「風雲衛星」「高分」「CBERS」
画像ダウンロードには各ポータルへのアカウント登録が必要。ここではポータルの状態と
提供データの概要、および認証不要の代替データ源を確認する。
Returns:
CallToolResult: 表示用サマリ + JSON。
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v0.25.2Does 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.