get_weather

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It credibly reveals data update frequency (~hourly), the scope behavior with and without station, and enumerates the returned fields with units. Missing minor details like error conditions or aggregation behavior, but for a read-only weather observation tool this is solid forward 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?

Four front-loaded sentences with zero wasted words. Purpose leads, followed by scope behavior, freshness, and return fields. The field list earns its place as a substitute for an output schema. Every sentence delivers new, non-redundant information beyond what annotations or schema already provide.

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 tool with one optional parameter, no output schema, and no annotations, the description compensates fully: it enumerates the return fields with units (substituting for output schema docs), states freshness, and explains both call modes. Nothing an agent needs to invoke it correctly is missing.

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 100%, so the baseline is 3. The description's parameter text ('Omit to get all') essentially duplicates the schema's own wording and adds nothing beyond it — the case-insensitivity, ASCII-fold behavior, and examples all live in the schema. The field/unit list describes output, not parameters, so it doesn't lift this score.

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 verb (get), resource (current synoptic weather observations), and origin (IMGW) in the first sentence. It clearly differentiates from siblings: get_hydro/get_warnings are for other data types, and list_weather_stations/list_hydro_stations serve listing purposes, while this tool returns current observations. The 'current' qualifier further distinguishes it from the station listing 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?

Clearly explains the two invocation modes (omit station for all ~60, provide station for a single one), which is the core usage decision. It does not explicitly name sibling alternatives or state when NOT to use this tool, but for a simple retrieval tool the context is sufficient and the scoping behavior is unambiguous.

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