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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description adds genuine behavioral context beyond that: the data is '~5 min old' and the caller must 'Show the attribution line', both of which 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?

Purpose is front-loaded in the first sentence, followed by routing rules and a data-freshness note. It is dense and long, but nearly every clause carries routing or constraint information; only the abrupt 'Show the attribution line' tail feels tacked on.

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 characterizes the payload (event kinds with delay and speed, grouped per road in listed order) and points to cursor pagination via _meta.nextCursor. The only shortfall is that the exact shape of each event is left implicit.

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 roads, kinds, limit, cursor and language in depth. The description only reinforces the roads cap ('up to 5 motorways') and does not add syntax or format meaning 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 and resource: 'Returns jams, slow traffic, closures and roadworks in force this minute on up to 5 German motorways, with delay and speed.' It goes further and names the siblings it must not be confused with (check_road_status, find_roadworks_ahead), 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?

Explicit when-to-use ('the question is about the road now: Stau, a delay, how it looks') and when-not ('Do NOT use for whether a road is open or passable', later time windows, city streets, fuel, trains), each paired with the alternative tool by name. The clock-vs-question routing rule is spelled out in full.

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 carry readOnlyHint/idempotentHint/openWorldHint/destructiveHint so safety profile is covered. The description adds operational constraints beyond annotations: one road per call, ≤14 days, ≤11 entries, and a required 'show the attribution line' instruction, which the annotations do not express.

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, then when-to-use, then exclusions, then constraints. Dense but no filler; every clause is functional. Slightly long but the length is justified by the routing and horizon heuristics.

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, so the description must convey return semantics: it does via 'closures come first, then restrictions in force, then planned works' (from the limit param) and 'live closures are always included'. What isn't covered is the shape of a single entry, but the routing, constraints, and attribution requirement make it complete enough to invoke 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%, so baseline is 3. Description adds meaning beyond the schema by stating the exclusivity rule among road/place/lat+lon and the horizon_days heuristic mapping ('this weekend' → 3, named weekday → days from today, bare question → omit). This is genuinely beyond what the schema properties say.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource: returns open/closed/restricted status for one German motorway or federal road, now and in coming days. Explicitly distinguishes from siblings (check_autobahn_traffic, find_roadworks_ahead) by naming what it is NOT for.

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 with quoted example phrasings, plus a clear 'Do NOT use for' section that routes to two named alternatives with their distinguishing conditions. Turn-by-turn routing for an agent is unusually complete.

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

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

