Amtsblick

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true. The description adds valuable behavioral context beyond that: classification comes from source data, no own warning levels are computed, it is not an official warning, and the response ends with source/license information. It does not cover things like ordering or pagination, so 4 rather than 5.

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 purpose is front-loaded, and the text flows logically from overview to caveats to examples to output note. It is slightly long with several sentences, but each sentence contributes useful information rather than 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?

For a read-only, single-optional-parameter tool with no output schema, the description is complete: it explains what data is shown, how it is grouped, what no-data stations are included, the data provenance, the non-official-warning limitation, and the response footer. Nothing essential for correct invocation appears to be 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 single 'bundesland' parameter is fully documented in the schema. The description adds only an indirect example ('in Niederösterreich') and no extra syntax or semantic detail beyond the schema, making the baseline 3 appropriate.

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 resource and scope: an overview of gauge stations reporting at least elevated water flow, grouped by flood level and trend, plus stations with no data. It does not explicitly distinguish itself from siblings such as pegel_an_gewaesser or pegel_in_der_naehe, 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?

Example questions ('Gibt es gerade Hochwasser in Österreich?', 'Wie ist die Hochwasserlage in Niederösterreich?') make the intended usage clear. The caveat 'Keine amtliche Warnung – maßgeblich sind die Warndienste des Landes' further sets expectations. However, no sibling alternatives or explicit when-not-to-use conditions are given.

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?

Annotations cover the safety profile (readOnlyHint, openWorldHint, destructiveHint), and the description adds real context beyond them: conditional behavior when the water module is active, the 15 km gauge radius, the absence of official warnings, and a license/source trailer on the response. It stops short of failure modes such as ambiguous place names or what happens when the module is inactive.

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-loaded: the full content scope is in the first sentence, followed by examples and then the license note. Three example questions is slightly more than needed, but each sentence carries information and none is 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?

With no output schema, the description carries the burden of describing returns and does so: weather, nowcast, 24-hour forecast, gauges, and the source/license footer. For a one-parameter, read-only, annotated tool, 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% and there is a single parameter, so the schema already documents the accepted 'ort' formats (name, GKZ, coordinate). The description adds nothing about the parameter, which is the expected baseline when the schema does the heavy lifting.

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 and resource (an all-in-one overview for an Austrian municipality) and enumerates exactly what is bundled: current weather, 3-hour nowcast, 24-hour forecast, and nearby gauges within 15 km. That enumeration is what separates it from the single-purpose siblings like niederschlag_jetzt, wetter_prognose and pegel_in_der_naehe.

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 three example questions ('Wie ist die Lage in Steyr?', etc.) make the intended usage concrete, and 'Keine amtliche Warnung' tells the agent this is not the tool for official warnings. However, no sibling is named as an alternative, so the routing to hochwasserlage or wetter_prognose is left to inference.

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?

Annotations already declare readOnly, openWorld and non-destructive. The description goes beyond them by disclosing the fallback behavior (stale nowcast yields hourly forecast values and the response says so), the license attribution footer, and the non-official-warning caveat. It does not mention rate limits or latency, but the added behavioral context is meaningful.

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-loaded with the core capability, then fallback behavior, disclaimer, examples and license note. Slightly long due to multiple example questions, but every element (granularity, fallback, warning caveat) earns its place.

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?

With no output schema, the description carries the burden of describing the result: 3-hour window at 15-minute steps, temperature/wind/gusts, forecast fallback, and a source/license trailer. That is sufficient for an agent to call and interpret it; only the exact output shape and field naming remain unspecified.

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?

Only one parameter ('ort') and schema description coverage is 100%, so the schema fully documents accepted forms (municipality name, optional state, five-digit GKZ, or coordinates). The description adds no syntax or format detail beyond the schema; baseline 3 applies.

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?

Specific verb+resource with scope: precipitation for the next 3 hours in 15-minute steps (GeoSphere Austria nowcast) for an Austrian municipality, plus temperature, wind and gusts. It is clearly distinguishable from wetter_prognose by its nowcast horizon and granularity, though it does not name that sibling explicitly.

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?

Example questions ('Regnet es gleich in Linz?', 'Wann hört der Regen in Graz auf?') give concrete usage context, and the disclaimer 'Keine amtliche Unwetterwarnung' signals when not to rely on it for warnings. However it never points to an alternative sibling (e.g. wetter_prognose or lage_am_ort) for those cases, so the routing guidance is incomplete.

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?

Annotations already establish read-only, idempotent, open-world, non-destructive behavior, and the description adds substantive context beyond that: exact-before-fuzzy fallback, umlaut and St./Sankt normalization, list output for ambiguous names, and the CC BY 4.0 source/license footer on every response.

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?

Purpose, behavior, examples, and licensing note are ordered logically and front-loaded, with no filler sentences. The licensing note is slightly tangential but legitimately describes response content.

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?

Although there is no output schema, the description enumerates the returned fields and the license footer, and clarifies ambiguous-name handling. Nothing needed to invoke or interpret the tool 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% and the single 'text' parameter is fully documented in the schema, including the 'Name, Bundesland', GKZ, and coordinate formats. The description correctly mirrors those accepted forms but adds little the schema does not already state, so the baseline 3 applies.

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?

Names a specific verb (sucht/findet), a specific resource (österreichische Gemeinden), the accepted lookup keys, and the returned fields (GKZ, Bezirk, Bundesland, Mittelpunkt). This is unambiguous and clearly distinguishable from the weather/flood 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?

