Amtsblick

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

Annotations already cover read-only, non-destructive, open-world. The description adds important behavioral context: classification comes from source data, no own warning levels are computed, no official warning, and the response must cite data source with license. It also describes what is returned, which is valuable without an output schema.

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 the core purpose, then no-data cases, caveats, examples, and citation instruction. Every part serves an agent need; length is justified by the tool's complexity, though it could be slightly 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?

Given no output schema, the description adequately explains returned content (grouped stations with tendency, no-data stations with name/water body/municipality). It also includes data provenance and warning caveats. An agent has enough to call and interpret the tool 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 100% and the single optional parameter is fully documented in the schema. The description only implies regional filtering through an example question ('Niederösterreich') and adds no syntax or semantics beyond the schema, so 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 (Pegelmessstellen reporting at least erhöhte Wasserführung) and the grouping/conditions, plus no-data stations. It does not name any sibling tool or explicitly contrast with alternatives like pegel_an_gewaesser or lage_am_ort, so it is clear but lacks sibling differentiation.

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 example questions that imply when to use (nationwide flood situation, state-level, no-data stations). It does not state when not to use or point to sibling tools for local gauge queries, so guidance 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/non-destructive, so the safety profile is covered. The description adds genuine behavioral context beyond them: the water/pegel section is conditional on the water module being active, the 15 km radius is disclosed, and it states this is not an official warning and that the data source plus license must be cited from the 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?

Front-loaded with the aggregate scope before the disambiguation and examples; each sentence carries information (parts returned, sibling routing, caveat, citation duty). It is on the long side and the example questions add bulk, but nothing is redundant.

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, so the description must explain the return value — and it does, enumerating all returned components and the 15 km / 3h / 24h bounds, plus the conditional water section and the citation requirement. An agent has everything needed to call and interpret it.

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 baseline is 3, but the description adds domain meaning the schema does not: the value must be an Austrian municipality, and the 'wenn das Modul Wasser aktiv ist' framing clarifies what the single lookup feeds into. This modestly exceeds the schema baseline.

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 (aggregate overview) plus resource (Austrian municipality situation) and enumerates exactly what is bundled: current weather, 3h nowcast, 24h forecast, and optional nearby gauges. It explicitly names the sibling detail tools it is not, so it is distinguishable without opening any 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 an explicit routing rule — use wetter_prognose, niederschlag_jetzt or pegel_in_der_naehe for details — and adds three concrete example questions showing the intended broad-overview use case. When-to-use and when-to-use-something-else are both covered.

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 cover readOnly/openWorld/non-destructive, but the description adds real behavior: a fallback to hourly forecast values when the nowcast is stale, a statement that the response flags this, a disclaimer that it is not an official severe-weather warning, and an instruction to cite the data source with license.

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 the core scope, then fallback behavior, disclaimer, examples and output instruction. The example questions and the citation instruction are useful but add length; still every part serves a purpose.

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 return-value burden and does so adequately by explaining the 15-minute nowcast, the hourly fallback, and that source/license appear at the end of the summary. Nothing critical for correct invocation is missing, though return-format details remain thin.

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 'ort' parameter is already fully documented with accepted formats (municipality, GKZ, coordinates). The description adds no syntax beyond the schema, 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?

States a specific verb+resource with scope: precipitation for the next 3 hours in 15-minute steps for an Austrian municipality, plus temperature, wind and gusts. It also implicitly distinguishes itself from wetter_prognose by scoping to the near-term nowcast window.

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?') make the intended use concrete, and the fallback to hourly forecast values is described. It doesn't explicitly name sibling tools like wetter_prognose as alternatives, so a 4 rather than 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?

Beyond the annotations (readOnly/openWorld/idempotent), the description discloses non-obvious behavior: exact-then-fuzzy fallback, umlaut and 'St.'/'Sankt' normalization, and that ambiguous names return a list rather than a single record. It also states a post-call obligation (cite data source and license), which nothing in the structured fields conveys.

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 and behavior are front-loaded in the first two sentences, with examples and the citation instruction following. Slightly busy due to the example list and the license reminder, but every part maps to real behavior, so nothing is wasteful.

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 correctly fills the gap by naming the return fields and explaining list output for ambiguous names. Minor omissions remain (e.g., limits on the result list, ordering), but the definition is sufficient 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 100% and the single 'text' parameter description already documents name-typo tolerance, the 'Name, Bundesland' form, five-digit GKZ, and the 'Breite, Länge' coordinate format. The description mostly restates these, so the baseline 3 applies with no meaningful added syntax detail.

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 (Sucht) and resource (österreichische Gemeinden) plus the three accepted query modes (Name, GKZ, Koordinate) and the returned fields (GKZ, Bezirk, Bundesland, Mittelpunkt). This is clearly distinct from the weather/water siblings, none of which deal with municipality lookup.

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 ('In welchem Bezirk liegt Steyr?', 'Welche Gemeinden heißen Sankt Johann?', 'Zu welcher Gemeinde gehört 48.04, 14.42?') give concrete context for when to call it. There is no explicit when-not or named alternative, but the domain is unambiguous relative to the sibling set.

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 the safety profile is covered. The description adds genuinely useful behavior: the register is refreshed at most hourly (freshness/rate), it returns name suggestions on mismatch, and it explicitly is not an official warning. It omits return format/pagination detail, keeping it below 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?

