ViaFrei

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

Annotations already establish readOnly, idempotent, non-destructive and closed-world, so the description is not carrying the safety burden. It nevertheless adds real behavior: data freshness ('~5 min old'), a mandatory attribution obligation ('Show attribution'), the fact that only in-force items are listed while future closures are counted separately in the headline, and cursor-based pagination. It does not discuss rate limits or caching, so a 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?

Most content earns its place, but it is delivered as long run-on sentences with heavy parentheticals and mixed German/English jargon, so the routing rule for closures has to be reconstructed by the reader. The key identity ('per motorway, current conditions') is front-loaded, but the middle sags with nested conditionals. It is dense rather than bloated, yet not well structured.

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 10-parameter, no-output-schema tool, the description covers what comes back (Ampel, jams, closures, roadworks, place/delay/speed/map), freshness, ordering of results, and pagination. The main omission is any statement of error or empty-result behavior (e.g. what 'frei' looks like when nothing is reported), which leaves a small gap for an agent 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 the baseline is 3; every parameter already carries a rich description including mutually exclusive combinations (land vs roads/place/lat/lon/radius_km). The description adds intent-level guidance (e.g. 'name every motorway (Munich→Berlin: A9)') but largely restates what the schema's own property descriptions say. With the schema doing the heavy lifting, the description clears the bar but does not exceed it.

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 opening clause names the resource and scope precisely: 'Per motorway (≤ 5), or one Bundesland's motorways with land', and enumerates the payload (Ampel, jams, closures, roadworks in force, place/delay/speed/map). It also explicitly separates itself from check_road_status, find_roadworks_ahead and get_train_departures. The telegram-style fragmentation ('an Ampel, then jams...') keeps it from being a clean verb+resource sentence, so it is not 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?

It gives an explicit use case ('asked about a named motorway now: frei/clear, Stau, delay, how it looks, or a LIST of closures'), explicit exclusions, and names the correct sibling for each exclusion (open/closed/gesperrt → check_road_status, dated/geplant Baustellen → find_roadworks_ahead, trains → get_train_departures, city streets → not held). The clock-vs-question rule for closures is spelled out with examples in both German and English. Nothing 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/idempotent/non-destructive and closed-world, so the safety profile is covered; the description adds scope limits (14 days, 11 entries), a mandatory attribution requirement, and the enumeration of source categories. It stops short of describing the shape or ordering of the response beyond the limit note, which keeps it off a 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?

Front-loaded with purpose, then use, then do-not-use, then limits and attribution — a correct priority order with no filler. It is dense to the point of being telegraphic ("NI, NW, HE, BW, MV, SN, TH" as bare abbreviations), which costs a little parseability but not much length.

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 8 optional parameters, no output schema, and rich structured fields, the description covers the decision space an agent needs: which input combination to use, when to ask the user for a town, horizon semantics, and attribution. The main residual gap is return-value expectations, which nothing else supplies since there is no output schema.

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 parameter descriptions are unusually thorough (road pattern semantics, place vs lat/lon precedence, vehicle enum behavior, horizon_days counting rules). The description restates the gist (pass Land/town as place, road vs place vs coordinates) but adds no syntax or semantics the schema does not already contain, 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 and resource (whether a motorway/B/Land road is open/closed/restricted now or soon) and enumerates the data sources it draws on: closures, jams, city/Land messages, Hamburg cameras, lorry limits. It explicitly distinguishes itself from siblings, so an agent can route 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 use trigger with a real utterance example ("A8 in diesem Moment gesperrt?"), then three named exclusions with the correct alternative for each: named motorway frei/clear or its jams → check_autobahn_traffic; dated roadworks → find_roadworks_ahead; named city street → no call at all. The "do not call" case is rare and valuable.

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 readOnly, idempotent, non-destructive, open-world, so the description only needs to add operational detail — and it does: broken equipment listed first, a hard cap of 50, silent disambiguation when a name matches several stations, step-free surveys only where one exists for non-rail stops, and the instruction to surface an attribution line. That is material behavior an agent cannot infer from 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 capability, then triggers, then exclusions — a sensible order, and the quoted example utterances do real routing work. It is dense and occasionally repetitive (the 50-item cap and broken-first ordering appear in both description and schema), but no sentence 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?

For a five-parameter read tool with no output schema, the description supplies what is missing: what an entry contains (place, state, reason), ordering and coverage guarantees, ambiguity handling, and the bilingual/attribution obligations. Nothing an agent needs to call it correctly is absent.

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 schema already explains limit ordering, eva_no exactness, station-versus-eva_no exclusivity, the facility filter rationale and the language default. The description restates the 50 cap and 'broken first', adding little parameter-level meaning beyond what the schema provides, 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 concrete verb and resource — reporting whether lifts and escalators at a railway station or Köln Stadtbahn stop are working, each with place, state and reason — and explicitly contrasts itself with get_train_departures, get_departures and describe_station. An agent can route on it 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?

