cnsa_status

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

With no annotations at all, the description carries the full burden, and it does disclose the return content: reachability status plus a summary of each portal. It says nothing about what '到達状態' means operationally (up/down/degraded), how the check is performed, whether results are cached or live-probed, timeout behavior, or whether the tool needs network access to external sites.

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 compact lines: the purpose statement is front-loaded and the example phrases follow as secondary hints. Nothing is redundant, though the example list is of marginal value for a parameterless status tool.

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, no-output-schema status tool, the description covers what the tool is, which providers it covers, and what is returned, which is close to sufficient. The main gap is the absence of any note on freshness, failure modes, or which sibling to use when a full dataset search (rather than portal status) is what the user wants.

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 input schema has zero properties, so the baseline of 4 applies; there are no parameters whose meaning could be lost. The description also need not compensate for any schema gaps here.

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?

Specific verb (返す) plus a well-scoped resource: reachability status and overview of Chinese CNSA-family satellite data portals, with the three concrete providers named (風雲/NSMC, 高分/CNSA-GEO, CBERS/CRESDA). This clearly separates it from siblings like cnes_status or qzss_status by naming the Chinese program, though it never explicitly says how it differs from those status 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 bracketed example phrases (「中国の衛星データ」「風雲衛星」「高分」「CBERS」) imply the kind of user request this answers, which gives implied usage context. There is no explicit when-to-use/when-not statement and no named alternative (e.g. when to prefer copernicus_search or jaxa_datasets instead), and since the tool takes no parameters the examples read oddly as query strings.

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