It is front-loaded with what is returned, then constraints, then examples, with little waste. The trailing instruction about citing source and license is slightly appended but operational and justified.

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 return burden and does so by enumerating the returned fields. Freshness limits, the mismatch fallback, and the non-warning disclaimer give an agent enough to invoke and interpret it, though the exact response shape is only summarized.

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 already documents the format (name without article, e.g. "Enns"). The description adds meaning beyond the schema by requiring the name to match the register and disclosing that suggestions are returned on deviation, which an agent needs to handle input correctly.

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: retrieving all current measurement stations (with value, unit, timestamp, location, trend) for an Austrian water body. It clearly distinguishes the scope from a spatially-filtered sibling, but never names pegel_in_der_naehe or lage_am_ort explicitly, so the sibling boundary is only implied.

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 trigger examples ("Wie ist die Lage an der Donau?", "Welche Messstellen gibt es an der Mur?") make the intended use clear, and the name-matching rule with fallback suggestions sets expectations. It still does not state when to prefer this over pegel_in_der_naehe or hochwasserlage, so no explicit when-not 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?

Annotations already declare readOnly/openWorld/non-destructive, so the safety profile is covered. The description adds real behavioral context beyond them: a hard cap of 20 results sorted by distance, hourly data refresh, a 'not an official warning' disclaimer, and the requirement to cite the data source with license in the answer. It does not state what happens when the radius returns more than 20 stations, but overall this is well above the annotation baseline.

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 scope, then attributes, then examples, then the citation instruction – a sensible ordering. It is somewhat long, and the closing 'Nenne in deiner Antwort die Datenquelle…' instruction is output guidance rather than tool selection help, but every sentence still carries information.

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 full burden and does so: it enumerates the per-station fields (Gewässer, Wert mit Einheit, Messzeitpunkt, Lage/Stufe, Tendenz), the result ordering and cap, the data freshness, and the disclaimer. An agent has everything needed to call it and interpret the response.

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 both parameters (ort with its Gemeinde/GKZ/Koordinate forms, radius_km 1–100 default 15) are already fully documented. The description only restates the geographic scope (Austrian municipality) and adds nothing about accepted input forms or units, so 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 (Pegelmessstellen des Hydrographischen Dienstes), the scope constraint (Umkreis einer österreichischen Gemeinde, nach Entfernung sortiert, höchstens 20), and the returned attributes. It is clearly distinguishable from siblings like pegel_an_gewaesser (gauges on one water body) and hochwasserlage (flood situation overview), since it is explicitly a proximity search around a place.

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 concrete example questions ("Wie hoch ist die Enns in Steyr?", "Welche Pegel gibt es rund um Schärding?") make the intended use case unambiguous, and "Keine amtliche Warnung" implicitly marks the boundary with the flood-warning sibling hochwasserlage. What is missing is an explicit routing statement naming the alternative tool for official warnings.

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/idempotent/non-destructive/openWorld, so the safety profile is covered. The description adds value beyond that: it discloses that remaining request quota per source is included, and instructs the agent to reproduce attribution and license verbatim from the list — a behavioral/output constraint not derivable from the structured fields.

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 purpose sentence, then examples, then the verbatim-reproduction instruction; each sentence earns its place. The opening sentence is dense with a long field enumeration, but nothing is redundant padding.

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 enumerates the returned fields (license, license link, prescribed attribution, source link, dataset, DOI, status date, processing notes, per-source quota) thoroughly enough that an agent knows what it will receive. It also supplies formatting guidance for the answer.

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 the documented baseline of 4 applies. There is no parameter semantics to explain, and the description correctly spends no words on inputs.

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?

A precise verb + resource: 'Listet alle Datenquellen dieses Servers' and then enumerates exactly what each entry contains (Lizenz, Quellenvermerk, Link, DOI, Stand, Aufbereitung, Restkontingent). This is unmistakably distinct from every sibling, all of which return weather/water/location data rather than server provenance 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 concrete example questions map directly onto when to call it ('Woher stammen die Daten?', license per dataset, remaining quota). That is strong positive guidance, though the description never explicitly names an alternative or states when NOT to use it.

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, non-destructive and open-world access, so the safety profile is covered. The description adds genuinely useful context beyond that: hourly model at 1 km resolution, up to 61 hours of range, and a required attribution step (cite the data source with license). It does not discuss rate limits or failure modes, but with annotations covering safety this is adequate.

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 resource and content, followed by resolution/range, the warning caveat, example questions and the attribution instruction. Every sentence carries information, though the example-question block and attribution note make it longer than strictly minimal.

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 full burden of describing return values, and it does so thoroughly (6-hour blocks, listed variables, daily aggregates). It also communicates the resolution, time horizon and attribution requirement, leaving nothing an agent needs in order to call 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 both parameters (ort with its name/GKZ/coordinate formats, stunden with range 1-61 and default) are already fully documented in the schema. The description's mention of "bis 61 Stunden" echoes the schema rather than adding syntax or format meaning, 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?

States a specific resource (GeoSphere Austria forecast for an Austrian municipality) and details exactly what the response contains: 6-hour blocks with temperature, precipitation, snow share, peak gust, wind and snow line, plus daily values. This rich content description implicitly separates it from siblings like niederschlag_jetzt (current precipitation) and the flood/warning tools, though no sibling is named 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?

Provides three concrete example questions that map directly to the tool's forecast use case, and adds a boundary condition ("Keine amtliche Unwetterwarnung") telling the agent this is not for official severe-weather warnings. It stops short of explicitly naming alternatives for the current-conditions or flood siblings, so routing is left partly to inference.

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