Annotations already declare readOnly/openWorld/idempotent/non-destructive, so the bar is lower, and the description still adds real traits: a hard 50-facility cap, out-of-service-first ordering, and the fact that results carry an attribution line. It does not discuss error/ambiguity behaviour beyond the schema, so a 4 rather than 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 purpose, then usage triggers, then the explicit exclusion, then behavioral facts. It is long but every clause carries distinct information (examples, exclusion, cap, ordering, attribution) with no 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 supplies the return shape (each facility, its location, state of in service/out of service/unknown, and operator explanation) plus attribution, while annotations carry the safety profile. An agent has everything needed to call it and interpret the result.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and the parameter docs are unusually rich (station-vs-eva_no mutual exclusion, enum guidance, language default warning), so the baseline is 3. The description's only added parameter meaning is the 50-cap and out-of-service-first ordering tied to limit, which the schema also states.

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 (report working state of a German station's lifts and escalators) plus the exact returned fields: per-facility state and operator explanation. It also names the sibling it is not (get_train_departures), so an agent can separate it from departure tools 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 explicit when-to-use triggers with real multilingual example utterances ("Funktioniert der Aufzug am Kölner Hauptbahnhof?", wheelchair/pram/luggage scenarios) and an explicit when-not-to-use rule routing to get_train_departures for times, platforms and delays. 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 read-only, idempotent, non-destructive behavior, so the safety profile is covered. The description adds valuable non-annotation context: the region-vs-line data limitation, the aggregation constraint, the license with an obligation to show attribution, and the direction to set language on every call. Missing only return-shape/pagination details, which are less relevant for an aggregate tool.

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 when-to-use, then exclusions, then constraints, then attribution. Every clause earns its place; no 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?

Given five parameters, no output schema, and an open-world-free read-only operation, the description supplies the remaining decision-relevant facts: use case, exclusions, aggregation limits, window semantics, bilingual behavior, and the CC BY-SA attribution requirement. Nothing material for correct invocation 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, but the description still adds meaning beyond the schema: it clarifies that lat/lon are alternatives to region ('either region OR lat+lon, never both'), states the window cap, and stresses that language must be set on every call regardless of default. That is genuine value on top of the structured fields.

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+scope: punctuality of public transport in one German region, with enumerated metrics (share of trips >5 min late, cancelled stops, trend, sample size). It is distinguishable from siblings such as check_autobahn_traffic and check_road_status by being explicitly rail/bus network punctuality rather than road conditions.

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 ('whether buses and trains are running normally, or whether a strike or storm is disrupting local transport') and an explicit exclusion ('Do NOT use for one line, trip or station — per-line realtime is unavailable'), plus a hard constraint (region-wide aggregates only, window ≤ 120 min). An agent can route to this tool without further 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/openWorld/idempotent/non-destructive, and the description adds genuinely new behavior: it reports data staleness rather than defaulting to an all-clear, and requires surfacing the attribution line to the user. Those are operational traits an agent could not infer from annotations or 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 purpose, then use/do-not-use, then behavioral caveats and display requirement. Dense but each sentence carries signal; slightly over-long with the parenthetical hazard list, which is the only marginal fat.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only warning lookup with no output schema, the description names the returned components (Warnstufe, area, validity window, official text), the freshness caveat, and the attribution obligation — everything an agent needs to call and present the result 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% and each parameter (lat/lon vs place, language default, min_level) is documented in rich detail in the schema itself, including the place-vs-coordinates exclusivity. The description's mention of Warnstufe 1–4 loosely frames min_level but adds no new parameter guidance, 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 (returns) and resource (official DWD weather warnings) with scope: the hazard types, Warnstufe 1–4, area, validity window and unaltered official text. It explicitly distinguishes itself from siblings by declaring 'warnings only' and routing closures/jams to check_autobahn_traffic.

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 triggering situations (a trip, whether it is safe to drive somewhere, storm/snow/ice warnings) and explicit exclusions plus an alternative tool (check_autobahn_traffic for closures and jams; no plain forecast). This is as close to a complete when/when-not/alternative mapping as a definition gets.

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, yet the description adds genuinely new behavioral context: gazetteer facts are nearest-point not boundary lookups, results can differ near borders, the admin point may be a Regierungsbezirk rather than a Land, and OpenStreetMap ODbL 1.0 attribution must be shown. These are obligations and caveats the structured fields cannot 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 core definition and the exclusion before the caveats, so the most decision-relevant content comes first. It is dense and somewhat run-on in the middle clauses, 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?

No output schema exists, so the description must characterize the return, and it does so explicitly by listing the five fact types and their per-fact distances. Combined with the attribution requirement and boundary caveats, an agent has everything needed to call it and present results 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%, and the language parameter already carries a very detailed schema description, so the baseline of 3 applies. The prose adds no syntax or format guidance for lat/lon or language beyond what the schema states.

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 'Turns a coordinate into words' states a precise verb+resource, and the description enumerates what comes back (address, settlement, Kreis, administrative area, motorway junction with distances). It explicitly distinguishes itself from find_place, find_poi and find_address, so an agent can route correctly 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?

Both the trigger ('Use when you already HAVE a lat/lon') and the anti-trigger ('Do NOT use to look up a place or address BY NAME') are stated, and the three alternative siblings are named by name. This is the textbook when/when-not/alternatives pattern.

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/idempotent/non-destructive, so the bar is lower; the description adds genuinely non-obvious traits: a hard cap of 5 results, the interpretation that multiple hits mean a doubly-mapped door rather than ambiguity, and an attribution obligation (ODbL 1.0 line). It does not discuss failure modes or rate limits, but the added context is substantive.

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 and then the routing rules; every sentence carries information (trigger, exclusions, result semantics, license). It is dense but not padded, though the license sentence is a slight tail appendage.

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, and the description covers the return (coordinate plus OSM objects), the cardinality behavior, and the attribution requirement, so 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 coverage is 100%, so baseline is 3; the description still adds value by explaining that the query must carry a town or postcode to be placeable, that both field orders work, and that `language` must be set explicitly rather than left to its default. These are behavioral constraints the schema states only partially.

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 and returns its coordinate, plus what OpenStreetMap holds under it') and explicitly distinguishes itself from find_place and find_poi by input shape. An agent can select it 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 positive triggers (street AND number given, or to see what is mapped there) and explicit exclusions routed to named siblings: town/district/station name alone → find_place, company/shop/landmark → find_poi. It also states the coordinate can be passed to any other tool as lat/lon.

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 non-obvious behavior: availability is missing for most operators and must be reported as unknown, never as free; the radius and result caps are hard limits; and the caller must display the attribution line. These are real operational constraints the annotations do not convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

It is front-loaded with the purpose and return fields, then routing rules, then limits — a sensible order. It is dense and runs long, but nearly every clause (exclusions, unknown-status caveat, attribution) carries distinct information, so little 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?

With no output schema, the description still explains the return payload, the uncertainty in the availability field, and the hard caps on radius and site count. For a 9-parameter, zero-required tool, an agent has everything needed to call it correctly and interpret 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 schema already documents every parameter, including place-vs-coordinate exclusivity, connector semantics and min_power_kw guidance. The description restates the radius and result caps but adds no parameter detail beyond the schema, so the baseline of 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 gives a specific verb and resource ('Returns EV charging sites near a place or coordinate') and enumerates the returned fields (operator, connector types, max power, price per kWh, free-point counts). It explicitly distinguishes itself from the nearest siblings, find_cheapest_fuel and get_driving_rules, 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?

It states when to use the tool with concrete driver-style triggers ('Wo kann ich laden?', 'CCS 150 kW near Leipzig') and gives explicit when-NOT-to-use rules naming the correct alternatives for fuel and for E-Kennzeichen/Ladekarte questions. 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 cover read-only, idempotent, open-world safety, so the description correctly spends its budget on non-structured constraints: radius ≤ 25 km, max 10 stations, per-line price/opening-hours age, and the MTS-K attribution/display obligation. It stops short of noting rate limits or fallback behavior when no station 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?

Front-loaded with purpose, then usage, then exclusions, then limits. Dense but mostly high-value; the 'Each line names the age...' sentence is useful, though the attribution sentence is a compliance note rather than invocation guidance.

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-param, no-output-schema, read-only search tool, the description covers selection, exclusions, hard limits, and output-content expectations plus a legal display note. It never mentions result ordering guarantees beyond 'cheapest' or failure modes (no results, invalid place), but those are minor.

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 rich (place vs lat/lon mutual exclusion, language default pitfall, fuel enum meaning). The description only echoes the radius and limit caps, adding little beyond the schema. Baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (Returns), resource (cheapest stations), and scope (one fuel grade near a place or coordinate), with an enumerated return payload. It explicitly separates itself from find_fuel_station, find_charging_station, and check_autobahn_traffic.

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 the triggering condition ('when the user asks where to fill up or what fuel costs'), explicit exclusions with named alternatives, and a routing rule: brand/name/open-now/nearest-first goes to find_fuel_station. 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 readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely new behavioral context beyond that: results carry attribution and an MTS-K note and disclose the age/freshness of each price and opening-hours claim, which matters for a data-source-backed lookup. It stops short of describing pagination or result shape, but with annotations carrying safety this is strong.

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 purpose, then usage, then exclusions, then result behavior — a clean information hierarchy. Despite being three dense sentences it earns every clause, and the length is justified for a 13-parameter 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?

For a 13-parameter, zero-required read tool with no output schema, the description covers routing, filtering axes and return-value provenance (attribution, MTS-K, staleness). It gives enough for correct invocation; only the detailed result shape is left implicit, which is a minor gap given the lack 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 schema already documents all 13 parameters in depth (including the place-XOR-lat/lon rule). The description's filter/sort enumeration largely restates what the schema provides, adding only natural-language framing rather than new semantics. 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 ("Finds") and resource ("filling stations") with explicit scope ("around a place or coordinate") and summarizes the filter/sort axes. It also names the siblings it must not be confused with (find_cheapest_fuel, find_charging_station), so an agent can disambiguate 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?

Explicit when-to-use framing ("Use when the question is WHICH station") with concrete examples, plus explicit when-NOT-to-use guidance naming the correct alternative tool for each excluded case. This is the textbook routing pattern.

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 safety, so the description only needs to add operational context — and it does: radius cap of 15 km, a result cap of up to 3 items per category, and the fact that source attribution is shown. It does not describe pagination or result ordering, and the capsule output shape is only implied, which keeps it short of 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?

The lead sentence defines the tool, the second gives usage and the routing exclusions, and the closing fragment carries the hard limits and attribution note. Despite being dense with sibling names, every clause is load-bearing for routing and 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 must convey what comes back — it does: per-category items with distances, capped at 3 each, plus attribution. Combined with the radius constraint and the place-vs-coordinates rule, an agent has everything needed to call this correctly and interpret the result.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the parameter contract (lat/lon vs. place, the language override, radius range, category enum) is already fully documented in the schema. The description repeats the categories and the ≤15 km bound but adds no semantics beyond what the schema states, 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 (an at-a-glance overview of what surrounds a place or coordinate) and enumerates the exact categories covered: fuel, charging, parking, railway station, motorway junction. It explicitly distinguishes itself from sibling tools such as find_cheapest_fuel, find_parking and describe_location, so an agent can select 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 the trigger phrasing ('what is around me', 'what is near <place>') and then an explicit do-NOT list mapping each out-of-scope case to the correct sibling (find_cheapest_fuel, find_charging_station, find_parking, find_place/find_poi/find_address, describe_location). The boundary between this broad tool and the category-specific tools 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 already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description still adds real behavioral context: the 25 km / 10-site caps, up to three separate source lists, mandatory attribution, and the crucial caveat that a missing "free now" means no published count rather than a full lot. That caveat and the result-shape notes go beyond the annotations, so it lands above baseline but does not fully describe pagination or result ordering beyond 'nearest first'.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core capability and exclusions, and nearly every clause carries decision-relevant information (exclusions, radius cap, source split, attribution). It is dense and long for a single paragraph, but not 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?

With no output schema, the description correctly carries the return-shape burden: total spaces, published free spaces plus the reading's age, up to three attributed source lists, and the interpretation rule for absent free-space data. For a zero-required-parameter, nine-param read tool this is complete.

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 descriptions are themselves unusually rich (enum meanings, mutually exclusive lat/lon vs place vs road, radius ignored for road). The tool description largely restates that guidance at a higher level rather than adding new per-parameter syntax, so with full schema coverage the baseline of 3 is the right anchor.

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 and the full scope: parking near a place, coordinate, or along one motorway, covering rest areas with lorry spaces, car parks and park-and-ride sites, with total and free-space counts. It explicitly distinguishes itself from siblings find_cheapest_fuel and find_charging_station, 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 concrete when-to-use triggers ("where to park or leave the car for the train") with sample German queries, plus explicit when-NOT-to-use alternatives by name (fuel, EV charging). The road-vs-place-vs-coordinate selection rule is also spelled out, including the both-named tiebreak.

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

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

With annotations already covering read-only, idempotent, and non-destructive behavior, the description adds substantial operational context: the 10-result cap, the 200 km radius limit, the attribution line that must be shown to the user, and how `near` separates same-named places. These are behavioral traits beyond what the annotations state and are important for correct use.

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 result shape, then moves through usage, exclusions, and limits without filler. Each sentence earns its place by adding a distinct rule or distinction.

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 lookup tool with no output schema, the description covers what is returned, how many results, geographic limits, the required attribution, and the main sibling alternative. The annotations already cover safety, so no important calling context 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 the schema already documents each parameter's meaning, including `near`, `language`, and the result/radius limits. The description reinforces the disambiguation role of `near` and the language default rule but does not add meaning beyond the schema, so the baseline of 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: 'looks up a place name and returns every place that matches', and it enumerates the returned fields (kind, AGS/RS key, population, English name, coordinate). It explicitly distinguishes itself from find_poi, so an agent can separate it from the many sibling lookup tools 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?

It gives explicit when-to-use triggers: where somewhere is, when a coordinate is needed for another tool, and recovering from an ambiguity report. It also gives an explicit when-not-to-use rule ('Do NOT use to find a company, shop or landmark: call find_poi') and a disambiguation pattern using `near`.

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, non-destructive, closed-world), so the bar is lower; the description still adds real behavior beyond them: a hard result cap (max 10), radius ceiling (<= 50 km), the ODbL attribution obligation, and the workflow hint that the returned coordinate chains into any other tool as lat/lon.

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, then constraints and licensing. Dense and mostly waste-free, but the result/radius caps restate schema constraints that are already explicit, costing a little 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 9-parameter geocoding tool with no output schema, the description covers purpose, alternatives, return contents, limits, and licensing, 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 parameters are already fully documented, including the nuanced language-parameter guidance. The description largely repeats schema facts ("At most 10 results, radius <= 50 km") and only mildly reinforces the 'in' preference, 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 (finds), resource (named business or landmark), examples (company, shop, clinic, hotel) and return shape (address, category, coordinate). It explicitly differentiates from find_place and the fuel/charging/parking 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 explicit when-to-use ("the person names a THING rather than a town"), when-not-to-use ("Do NOT use for a town, district or station... nor for fuel, charging or parking"), and names the alternatives. The performance hint ("Give 'in' when you can: far faster than searching nationwide") further guides correct invocation.

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, closed-world behavior, so the description's burden is lighter. The description still adds operational facts: a 92-day window cap, a 20-site cap, the 'show the attribution line' output expectation, and how the readable text truncates beyond 10 sites. No contradictions with 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?