It gives positive triggers (step-free access, broken lifts, wheelchair, pram) with quoted example queries in German and English, explicit exclusions (departures, platforms, delays, whole-station overview) and the sibling to use for each. The distinction between a railway/Köln Stadtbahn stop and other tram/U-Bahn/bus stops is also stated.

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 (readOnly, idempotent, non-destructive, closed-world), so the bar is lower, and the description still adds real operational context: 'No per-line figures', the region-level granularity ('data is filed at Kreis level'), and a licensing obligation the agent must honour ('show attribution' under CC BY-SA / CC BY 4.0). It does not describe return shape beyond the metric list, but attribution and aggregation limits are non-obvious traits the annotations could 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?

Front-loads the resource and what it returns, then routing, then constraints — the right order. It is information-dense but packed into a few long sentences with parenthetical examples, making it slightly harder to scan than an ideally partitioned definition.

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: it names the metrics, the trend comparison, and the in-force service alerts (diversions, closed stops). Combined with usage boundaries and licensing, an agent has everything needed to call and interpret 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 lat/lon/region/language/window_min are already fully documented, including the lat+lon-vs-region mutual exclusion and the 'en' language pitfall. The description largely restates the schema (window ≤ 120 min, region scope) rather than adding syntax or format detail, 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?

Opens with a specific verb+resource ('How punctual public transport is now in one German region') and enumerates the metrics returned (late share, skipped stops, cancellations, trend, alerts). It explicitly names the sibling it is not (get_train_departures) with a concrete counter-example, so an agent can route without opening either 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 a positive trigger ('Use when asked whether buses and trains run normally, or a strike, storm or works disrupt them') and a negative one ('Do NOT use for a station's departures or a line from a named DEPARTURE station'), naming the alternative tool. The destination-vs-departure distinction ('nach …'/'zum …' is not one) is unusually precise 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?

Annotations already declare readOnly/openWorld/idempotent/non-destructive, so the safety profile is covered and the description only needs to add behavior — which it does: the official text is returned unaltered, an attribution line must be shown, and the road-surface forecast is only added at a town or coordinate. It does not discuss cost, latency, or what happens on an unknown place, but that is largely handled in the parameter 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-loaded with what is returned before the conditional road-weather extra and the do-not-use clause; every sentence carries information. It is dense with parenthetical German terms, which slightly taxes scanning but each one disambiguates a domain term the agent will meet in the output.

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 by naming the level scale, area, validity, official text, road condition and road temperature. The one real gap is the instruction 'Show the attribution line' without stating what that line is, leaving the agent to invent or fetch 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 the baseline is 3; the description still earns above that by tying the place/lat+lon duality to concrete behavior ('At a town or coordinate it adds the DWD road-surface forecast'), which tells the agent why the input choice changes the answer. The min_level filtering caution lives in the schema rather than the description, so it is not double-counted here.

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 specific verb and resource: returns official DWD weather warnings in force for a place, enumerating the warning types (storm, snow, ice, heavy rain, thunderstorm, heat) and the fields returned (Warnstufe 1–4, area, validity, official text). It also states the secondary payload (Straßenwetter-Prognose for the nearest road-weather stations) and explicitly names the sibling it is not (check_autobahn_traffic), so an agent can separate it from check_road_status and the traffic tools 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 when-to-use list (weather on a trip, safe driving, storm or snow warnings, icy roads/Glätte, Glatteis) and an explicit when-not list with the alternative named ('Do NOT use for a general forecast (not offered) or jams (check_autobahn_traffic)'). Nothing about routing between this and its siblings 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 establish readOnly/idempotent/no-open-world safety, so the bar is lower, and the description adds real context beyond them: attribution source (OpenStreetMap ODbL 1.0), the requirement to show the attribution line, and a caveat that administrative fields come from the containing municipality rather than the nearest Kreis point, with a border warning. It stops short of stating any rate limits or error behavior, but the provenance and licensing obligations are valuable disclosure.

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 verb and return content, and every clause carries information. Slightly dense and mildly repetitive ('this only goes coordinate to words' restates the opening), but no wasted 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?

With no output schema, the description enumerates the returned fields and the administrative-source caveat an agent needs to interpret them. Combined with full schema coverage and annotations, nothing needed to call or read this tool 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 schema already explains lat/lon WGS84 ranges and the language default/enum behavior in detail. The description adds no parameter-level syntax or format guidance of its own, 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 and transformation ('turns a coordinate into words') and enumerates the return content: nearest address, settlement, motorway junction, Gemeinde/Kreis/Land, low-emission zone. It also names the sibling tools it is not, so an agent can distinguish it 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?

Explicit positive trigger ('Use when you already HAVE a lat/lon') and explicit exclusion ('Do NOT use to look up a place or address BY NAME — that is find_place, find_poi or find_address'), naming the three alternatives. Routing is unambiguous.

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 only declare it as a safe idempotent read; the description adds real behavioral context beyond that: out-of-service lifts are listed first, delays are live, ambiguous station names return a candidate list with a follow-up question rather than an error, and an attribution line must be shown. These are non-obvious output and interaction behaviors the agent could not infer 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-loads the resource and its contents, then the triggers, then the exclusions, then the attribution note — a sensible order with no filler sentences. It is dense and somewhat longer than needed, and the trailing "Show the attribution line." sentence is a dangling instruction rather than integrated into the flow.

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?

There is no output schema, yet the description effectively describes the return payload (address, step-free status, facilities, departures with delays, alerts, parking, charging) plus the disambiguation case. For a four-parameter read tool this leaves nothing an agent needs in order to call it or 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 100%, so the schema already explains eva_no, station, language and departures in depth, including the mutual exclusivity of eva_no/station and the enum default trap. The description adds no parameter-level meaning of its own, 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?

Opens with a specific verb+resource ("one German railway station") and enumerates the exact payload: address, step-free status, lifts/escalators, platforms, departures with live delays, alerts, parking, charging. It also names the sibling tools it is not (check_station_facilities, get_train_departures, get_departures), so an agent can route 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 explicit positive triggers with three real sample questions ("Was gibt es am Bahnhof Köln Hbf?", "is Hannover Hbf step-free today?") and explicit exclusions mapped to the correct alternative for each (single lift → check_station_facilities, one train → get_train_departures, bus stop → get_departures). Both the when and the when-not are covered with named alternatives.

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 read-only, idempotent, non-destructive, closed-world, but the description adds real behavioral detail beyond them: a hard cap of 5 points, deduplication of a door mapped twice, distance reporting for far-apart points, handling of multi-town results as a question, and an ODbL 1.0 attribution obligation. That is material context annotations do not carry.

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 purpose and immediately follows with the disambiguating rules, then edge cases and licensing. It is dense and every sentence carries information, though the run-on construction packs several distinct rules into single sentences and could be separated slightly more cleanly.

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 explaining what is returned (coordinate plus named objects or none) and how the coordinate is reused by other tools. Required input constraints, the multi-result ceiling, dedup behavior, and the legal attribution requirement are all covered for a tool of this complexity.

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 schema already documents query, limit, and language, including the town/postcode requirement and the language default. The description mostly reinforces these rather than adding new parameter meaning; the lat/lon pass-through is a downstream usage hint, not an input detail. Baseline 3 is 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?

States a specific verb and resource (looks up a street address) plus exactly what it returns (coordinate + named OSM objects at it, or none). It explicitly names the siblings it is not (find_place, find_poi) and the input shape that selects it, so an agent can distinguish it 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 trigger ('person gives a STREET AND NUMBER'), an explicit exclusion ('never who lives there'), and routes two alternative cases to named siblings (find_place for town/district/station, find_poi for named company/shop/landmark). When-to-use and when-not-to-use 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 declare readOnly/idempotent/non-destructive, and the description adds genuinely non-obvious behavior beyond them: the ≤25 km radius and ≤10 sites caps, the rule that missing availability is "unknown, never free", and the obligation to show the attribution line. These are exactly the traits an agent cannot infer from structured fields and would otherwise get wrong.

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 what is returned, then filters, then use/don't-use, then hard limits — a sensible ordering with no filler sentences. It is dense to the point of being a run-on in the middle (filter list plus conditions parenthetical), which costs a point but no sentence is truly wasted.

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 12-parameter, no-output-schema tool this is complete: it describes the shape of the answer (fields returned), the caps, the unknown-vs-free semantics, and the attribution requirement. Nothing an agent needs in order to call it correctly or interpret the result 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 schema already documents every parameter in depth (including enum meanings, units, and omission advice), so the description's filter summary (plug, power, operator, free now, conditions) largely restates structured data. The one added semantic, that absent availability must not be treated as free, is behavioral rather than parameter-specific. Baseline 3 is 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?

Opens with a specific verb and resource ("Returns EV charging sites near a place or coordinate") and immediately enumerates the returned fields (operator, plugs, max power, price per kWh, live-free status). It also names the two sibling tools it is NOT for (find_cheapest_fuel, get_driving_rules), so an agent can separate it from the fuel and rules tools 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 trigger phrasings in the user's own words ("Wo kann ich laden?", "CCS 150 kW near Leipzig", "ist gerade eine Säule frei?") plus a hard exclusion list for petrol/diesel and E-Kennzeichen rules with the correct alternatives named. The radius cap and result cap are stated as operating constraints, so the agent knows both when to call and the limits of what it can ask for.

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 the safety profile (readOnly, idempotent, openWorld, non-destructive), yet the description adds real behavioral context: hard caps (25 km radius, 10 results), that each line reports the age of its price and opening-hours claim, that prices are consumer information only, and that an attribution line plus MTS-K note must be surfaced. The one gap is that nothing is said about failure or empty-result behavior when no station falls in the radius.

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 purpose, then exclusions, then limits, then the routing alternative, then the compliance note — a sound ordering with no filler sentences. The 'Radius ≤ 25 km, at most 10 stations' clause mildly duplicates schema constraints, which costs a point but not much.

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?

Seven parameters, all documented, no output schema required because the description itself lists the returned fields, and the legal/compliance obligation for the attribution and MTS-K note is called out. For a read-only lookup with full annotation coverage, nothing an agent needs in order to call it correctly or report results 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%, so every parameter including fuel, place, radius_km and language is already fully documented in the schema, and the description adds no syntax or format detail beyond restating the caps. It contributes a scope qualifier ('one fuel grade') but the heavy lifting is done by the schema, which is the baseline-3 case.

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 ('Returns the cheapest stations for one fuel grade near a place or coordinate') and enumerates what each result carries: price per litre, brand, address, distance, open state. It is immediately distinguishable from the nearest sibling, find_fuel_station, by its price-ordering and cheapest-first framing.

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 trigger ('where the user asks where to fill up or what fuel costs') and explicit exclusions with named alternatives: EV charging -> find_charging_station, traffic -> check_autobahn_traffic, price history -> not this tool. It also routes to find_fuel_station for brand, name, open-now, named-time or nearest-first queries, so the agent never has to infer the boundary.

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?

The annotations already declare read-only, idempotent, open-world behavior, so the description does not need to restate safety. It adds useful context beyond annotations by noting that every result carries attribution, the MTS-K note, and the age of each price and opening-hours claim. It does not cover empty-result or provider-failure behavior, but for a read-only search tool this is a strong addition.

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 core action and scope, then usage guidance and exclusions, then output-freshness context. There are no filler sentences; every clause contributes to selecting or interpreting the tool.

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 13 parameters, full schema coverage, annotations, and no output schema, the description supplies what structured fields do not: the decision boundary against alternatives and the fact that results carry attribution and age metadata. Combined with the richly documented schema, an agent has enough information to call the tool correctly for the main use cases.

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 parameter descriptions themselves explain coordinates, place syntax, fuel grades, sorting, open_at formatting, language behavior, radius limits, and the open_now versus whole_day distinction in detail. The description's filter summary ('grade, brand, name, open now, open at a time you name, open 24 h') mirrors those schema semantics without adding new meaning. Baseline 3 is 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 verb and resource: finds filling stations around a place or coordinate with filters and sorting. It explicitly distinguishes itself from siblings by naming find_cheapest_fuel and find_charging_station and describing their different questions. An agent can identify the tool's scope without opening 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?

It gives explicit when-to-use guidance ('Use when the question is WHICH station') and concrete examples such as closest diesel, an ARAL open tonight, or a specific forecourt. It also gives explicit when-not-to-use guidance, routing the cheapest-fuel question to find_cheapest_fuel and EV charging to find_charging_station.

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 (readOnly, idempotent, non-destructive), and the description adds substantive context beyond them: the 150 km radius and 10-station caps, the fact that no live availability or price exists, that the nearest station beyond the radius is still named, and that an attribution line is shown. These are exactly the data-quality caveats an agent needs before promising results.

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 scope are front-loaded in the first clause, and every later sentence carries routing or constraint information. It is dense but slightly overstuffed — the parenthetical German query examples and the attribution note are useful, while a couple of clauses restate schema limits.

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?

There is no output schema, yet the description names the returned fields (operator, address, pump pressures, opening hours, record age), the ordering, the result caps, and the absence of live availability/pricing. Nothing an agent needs to call this correctly or set expectations with a user 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%, so the baseline is 3; the description earns above that by explaining the vehicle parameter in domain terms (700 bar car pump vs 350 bar truck/bus pump) and restating the radius/limit ceilings as answer-shape constraints. It doesn't add syntax detail beyond the schema for place or language, which keeps it from a 5.

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 ('Returns hydrogen (H2) filling stations near a place or coordinate, nearest first') and enumerates the returned fields, so the agent knows exactly what it gets. It explicitly names the two nearest siblings it is not (find_fuel_station, find_charging_station), making it separable 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 explicit when-to-use triggers including the German phrasings a user would actually type ('Wasserstofftankstelle', 'H2 tanken', 'hydrogen station near me'), plus explicit when-not-to-use routing to find_fuel_station and find_charging_station. It also closes the gap for LPG/CNG by instructing the agent to say those aren't held.

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 and destructiveHint=false, so safety is covered; the description adds non-annotation behavior instead: the 15 km radius ceiling, result caps of 3 per category (5 per need), per-category radii for everyday places, and that source attribution is emitted. It stops short of describing result ordering or what fields each entry carries, which keeps it at 4 rather than 5. Nothing contradicts the annotations.

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?

Two sentences, both front-loaded: capability first, exclusions second, in the order an agent needs them. The exclusion sentence is a dense comma-list but each item is a distinct routing decision, so little is wasted; slightly heavy punctuation costs it a point.

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 6 parameters, no required fields, no output schema and annotations present, the description covers capability, trigger, exclusions, radius limits and result volume — enough to call it correctly. It leaves the shape of individual results (fields per entry, ordering) unstated, which is a minor gap given the absence of an output schema.

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 baseline is 3; the description still contributes beyond it by stating the radius bound and the category-cap semantics ("up to 3 per category (5 per need)") and the rule that daily-life categories ignore radius_km in favour of their own 1–2 km radius. It does not restate lat/lon vs place trade-offs, which the schema already handles 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 names a specific retrieval task ("overview of what is around a place or coordinate") and enumerates the returned content: fuel, EV charging, parking, nearest railway station and motorway junction with distances, plus opt-in everyday categories. It also states the scope limit that everyday places appear "only when named in categories", which is a real behavioral distinction, not a restatement of the name.

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?

It gives an explicit trigger ("Use when asked 'what is around me'") and an explicit seven-way exclusion list routing to find_cheapest_fuel, find_charging_station, find_parking, find_place/find_poi/find_address and describe_location. This is the strongest form of sibling differentiation: the agent can pick the correct tool on the first try without opening any schema.

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 only declare a safe read operation; the description adds substantive behavior beyond that: results arrive as separate per-source lists (ODbL vs CC BY-SA, up to three), radius ≤ 25 km, ≤ 10 sites per list, and a critical semantic caveat that a missing "free now" means no published count rather than full. It also states the attribution obligation, which is a post-call requirement not derivable from 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 capability, then usage, then caveats and output quirks in priority order. It is dense and the sentences are long, but every clause adds a fact an agent would otherwise get wrong; only the parenthetical example triplets verge on redundancy.

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 10-parameter, enum-heavy, no-output-schema tool, the description covers the gaps structured data cannot: source-list splitting, the free-spaces ambiguity, absence of pricing, and the attribution duty. Nothing an agent needs in order to call it correctly and 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%, so the baseline is 3 and the schema carries param definitions. The description still adds cross-parameter rules that are easy to miss: road OR place OR lat+lon but never two, and that the per-source split means up to three lists. These constraints reinforce rather than merely repeat the schema, warranting a point above 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+resource (parking search) with explicit scope: kinds covered (lorry parks, car parks, P+R, disabled bays) and attributes returned (spaces, amenities, free spaces). It names two siblings it is not (find_cheapest_fuel, find_charging_station), so an agent can route 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 both when-to-use and when-not-to-use with concrete trigger phrases ("Parkhaus in Köln", "Rastplatz A3", "P+R") and explicit exclusions routed to named alternatives. It even specifies the fallback behavior for price questions ("say so, no call"), which is a real decision rule.

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 the safety profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint=false), so the bar is lower. The description still adds non-obvious behavior: a hard cap of 10 results, a 200 km radius ceiling, that the official AGS/RS key appears only in the structured result, and that every result carries an attribution line the agent must surface to the user. It does not describe ranking/tie-breaking or fallback behavior when nothing matches.

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 opening sentence front-loads purpose and payload, and the when-to-use, exclusion, and limit sentences each carry distinct information. It is longer than strictly necessary (the disambiguation point is stated twice, via `near` and via the Neustadt example), but nothing is 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?

