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

With no annotations, the description carries the full transparency burden. It discloses the return type (str), a concrete example ('Today is Wednesday, 2026-09-23T13:02 (Swiss time)'), and the ISO 8601 without-offset format, noting it can be sent directly to the forecast tools. Minor gaps remain about edge cases like DST or system-clock dependence, but they are low-risk.

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 four concise sentences, each earning its place: purpose, usage timing, format rationale, and return example. It is front-loaded with the essential 'what' and keeps the supporting reasoning tight.

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 zero-parameter utility tool, the description is complete. It covers what it returns, when to call it, how the output should be interpreted, and how it feeds into sibling forecast tools. Nothing needed to invoke it correctly is left out.

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 tool has zero parameters, so the baseline is 4. The description correctly avoids inventing parameter details and instead focuses on the returned value and its use. No further parameter documentation is needed.

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 opens with a clear verb and object: 'Get the current weekday and Swiss local time.' This unambiguously defines the tool's purpose. It also differentiates from the weather-forecast siblings by being the date/time anchor tool rather than a forecast tool.

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 explicitly tells the agent when to call it: 'Call this first when the question is relative, such as "tomorrow" or "tonight"'. It also explains why, saying the forecast tools expect a real date rather than an offset. This provides concrete, actionable routing guidance.

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

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

With no annotations provided, the description carries the full burden, and it delivers richly: it defines the Swiss calendar day boundary (00:00–24:00), clarifies that min/max are hourly mean temperatures, states the weather words describe daytime, and explains that values can be None when MeteoSwiss does not publish them. This goes far beyond a generic 'get forecast' statement.

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-organized with Args, Returns, and Examples sections. It is detailed but every sentence adds needed information about semantics, constraints, or output interpretation, especially given that no annotations and no output schema exist to supplement it.

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?

The tool has no output schema, so the description must cover return values, and it does thoroughly: the resolved location, altitude, per-day rows, model run, temperature min/max, rainfall percentiles, weather words, and None semantics. Considering the moderate complexity and the absence of structured metadata, the description is complete enough for correct invocation.

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 input schema provides zero parameter descriptions (0% coverage), so the description must compensate. It fully does so by giving formats ('ISO 8601', e.g. '2026-09-23'), valid ranges ('today or up to 8 days ahead', 'days from 1 to 9'), a default ('Default 1'), and concrete examples for both location and days.

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: 'Get the whole-day forecast for a location, for one day or several days in a row.' It clearly differentiates from siblings like hourly_forecast by framing itself as the day-level view and explicitly notes it is the 'cheapest way' to answer daily weather questions and 'Always use this for the rain of a whole day.'

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 context for when to use this tool: for a day, weekend, or week, and specifically for whole-day rainfall. It does not explicitly name sibling alternatives and say 'use hourly_forecast instead when...', but the 'always use this for the rain of a whole day' guidance and the day-level framing strongly imply the boundary versus other forecast tools.

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

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

With no annotations provided, the description carries the full behavioral burden. It explains the output concept (height where air is 0 degrees), the relationship to snow, the required time format and range, and the return dict contents. It does not disclose edge cases or data sources, but it is transparent about the core behavior and result.

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 concise yet complete: one opening sentence, a clarifying context sentence, then clear Args/Returns/Examples sections. Every sentence earns its place, and information is front-loaded with the core purpose before details.

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 two required parameters, no output schema, and no annotations, the description provides everything an agent needs: parameter formats, time constraints, return value structure, and usage examples. It is fully complete for correct invocation.

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 coverage is 0%, but the description fully compensates. It defines location as a name or Swiss postal code with examples, and when as Swiss local time in ISO 8601 without offset with a concrete example and validity window. This adds all necessary meaning beyond the bare parameter names.

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 opens with a specific verb and resource: 'Get the height of the 0 degree line at a location at a specific time.' It clearly differentiates from weather siblings like hourly_forecast or rain_outlook by focusing on the freezing level, and the snow-context sentence reinforces its purpose.

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 explains when this tool is relevant: 'Snow usually reaches somewhat below it, so it answers questions about snow in the mountains.' It does not explicitly name alternative tools or say when not to use it, but the context is clear enough for an agent to select it appropriately.

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

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