Front-loaded with purpose, then usage rules, then constraints, then the attribution reminder. Dense but every clause carries a routing or parameter rule. Slightly overstuffed with nested parentheses and quoted examples, which costs a point on tightness.

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 5-parameter read-only lookup with no output schema, the description covers windows, caps, language behavior, attribution, and alternatives to sibling tools. An agent has everything needed to call it correctly and to route the excluded cases elsewhere.

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 nonetheless reinforces parameter behavior in prose — one road per call, resolve relative dates to real dates, the default 7-day window, and that 'language' must be set on every call rather than left to its default. That is meaningful semantic reinforcement, though it largely mirrors the schema text.

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 ('roadworks PLANNED on one German motorway inside a date window') plus the fields returned (section, direction, restrictions, start/end). It explicitly contrasts with sibling tools check_autobahn_traffic and check_road_status, so an agent can distinguish it without inspecting 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?

Gives explicit triggers (date or window named, the word 'geplant', 'how long'), explicit exclusions (multiple motorways, current situation, no date/geplant), and names the alternative for each excluded case. This is exactly the when/when-not/alternatives guidance the rubric rewards.

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 real behavioral context beyond them: planned times only (not live), no destination filtering, a 48 h window, a 15-row cap, and that results carry an attribution line. It does not state auth or rate-limit behavior, but for a read-only public-data lookup that is a minor gap.

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 mode list, then usage rules, then behavioral constraints — each sentence carries distinct information. It is dense and mixes German example phrases into an English description, which costs a little readability but not correctness.

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-output-schema lookup tool, the description covers purpose, routing to alternatives, result contents (line, destination, platform, attribution), result limits, and the planned-vs-live distinction. Nothing an agent needs to call 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% and the parameter descriptions are already unusually rich, so the baseline is 3. The description still adds value by stating the 48 h window, the 15-per-call cap, and the 'no destination filter — read the board' constraint, which shapes how the agent sets when/duration_min.

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 public-transport stop') and enumerates the covered modes, so the scope is unambiguous. It explicitly separates itself from the closest sibling, get_train_departures, which an agent could otherwise confuse it with.

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 (any bus/tram/U-Bahn/ferry, another day, or a clock time over 2 h away), an explicit when-NOT-to-use rule routing railway station trains to get_train_departures, and a further alternative (check_transit_disruption) for punctuality questions. 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 readOnlyHint=true and idempotentHint=true, so the agent knows it is a safe read. The description adds valuable behavioral context beyond that: results are sourced and dated and the attribution must be shown, the tool is not legal advice, and the city parameter behaves differently per topic (narrows lez, adds a per-city caveat for ev, while other topics stay nationwide). No contradictions with 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?

