List Weather Stations

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 discloses the geographic scope (Swedish stations) and the case-insensitive substring matching behavior, but omits return format, pagination/limit behavior, and whether the operation is read-only. For a simple list tool this is adequate but incomplete.

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 front-loaded with purpose and usage, then adds search semantics. Every sentence contributes to selection or invocation, and the examples, while numerous, are directly useful for the name pattern. No structural waste.

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 two-parameter discovery tool, the description covers why to use it and how name filtering works. However, with no output schema and no annotations, it does not describe what the return contains (e.g., station names, IDs, coordinates) or the default limit behavior. It is sufficient to invoke correctly but incomplete for interpreting results.

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 baseline is 3. The description adds meaningful clarification for namePattern, including case-insensitive substring matching and example values, though it does not explain the limit parameter. There is a slight tension between the schema's 'SQL LIKE syntax' and the description's 'substring matching', but it remains useful.

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 ('List') and resource ('Swedish weather stations') with optional name filtering. It distinguishes itself from get_weather_station by framing the tool as discovery of station names before querying specific weather data. Sibling tools are not named explicitly, so it falls short of a 5.

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?

Explicitly says to use this tool to discover station names before querying specific weather data, giving clear context for invocation. It does not state when to prefer siblings like get_weather_station or get_weather_stations_near_location, so no exclusions or alternatives are provided.

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