With no annotations provided, the description fully discloses behavioral details: the default single-hour return when end is omitted, the exact time semantics (from/to, 3-hour coverage for rain/weather per MeteoSwiss), and the percentile interpretation for temperature. This goes far beyond a generic summary.

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 structured with clear sections (description, args, returns, examples) and front-loads the purpose. Every sentence adds value, and the length is justified by the complexity of the data semantics. No redundancy or filler.

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?

Despite no output schema and no annotations, the description covers everything an agent needs to call the tool correctly: input formats, time bounds, return structure, and the meaning of the data fields. It even explains the 3-hour aggregation rationale. Nothing essential 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 coverage is 0%, but the description compensates completely: it specifies the location format (name or Swiss postal code), start format with example and valid range (today up to 8 days ahead), and end constraints (optional, at most 24 hours after start). Examples illustrate real calls.

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 opens with a specific verb+resource ('Get the weather hour by hour for a location') and enumerates the exact data delivered (temperature range, rain chance, weather in words). It also names the sibling tools it is not (daily_forecast, rain_outlook), so an agent can distinguish it immediately.

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?

Provides explicit use cases ('Use this for one hour... or part of a day') and gives concrete natural-language queries ('how is the afternoon'). It also states when to use alternatives ('For whole days use daily_forecast, for rain amounts rain_outlook'), leaving no ambiguity.

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

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

No annotations are provided, so the description carries full responsibility. It discloses the return structure (dict with resolved location, altitude, per-block rows, and model run), explains that the median is often 0 when showers are possible and advises reading the chance and 'up to' amount, and states time constraints (start today or up to 8 days ahead, end at most 48 hours after). This is thorough and proactive.

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 Args, Returns, and Examples sections. It front-loads the core purpose and usage, then provides concise yet complete parameter details. Every sentence adds value—no filler. The examples are illustrative and directly useful for an agent.

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 the tool's moderate complexity and lack of annotations/output schema, the description is exceptionally complete. It explains the output format, parameter constraints, interpretation guidance, and even provides two example calls. An agent has everything needed to select and 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 coverage is 0%, but the description fully documents each parameter: location (name or Swiss postal code), start (Swiss local time ISO 8601 without offset, with valid range), and end (same format, max 48 hours after start). It adds essential format and constraint details that the schema completely lacks.

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 ('Get') and a clear resource: when and how much it may rain in 3-hour blocks. It differentiates from siblings like hourly_forecast and daily_forecast by focusing exclusively on rain probability and amounts, and it names the exact use cases ('will it rain this afternoon', 'do I need an umbrella'). The purpose is unmistakable.

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 explicitly says 'Use this for...' and lists three concrete scenarios. It also implicitly distinguishes from alternative forecast tools by focusing on rain-specific data and 3-hour resolution. While it doesn't name alternatives, the guidance is clear and actionable, leaving no ambiguity about when to invoke this tool.

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

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