The description is long but every sentence earns its place. It front-loads the purpose and topic list, then gives usage rules, exclusions, city behavior, language guidance, and sourcing. It is structured and scannable, though a bit dense. It could be slightly tighter, but it is far from bloated given the tool's complexity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 9 topics, no output schema, and sparse annotations, the description covers everything an agent needs: what it returns, when to use it, when not to, how the city parameter modifies results, the mandatory language setting, and the need to show attribution and note it is not legal advice. Nothing essential is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description adds extra meaning on top of the schema: for 'city' it explains that it narrows only the 'lez' topic and adds a caveat for 'ev' while other topics are nationwide; for 'language' it stresses that the default is only a fallback and must be set to the user's language, and it explains translation behavior (German terms kept in parentheses). These details go beyond the schema's property descriptions, so a 4 is warranted.

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 precise statement: returns German road rules a visitor needs, then enumerates the exact topics (low-emission zones, speed limits, winter tyres, etc.). It names the resource (German road rules) and clearly differentiates from siblings by explicitly excluding live traffic and charger lookups, so an agent can tell this apart without reading other 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?

It gives explicit use cases ('Use when someone drives through Germany or asks whether they may enter a city') and explicit non-use cases with named alternatives ('Do NOT use for live traffic or closures: check_autobahn_traffic; to FIND a charger: find_charging_station'). It also explains the optional city parameter narrows results and that the language parameter must be set to match the user's language, with a fallback rule. This is fully actionable routing guidance.

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

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

