Check the reachability and data overview of France's CNES Earth observation portals, including THEIA and GEODES, before accessing satellite imagery.
フランス CNES の地球観測データポータル（THEIA / GEODES）の到達状態と概要を返す。
例:「フランスのCNES衛星データ」「THEIAポータル」
画像ダウンロードには CNES アカウント登録が必要。ここではポータルの状態と
提供データの概要を確認する。
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?
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.