With no annotations provided, the description carries the full burden. It discloses the data source (MeteoSwiss), the unit conversion (minutes summed to hours), time-zone and offset requirements, the valid time window (today to 8 days ahead), and the return structure (sunshine hours, resolved location with altitude, period, and model run). This is substantial behavioral context beyond a bare call signature, though it does not mention error behavior or rate limits.

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 Args, Returns, and Examples sections. Every sentence contributes information: the purpose, the unit conversion, parameter constraints, return shape, and two use cases. It is slightly verbose but appropriately so for a tool with no schema documentation. The main purpose is front-loaded.

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 there is no output schema, the description is adequately complete: it describes the return dict and its fields, explains the period constraints, and gives examples. It covers everything an agent needs to select and call the tool correctly for a typical read-only weather data request. Minor omissions like invalid-location handling are acceptable for this complexity level.

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 input schema has no descriptions (0% coverage), so the description must explain each parameter. It does so thoroughly: location accepts a name or Swiss postal code; start and end are Swiss local times in ISO 8601 without offset, with example values and the restriction that the period starts today or up to 8 days ahead. Examples illustrate valid calls, fully compensating for the schema gap.

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 the tool's purpose: 'Get the sunshine hours for a location over a period.' The verb 'get', the resource 'sunshine hours', and the scope (location + period) are specific and distinct from sibling tools like hourly_forecast or daily_forecast, which serve different weather metrics. No ambiguity about what it does.

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 provides useful context, such as the MeteoSwiss data source and the minute-to-hour conversion, and constrains start/end times to Swiss local time and a forward-only range. However, it does not explicitly state when to prefer this tool over alternatives or mention any exclusions (e.g., 'use daily_forecast for temperature'). Usage guidance is implied by the specific metric but not made explicit.

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

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

No annotations are provided, so the description carries the full burden. It discloses that the total is an estimate assuming independent layers, and explains that all three layers are returned to distinguish low fog from thin high cloud. It also describes the return dict contents (location, altitude, valid time, model run), offering good behavioral transparency beyond the basic purpose.

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 a clear opening, an explanatory note about the estimation, explicit Args/Returns/Examples sections. It is slightly longer than necessary but each sentence provides value, including the estimation nuance and the alternative routing. The structure is front-loaded with the core purpose, making it easy to scan.

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 tool with no output schema and no annotations, the description covers everything an agent needs: parameter format and examples, the return value structure, the estimation logic, and the differentiation from a sibling. It even includes usage examples. Nothing is missing for correct invocation and interpretation of 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 0%, so the description must fully explain the parameters. It does: location is defined as a location name or Swiss postal code with examples, and when is defined as Swiss local time in ISO 8601 without offset, with an example and a valid range (today to 8 days ahead). This completely compensates for the lack of schema 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: 'Get how cloudy it is at a location at a specific time.' It clearly distinguishes itself from the sibling hourly_forecast by explaining that this tool returns a numeric total and layer details, whereas hourly_forecast answers in plain words. The purpose is unambiguous and differentiates from siblings.

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 provides a clear alternative: 'When a number is not needed, hourly_forecast answers "how cloudy" in plain words.' This implies that this tool is for numeric cloud cover data. While it doesn't explicitly enumerate all when-not scenarios, it gives a concrete condition for choosing the alternative, which is sufficient guidance.

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

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

With no annotations provided, the description carries the full burden and does so excellently. It explains the averaging period (mean over the hour), the gust definition (one-second gust), the probabilistic meaning of the 90th percentile, and the direction convention (degrees clockwise from north, compass point). This gives the agent insight beyond the bare operation.

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 a concise summary, then a detailed explanation of output semantics, followed by Args, Returns, and Examples sections. Every sentence adds value — the probabilistic note and directional convention are important for correct interpretation. It is longer than a bare one-liner but not bloated.

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 tool with only two parameters, no output schema, and no annotations, the description is exceptionally complete. It documents parameter formats, constraints, the exact return fields, and gives usage examples. An agent has everything it needs to call this tool correctly and interpret the result.

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 document both parameters. It does: location accepts a place name or Swiss postal code with examples, and when is specified as Swiss local ISO 8601 without offset with constraints (today to 8 days ahead) and an example. This compensates completely 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 opens with a clear verb and resource: 'Get the wind at a location at a specific time', followed by the specific outputs (mean speed, strongest gust, direction). This is unambiguously distinct from sibling tools like hourly_forecast or rain_outlook, so an agent can identify it without needing to open the schema.

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 clearly conveys the tool's intended use case — retrieving wind data for a single location at a particular point in time — which is enough to infer when to select it. However, it does not explicitly mention alternatives or provide exclusions, so it falls short of the full explicit-routing bar.

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