Annotations declare readOnlyHint=true and idempotentHint=true, so the description carries a lower burden; it adds useful operational constraints (max 15 departures, 120-minute window, no destination filter) that go beyond the annotations. It does not describe pagination or error behavior, but for a read-only board tool it covers the key behavioral limits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the purpose, then interleaves usage boundaries and constraints compactly. The parenthetical asides (S-Bahn/ICE, 'heute Abend', the S1 example) are dense but each earns its place by disambiguating intent.

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 annotations covering safety and the 100%-covered schema handling parameters, the description adds the routing logic needed to avoid the three sibling tools and states the result window and cap. It lacks return-shape detail, but no output schema exists and the payload fields are already listed, so it is largely complete.

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 fully documents all six parameters, including the language-priority guidance and the station vs. eva_no mutual exclusivity. The description repeats the max-15 and 120-minute limits rather than adding new parameter meaning, so the 3 baseline 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 (get next departures from a German railway station) and enumerates the payload (platform, delay, cancellations). It actively distinguishes itself from the sibling check_transit_disruption and get_departures, telling the agent exactly which questions belong here.

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 examples ('when a train, S-Bahn or ICE leaves a named station', 'that departure is late'), when-not-to-use cases ('buses, trams, a non-railway stop, another day or a time over 2 h away'), and names the alternative tool (check_transit_disruption) for the single-line-punctuality case with the reasoning for the split.

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=false, destructiveHint=false, openWorldHint=false and idempotentHint=false. The description adds context annotations cannot express: session-scoped ownership, cross-session watches being 'not found, never stopped', and that results carry an attribution line. It does not state behavior on re-stopping an already-stopped watch, but overall disclosure is strong.

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 effect, then usage triggers, then the id-resolution procedure, then exclusions — a sensible order. It is dense and includes bilingual example phrasing, but every sentence carries routing or behavioral information rather than filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a session-scoped mutation tool with no output schema, the definition covers effect, triggers, id resolution, ownership semantics, and error behavior for foreign watches. Nothing an agent needs in order to call 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, but the description genuinely adds value by telling the agent how to derive the id when the person names a subject instead of an id ('take the id from viafrei://watches'). It leaves the uri vs watch_id choice to the schema, which already documents 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?