With 8 parameters, no output schema, and annotations covering only safety, the description supplies what the structured fields cannot: the result shape, the result cap, the radius ceiling, the attribution obligation, and the ambiguity-recovery workflow. 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 coverage is 100%, so the baseline is 3, and the schema already documents every parameter including the important `language` default trap. The description adds strategic framing rather than new syntax: it explains that `near` is the disambiguation lever for same-named places and reiterates the 10-result/200 km bounds, tying the parameters into one workflow.

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 ("Looks up a place name and returns every match") and enumerates the returned fields (kind, population, English name, coordinate, AGS/RS key). It explicitly contrasts itself with a sibling ("Do NOT use to find a company, shop or landmark: call find_poi"), so an agent can separate it from find_poi and find_address 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?

It gives three concrete trigger conditions (person asks where somewhere is, a coordinate is needed for another tool, recovering from an ambiguity error) plus an explicit exclusion routing to find_poi. The ambiguity-recovery role ("this is where you find out which Neustadt is which") is unusually actionable 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, idempotent, non-destructive, and not open-world. The description adds operational constraints: pagination limits (25 per page, 50 via cursor), radius limit (≤50 km), coordinate pass-through, and attribution requirement (ODbL 1.0). These are valuable behavioral details beyond the safety profile.

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 and usage rules. Every sentence is dense with actionable information—examples, exclusions, pagination, attribution—and none is wasted.

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 10-parameter tool with no output schema, the description covers selection criteria, key parameter usage, pagination, radius limit, and legal attribution. It provides everything an agent needs to invoke 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 description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds minor guidance (e.g., 'Give in when you can') but largely repeats constraints like page size and radius that are also in the schema. Baseline 3 is 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?

