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

Beyond the readOnly/idempotent/openWorld annotations, it discloses crucial semantic traits: an item is a station, not an observation; `datetime` is publication time not weather time; measurements back to 1980 live inside CSV assets; and one item's asset count (~16 CSVs). This is exactly the kind of non-obvious behavior an agent could otherwise misread.

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 purpose, then adds the high-value datetime caveat and bbox format in compact sentences. It is dense but essentially every sentence earns its place, though the bbox details partly duplicate the schema.

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?

No output schema exists, yet the description explains the return shape (one item per station/tile with coordinates, name, download URLs). With annotations covering safety and all params documented, an agent has everything needed to invoke it correctly.

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 schema already documents all six parameters richly, including bbox ordering and Swiss extent. The description largely repeats the bbox coordinate-order/extent guidance rather than adding new parameter-level detail, so baseline 3 fits.

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 (search) and resource (Swiss weather stations and federal geodata by area) and describes the returned item (one per station/map tile with coords, name, download URLs). It also positions itself as AUTHORITATIVE for station coverage and file selection, clearly distinguishing it from the catalogue-listing siblings like meteoswiss_collections.

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 frames when to use it (finding which stations cover a location and which files to fetch) and points to meteoswiss_collections for listing ids. It lacks an explicit 'when not to use' or a direct comparison to meteoswiss_collection/search_within, but the intended context is unambiguous.

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