env_snow_stations

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

Annotations already provide readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the description's job is to add context beyond that. The description adds the data source (SLF CC BY 4.0) and the explanation of station types, but does not disclose much else about behavior (e.g., rate limits, authentication, or edge cases). With annotations covering the safety profile, a 3 is appropriate – the description adds some value but not rich behavioral context.

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 well-structured with paragraphs, use_case, and important_notes tags, and is front-loaded with the purpose. However, it is somewhat lengthy; each sentence earns its place but could be slightly more concise. Still, the structure aids readability.

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?

Given that an output schema exists (context confirms), the description does not need to detail return values, but it still mentions the return fields (Code, Name, Kanton, Höhe, Typ). It covers the use case, important notes about data source and station types, and provides clear entry-point guidance. For a list tool with good annotations, this is complete.

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 description explicitly lists both parameters (canton and response_format) with brief explanations, adding meaning beyond what the input schema provides. The schema already has a description for canton, but the response_format parameter is an enum and the description clarifies the options. Since the schema description coverage is low (0% per context, though the schema itself has descriptions), the description compensates well.

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 clearly states it lists automatic IMIS snow measurement stations of SLF, and specifies what parameters they measure (snow height, new snow, wind, temperature). This distinguishes it from sibling tools like env_snow_current which retrieves actual snow data.

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 use_case tag explicitly says it's an entry point to snow data, to be followed by env_snow_current. The important_notes tag explains the data source (SLF, CC BY 4.0), clarifies that type=SNOW_FLAT are flat-field stations, and importantly tells users that this is NOT a precipitation tool, directing them to meteoswiss-mcp instead. This is excellent guidance for when to use or not use this tool.

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