Concrete example questions ('In welchem Bezirk liegt Steyr?', 'Zu welcher Gemeinde gehört 48.04, 14.42?') make the intended use obvious, and the exact-then-fuzzy behavior is stated. It lacks an explicit when-not or a named alternative, but the sibling set covers entirely different domains so no routing conflict exists.

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?

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds real behavioral context beyond that: data refreshes at most hourly, this is explicitly NOT an official warning (Keine amtliche Warnung), and the response carries the data provider's source note and CC BY 4.0 license link.

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-loaded with the returned data, then matching rule, freshness, warning disclaimer, examples and license note. Every element is useful, though the example-question list and license sentence make it longer than strictly necessary for invocation.

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?

With no output schema, the description compensates by enumerating the returned fields, stating freshness limits and the licensing/footer behavior. Combined with a 1-parameter schema it is close to complete; only the shape of the mismatch-suggestion response is left vague.

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 single parameter is already documented (name without article, e.g. 'Donau'). The description goes further by defining the matching rule against the Pegelbestand and the fallback suggestion behavior on mismatch, which the schema does not express.

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+resource: returns all current gauging stations (Pegelmessstellen) on an Austrian water body, listing exactly which fields come back (value, unit, measurement time, location, tendency). The 'an einem Gewässer' scope contrasts cleanly with the sibling pegel_in_der_naehe (by location), so an agent can pick between them without opening a 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?

Gives explicit invocation conditions: the water-body name must match the official Pegelbestand, and mismatches return suggestions, plus three example questions that model the expected input. It stops short of naming alternatives (e.g. hochwasserlage for warnings or pegel_in_der_naehe for proximity), so routing guidance is implied rather than complete.

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?

Annotations already declare readOnlyHint, openWorldHint and destructiveHint, so the safety profile is covered. The description adds genuinely useful behavior: data refreshed at most hourly, a hard cap of 20 results sorted by distance, the explicit disclaimer that this is not an official warning, and the license attribution appended to the answer.

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 core purpose, output contents, freshness, caveat and examples are front-loaded in a compact block with no filler sentences. The example questions are the only slightly redundant element, but they earn their place as disambiguation aids.

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?

With no output schema, the description fully specifies the return payload (per station: water body, value with unit, measurement time, low/mean/high flow stage, trend), plus result ordering, count limit, data staleness and the license footer. Nothing an agent needs to call this correctly or interpret the response 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 100% and both parameters (ort with its three accepted formats, radius_km with range and default) are fully documented in the schema itself. The description only alludes to the search area and the 20-result cap, adding nothing about parameter syntax or formats, so the baseline 3 applies.

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 names a precise resource (current gauge stations for water level or discharge from the Hydrographic Service), its scope (radius around an Austrian municipality), ordering (by distance) and cap (max 20), so the agent knows exactly what it returns. It does not explicitly name the nearest sibling, pegel_an_gewaesser, but the municipality-radius framing implicitly separates the two.

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 three example questions ("Wie hoch ist die Enns in Steyr?", "Welche Pegel gibt es rund um Schärding?", "Steigt das Wasser bei Hallein?") give concrete selection context, and "Keine amtliche Warnung" signals the boundary against a flood-warning tool such as hochwasserlage. No explicit when-not or named alternative is given, so it stops short of a 5.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so safety is covered. The description adds genuine behavioral context beyond that: it discloses the remaining request quota per source and that attributions are reproduced verbatim as the provider requires, which the annotations do not convey.

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 the return contents and then adds example questions that earn their place by illustrating usage. The long field enumeration is slightly dense but every item is informative rather than 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?

With zero parameters and no output schema, the description carries the full burden of describing the return payload, and it does so thoroughly (license, license link, mandated attribution, link, dataset, DOI, status, processing notes, quota). Nothing an agent needs to invoke and interpret it 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?

The tool takes zero parameters, so per the rubric the baseline is 4. There is nothing for the description to clarify regarding inputs, and it correctly does not attempt to.

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 ('Listet') and resource ('alle Datenquellen dieses Servers') and enumerates the exact fields returned (Lizenz, Link, Quellenvermerk, DOI, Stand, Kontingent). This clearly distinguishes it from the sibling tools, which are all data-value queries (Pegel, Wetter, Niederschlag), not metadata.

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?

Three example questions ('Woher stammen die Daten?', 'Unter welcher Lizenz...?', 'Wie viele Wetterabfragen...?') make the usage context concrete. It stops short of naming explicit alternatives or when-not-to-use conditions, so it is clear but not exhaustive.

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?

Annotations already declare readOnly, openWorld and non-destructive, so safety is covered. The description adds real behavioral context beyond them: hourly model at 1 km resolution, horizon up to 61 hours, the 6-hour block + daily output shape, the CC BY 4.0 attribution footer, and the disclaimer that this is not an official severe-weather warning.

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-loaded with the core purpose, then variables, then model/limits, then caveat and attribution. The example questions earn their place as usage anchors, though the response-format and license sentences could be tightened.

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?

With no output schema, the description compensates by enumerating returned fields and the attribution footer, and the annotations cover the safety profile. Missing only explicit sibling routing and pagination/response-size notes, which are minor here.

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 100%, so both parameters are fully documented in the schema (ort formats, stunden 1-61, default 48). The description only echoes the 61-hour horizon and does not add syntax or fallback behavior beyond what the schema already states; baseline 3 applies.

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 resource and scope: forecast for an Austrian municipality, listing the exact variables returned (temperature min/max, precipitation, snow share, gusts, wind, snow line) plus daily values. However, it never names or distinguishes itself from close siblings like niederschlag_jetzt or lage_am_ort, so the agent must infer the boundary.

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 example questions ("Regnet es heute Abend in Steyr?", "Wie warm wird es morgen in St. Pölten?") give concrete use contexts, and "Keine amtliche Unwetterwarnung" sets a when-not boundary. But no alternative tool is named for cases the agent might actually want (e.g. current precipitation or flood levels).

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