States a specific verb and resource ('Ends a watch this conversation opened with watch_situation') and its immediate consequence (no further change notifications). It explicitly distinguishes itself from check_road_status, watch_situation, and viafrei://watches, so an agent can route correctly without opening another 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 concrete triggers ('du musst mir nichts mehr zur A8 sagen', 'stop watching that charger'), names the alternatives for adjacent intents (check_road_status for lookups, viafrei://watches for listing), and states a hard exclusion ('cancel anything outside this chat — there is nothing subscribed elsewhere').

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 state the generic mutation profile (readOnlyHint=false, idempotentHint=false, destructiveHint=false, openWorldHint=false). The description adds the operationally important traits: session-scoped, a hard cap of 10 watches, 24 h maximum lifetime, inability to send external alerts, and that results carry an attribution line. None of that is derivable from the annotations or 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 purpose, then usage, then constraints, and every clause carries information — the example utterances and the 'say so' instruction are functional, not filler. It is dense and slightly long, but nothing reads as 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?

There is no output schema, so the description must carry the interaction contract, and it does: lifetime, watch cap, session scoping, refusal behaviour for unmatched keys, and attribution on results. For a non-idempotent subscription tool with a nested condition object, an agent has everything needed 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% and the schema already documents kind/key mapping, hours-vs-until exclusivity, the language override and every condition sub-key, so the description is not the primary source of parameter meaning. The description adds nothing about parameters beyond what the schema states (its '24 h each' note is a limit, not param semantics), so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Names a concrete verb and resource ('opens a watch') and immediately illustrates what it does with four concrete change types (road reopening, stop running late, weather warning, charge point freeing). It also explicitly contrasts itself with the read siblings check_road_status, check_autobahn_traffic and find_charging_station, so an agent can separate it from them without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives both when-to-use (person asks to be told later, with bilingual example utterances) and two explicit when-not-to-use cases: looking something up now (with the three alternative tools named) and any out-of-chat notification channel (email/SMS, with the instruction to say so). This is the full when/when-not/alternatives triad.

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