States a specific verb (find) and resource (business or landmark) with examples, and explicitly distinguishes from siblings by naming what it is NOT for (towns, fuel, charging, parking). An agent can select it without ambiguity.

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 when-to-use (person names a THING) and when-not-to-use (town, district, station, fuel/charging/parking), and recommends using 'in' for speed. Names alternatives implicitly via sibling tools, leaving nothing 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 only declare it a safe, idempotent read; the description adds real operational constraints the annotation cannot carry: one road/place per call, ≤92-day window, max 20 sites, partial Länder coverage with named exclusions (Kreisstraßen, other Länder), and a mandatory attribution instruction. It also discloses the text/structured split and that the total count is always reported.

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 purpose, then use-when, then do-not-use with alternatives, then hard limits and attribution — a clean decision order with no filler. It is dense to the point of being telegraphic ('BY: B only', 'Baustellen with neither date nor geplant'), which risks a slightly slower first parse but never wastes a sentence.

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 still tells the agent what comes back (where, impact, dates, map links), how results are ordered and capped, and that the readable text truncates at 10 while the structured half holds all sites. Combined with coverage limits and attribution, nothing needed 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 coverage is 100%, so baseline is 3; the description still adds cross-parameter rules the per-field text only implies — 'ONE road/place per call' as a mutual exclusivity constraint, the 92-day cap, and default-window behavior ('7 days' being right for a drive, widen only when asked). The rest (road format, place radius, language default) is largely restated from the schema.

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 ('Returns roadworks PLANNED'), the exact scope of road/place types and Länder, and what each result carries ('where, impact, dates, map links'). An agent can distinguish it from check_autobahn_traffic and check_road_status 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 explicit positive triggers ('when a date or window is named, it says geplant, or how long a site lasts') with a worked example query, and explicit exclusions naming the alternative for each ('Do NOT use when more than one motorway is named, for the situation this minute, or for Baustellen with neither date nor geplant — all three are check_autobahn_traffic; whether a road is open — check_road_status').

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 readOnly/idempotent annotations, it discloses operational caps (radius ≤ 5 km, ≤ 20 stations), a coverage gap (e-scooters are not covered), data-freshness signalling (data age), and an output obligation (each source's attribution is shown). These are exactly the traits an agent needs that structured fields do not carry.

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, trigger phrases, exclusions and limits are front-loaded in that order, so the agent can stop reading early. It is dense but a few clauses (the long place-resolution aside, the language rationale) run longer than needed, keeping it just short of maximally 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?

Seven parameters, no output schema, and the description covers everything an agent needs: what is returned, geographic and count caps, exclusions (e-scooters, parking, generic nearby), the required-input rule, and even language handling. Nothing material is left to inference.

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 the baseline is 3, but the description adds semantics the schema lacks: although zero parameters are formally required, it states that a place or lat+lon is required (and to ask the user otherwise), and that when both are given the answer is anchored to lat+lon with place as a label, refused if they lie too far apart. only_available is left entirely to the schema, which documents it 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?

States a specific verb and resource (returns rentable shared bikes near a place or coordinate) and enumerates exactly what comes back: stations with bikes and free docks, plus free-floating bikes, with distance and data age. It even names the covered providers (nextbike incl. KVB Rad, MyRadl, VAG_Rad; Donkey Republic), so the agent knows the scope precisely without opening 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?

Gives explicit trigger phrases in both languages ("Leihrad", "Fahrradverleih", "nächstes nextbike", "bike share near me") and explicit exclusions routing to named siblings: find_parking for parking and find_nearby for a general look around. The when/when-not pair is fully spelled out with the alternative tool named in each case.

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 this a safe, idempotent, closed-world read, so the bar is lower; the description still adds non-obvious behaviour: the mandatory § 23 Abs. 1c StVO notice shown verbatim, the attribution line in the output, the 25 km area cap, and the hard rule never to read locations to a driver or act as a live warning. It does not say what the result payload looks like or how truncation beyond `limit` is surfaced, which keeps it below a 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?

Front-loaded with what the tool returns, then when to use, then safety constraints and exclusions — a sensible order with no filler. It is dense and reads as a run-on in the safety section (several clauses in one sentence), costing a point on structure but not on substance.

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 still covers scope, the legal notice requirement, attribution, area limit, sibling exclusions, and the driver-safety refusal rule — everything an agent needs to invoke and phrase the result correctly. Nothing material is missing for a read-only lookup of this complexity.

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 schema already explains lat/lon vs. place, the language enum, and the radius. The description only echoes the area cap (≤ 25 km) and the by-kind/by-street grouping, adding little beyond the structured fields — 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 and resource (returns published speed-enforcement locations), enumerates the kinds covered (fixed, red-light, section control, mobile checks, measuring sites) and the keying (by kind and street). It explicitly rules out the two sibling tools an agent might confuse it with — get_driving_rules for speed limits and check_road_status for roadworks.

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 concrete trigger phrasing ("Blitzer Köln"), a temporal condition (planning vs. driving now), and an explicit do-not-use list naming the correct alternatives. It even prescribes the fallback behaviour when the user says they are driving — offer the list for before the trip or a stop — so no routing decision 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 read-only, idempotent, non-destructive. The description adds valuable context beyond that: coverage window (≥48 h ahead, ≤3 days), result cap (15 per call), attribution requirement ('Show the attribution line'), and directs delay/punctuality checks elsewhere. It does not cover error behavior or return format, so not a full 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?

Front-loaded with purpose, then usage and constraints. The description is information-dense and every sentence contributes, but it is quite long and telegraphic in places (e.g., 'Holds ≥ 48 h ahead, ≤ 3 days. 15 per call. Show the attribution line.'), which slightly reduces scannability.

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 complexity (10 parameters, multiple input modes, open-world stop data) and the absence of an output schema, the description covers routing, coverage limits, attribution, and sibling alternatives. An agent has enough to invoke correctly without reading external docs.

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 schema already documents all 10 parameters in detail (including examples and constraints). The description adds no additional parameter-specific meaning beyond what the schema provides; baseline 3 is appropriate when the schema carries the full parameter burden.

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: 'Scheduled departures from any German stop' and enumerates the modes (bus, tram, U-/S-Bahn, train, ferry). Immediately distinguishes itself from the sibling get_train_departures by excluding a rail station's trains today.

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 names when to use (when asked when a bus/tram/U-Bahn/ferry goes, for another day or time >2 h away, for nearest stops around a place) and when not to (rail station's trains today → get_train_departures; punctuality → check_transit_disruption; A-to-B journeys → no call). Provides concrete German example phrases.

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/idempotentHint/openWorldHint=false, so safety is covered. The description adds real context beyond that: results are 'sourced, dated', attribution must be shown, and it disclaims 'not legal advice' — a disclosure an agent needs to relay. It does not describe result completeness or how boundaries are versioned, keeping it below a 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?

Front-loaded with the resource and the use/don't-use routing before the parameter notes, which is the right order. The nine-item enumeration of topics duplicates the `topic` enum description verbatim in places, a small redundancy that costs some density, but no sentence 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 still covers scope, alternatives, parameter routing, sourcing/attribution and the legal disclaimer — enough to call it correctly. It never states what the default no-parameter call returns beyond the schema note, which is the one remaining gap for a 6-param, all-optional tool.

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 the baseline is 3. The description goes slightly beyond by summarizing the interplay between parameters ('city narrows to its zone; place or lat+lon checks a point against the published zone boundaries'), which lets an agent choose the right selector without reading all six 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?

States a specific verb and resource ('Returns the German road rules a visitor needs') and enumerates the covered domains: Umweltzone/Feinstaubplakette, speed limits, winter tyres, alcohol, lorry ban, tolls, Rettungsgasse, equipment, EVs. An agent can immediately distinguish this from check_autobahn_traffic, find_charging_station and check_road_status.

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?

Explicit positive trigger ('Use when someone drives through Germany or asks whether they may enter a city or street') plus explicit exclusions naming the alternative tools for live traffic/closures and charger lookup. Both when-to-use and when-not-to-use are stated, with the sibling named for each exception.

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 read-only, idempotent, open-world and non-destructive, so the safety bar is low; the description still adds hard behavioral facts: ≤15 rows and ≤120 min caps, times always returned in Europe/Berlin regardless of the offset passed, an ambiguous station name returning a disambiguation list rather than a guess, and a mandatory attribution line in the output.

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 comes first, then routing rules, then hard limits and the attribution requirement — a sensible front-load with no filler. It is, however, written in a compressed telegram style ("A line with no DEPARTURE station … — check_transit_disruption") that occasionally costs a re-read; parentheses and dashes carry a lot of load.

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 7-parameter, no-required-parameter tool with no output schema, the description covers defaults, caps, ambiguous-name handling, language-default pitfall, return-row ceiling and output obligations (attribution). Nothing an agent needs to call it correctly or interpret the result 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?

With 100% schema coverage the baseline is 3, but the description adds meaning the schema does not: the `when` window is restricted to today and ≤2 h (longer belongs to get_departures), a named train type should be paired with a longer `duration_min`, and omitting `categories` is the correct default for "which trains leave". These are usage rules for parameters, not restatements.

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?

"Next trains at a German railway station: platform, delay, cancellations" gives a specific resource, the fields returned, and the scope (German rail). It then explicitly separates itself from get_departures, describe_station and check_transit_disruption, so an agent can pick it 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?

It states the triggering questions ("when a train, S-Bahn or ICE leaves a named station", delays, "heute Abend") and names the alternative for each exclusion: one bus/tram/U-Bahn line, non-railway stop, another day, over 2 h → get_departures; a line with no departure station → check_transit_disruption; whole-station info → describe_station. Explicit when-not plus named siblings is the top of this scale.

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 (which only assert readOnly=false/destructive=false/idempotent=false), the description discloses the match-resolution rule (one match stopped, several listed and none stopped), the session-scoping limit (another session's watch is never found), and that results carry an attribution line. These are the behaviors an agent cannot get 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 action and its effect, then usage, then exclusions, then fallback behavior. Dense and largely waste-free, though the kind/key enumeration in the prose partially duplicates the schema and the parenthetical example clusters lengthen 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?

For a stateful mutation tool with no output schema, the description covers purpose, trigger conditions, alternatives, ambiguous-match handling, cross-session limits, and the attribution of results. An agent has everything needed to call it correctly or choose a sibling instead.

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 baseline is 3, but the description adds a genuine decision heuristic for the alternative invocation paths — id vs. kind+key — and notes that the key is matched case- and space-insensitively against this session's open watches. It does not, however, explain anything about `uri` or `language` beyond what the schema already says.

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 (ends/stops) and resource (a watch opened by watch_situation) plus the consequence (no further notifications). It explicitly distinguishes itself from watch_situation (create), check_road_status (lookup) and viafrei://watches (listing), so an agent can route correctly without reading any sibling 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?

States when to use it with natural-language user examples ("du musst mir nichts mehr zur A8 sagen"), gives explicit negative cases (do NOT look up, list, or cancel outside this chat), and explains the no-id fallback path (kind + key in the person's words) including the ambiguous-match outcome. Nothing 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?

Beyond annotations (readOnlyHint=false, idempotentHint=false, etc.), the description discloses session-scoped lifecycle, a hard cap of ≤10 watches, the ≤24h hours limit, condition-narrowing behavior, and that the answer echoes the resolved key and applied condition. It also states external-alert inability and attribution requirements — rich context annotations alone do not carry.

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 per-kind event types are front-loaded before the usage and do-not-use clauses, and each sentence adds routing or behavioral value. It is dense and long, but for a six-kind watch with nested conditions the length is largely earned rather than padded.

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 seven params, a nested condition object, and no output schema, the description supplies the key lifecycle facts (session scope, cap, default duration, which-one-list resolution, echoed condition). Return shape is only lightly sketched ('the answer names the key it resolved to'), which is a minor gap given no output schema exists.

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 all seven parameters and the nested condition object are already documented in depth; the description's parameter notes (hours ≤24/default 3, condition narrows it) largely restate the schema. The one genuine addition is the 'a name is enough as key; no lookup first' workflow hint, but overall the schema does the heavy lifting, 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 verb and effect: opens a watch so THIS conversation is notified on change, with concrete event types (road closure, jam, late stop, weather warning, charger freeing). It clearly separates itself from the sibling lookup tools (check_*, find_*, get_*) by stating it does not look up now, so an agent can route without opening schemas.

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 names when to use (be told later, with bilingual example quotes) and when not to use (not for immediate lookup; not for e-mail/SMS/external alerts, with instruction to say so). The stop_watch alternative is implicitly the sibling, and the look-now tools are explicitly excluded, leaving little to infer.

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