space_weather

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

No annotations are provided, so the description carries the full behavioral burden. It fully discloses a key surprise: automatic fallback to NOAA SWPC (no auth required) when NASA has rate limits or outages, and states the source is identified in content and structuredContent.source. It also specifies the output contract: display summary in content and JSON in structuredContent. This is rich, non-obvious behavioral disclosure.

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 verbose but every section earns its place: purpose, use case, fallback behavior, examples, output contract, and parameter docs. It front-loads the core purpose before behavioral details. The parameter documentation is somewhat long to live in the description (would be better in schema descriptions), but given 0% schema coverage it is justified placement.

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 4-parameter tool with no annotations, no output schema, and no schema descriptions, the description is highly complete: it covers purpose, use case, fallback, output format, and all parameters with enums and constraints. The only minor gap is that the exact JSON field structure of structuredContent is not enumerated, but the source field disclosure covers the most important piece.

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?

Schema description coverage is 0%, so the description must fully compensate. It documents all four parameters: kind with all five enum values and Japanese explanations (all/flare/cme/gst/sep), start_date and end_date with YYYY-MM-DD format and default behavior, and limit with default 10 and max 20. This fully compensates for the schema's lack of descriptions.

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 verb and resource: 'NASA DONKI の宇宙天気（太陽フレア・CME・地磁気嵐・太陽粒子現象）を返す' (returns NASA DONKI space weather for solar flares, CME, geomagnetic storms, solar particle events). This clearly distinguishes it from sibling astronomy tools like astronomy_weather, weather_satellite_now, and solar_system_now by naming the exact data source and phenomena covered.

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 gives clear usage context: '天体観測や通信・衛星運用に影響する太陽活動を確認できる' (check solar activity affecting astronomical observation, communications, and satellite operations). It also provides query examples like '最近の太陽フレア' and '地磁気嵐は起きてる?'. However, it does not explicitly name alternatives or state when NOT to use this tool versus a sibling, leaving the when-not-to-use guidance to inference.

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