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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds that the data is about 5 minutes old (a freshness/staleness caveat) and requires showing an attribution line, which are behavioral obligations beyond the annotations. It does not describe pagination behavior or error cases, but the freshness and attribution details are meaningful additions.

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 dense and front-loads the core purpose, but it is very long with nested clauses and multiple exclusion paths crammed into one paragraph. Every sentence does carry routing information, but the structure could be tighter. It earns its space but is not concise.

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 5 parameters, no output schema, and a rich input schema with full coverage, the description is complete. It covers what the tool returns, its freshness, the attribution requirement, and acts as a router to all relevant sibling tools. 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 coverage is already 100%, so the schema documents each parameter. The description goes further by explaining semantic intent: 'roads' should list every motorway on a route for one call, 'kinds' should be omitted when the question is about how the road IS, and 'language' must be set on every call to avoid a wrong-language answer. These clarify usage in ways the schema's own descriptions reinforce but the tool-level text makes actionable.

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 (reports jams, slow traffic, closures, roadworks), a resource (up to 5 motorways), a temporal scope (in force this minute), and the data returned (delay/speed). It explicitly distinguishes itself from siblings like check_road_status and find_roadworks_ahead, so an agent can differentiate 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?

The description gives explicit when-to-use criteria (named motorway, now, Stau, list of closures) and when-not-to-use with named alternatives for each excluded case: yes/no open/closed goes to check_road_status, dated/geplant roadworks to find_roadworks_ahead, town Stau to check_road_status, fuel to find_cheapest_fuel, trains to get_train_departures. This is about as complete as usage guidance 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, so safety is covered. The description adds real behavioral context the annotations don't: the ≤14-day and ≤11-entry caps, ordering semantics (closures first, then restrictions, then planned works; nearest-first by place), the requirement to show attribution, and the frank statement that city street data is not held.

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 routing are front-loaded well, but the block is dense — long parenthetical lists, mixed German/English examples, and multiple constraints packed into single sentences. It is information-rich but not cleanly segmented, so scanability suffers.

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, zero-required, no-output-schema tool with full schema descriptions and safety annotations, the description covers routing, scope limits, ordering, language handling, and data gaps. 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 coverage is 100%, so the baseline is 3, but the description adds cross-parameter reasoning the schema states only piecemeal: pass Land/town with L/S numbers because they repeat, road is the only path to planned-works data, and one of road/place/lat+lon. It reinforces but does not merely repeat 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?

The description states a specific verb and resource — road open/closed/restricted status across motorways, B/L/S roads, by place, jams, cameras — and explicitly distinguishes itself from check_autobahn_traffic, find_roadworks_ahead, and city-street coverage. An agent can route correctly 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 with quoted German examples ('ist die A8 in diesem Moment gesperrt', 'Stau in Köln?') and explicit when-not-to-use routing to three named siblings with the condition that selects each. This is a model negative-and-positive routing block.

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 safety is covered and the bar is lower. The description still adds real behavioral context beyond them: a 50-facility cap, out-of-service equipment listed first, the guarantee that summary counts cover all facilities so a short list never hides a broken lift, and an attribution line on results. Ambiguous station names producing a disambiguation list ('the result lists them and asks which; do not guess') is a genuinely useful behavior disclosure, though nothing is said about failure modes when a station has no facility data.

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 purpose, then usage triggers, then the exclusion. It is long, but each sentence does work — the bilingual examples exist to route non-English queries and the exclusion prevents misrouting to departures. The clause about attribution lines is slightly marginal, keeping it off a 5.

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: it lists the per-facility fields (location, state, operator explanation), the ordering rule, the cap, and the attribution line. Combined with annotations covering the safety profile and a 100%-covered schema, 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 parameter descriptions are unusually thorough, so the baseline is 3. The description only echoes the limit semantics ('At most 50 facilities, out-of-service ones first') already spelled out in the limit field; it adds no new meaning for eva_no, station, facility or language beyond what the schema already documents.

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 verb and resource ('Report whether the lifts and escalators ... are working now') and enumerates exactly what is returned: each facility, its location, its state (in service / out of service / unknown) and the operator's explanation. It also distinguishes itself from the nearest sibling by name ('Do NOT use for train times, platforms or delays — call get_train_departures'), so an agent can separate it from get_departures 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 when-to-use triggers are given with multilingual user phrasings ('Funktioniert der Aufzug am Kölner Hauptbahnhof?', 'Rolltreppe am Neumarkt kaputt?') plus the intent vocabulary that should route here: wheelchair, pram, heavy luggage, step-free access. An explicit exclusion and named alternative (get_train_departures) covers the main confusion case, 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 already declare readOnly/idempotent/non-destructive, but the description adds traits they cannot carry: no per-line granularity, a hard 120-minute window cap, region-level data filing (a town is reported as its Kreis and the answer says so), and mandatory licence attribution (CC BY-SA DELFI / CC BY 4.0 VBB). These are real operational constraints an agent must respect.

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 tightly packed, with the when/when-not routing and the licence clause each doing work. The parenthetical German query examples add length but also real disambiguation value, so only minor trimming is possible.

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 four reported metrics and the alert types (diversions, closed stops). Zero required parameters plus documented lat/lon-vs-region exclusivity and the language default warning cover 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%, so the baseline is 3; the description largely restates the window limit ("Window ≤ 120 min") already documented in the schema. Its genuinely additive notes — no per-line figures and the lat/lon vs region exclusivity — are already covered by the parameter descriptions, so it does not meaningfully extend parameter semantics.

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

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

States a specific resource (punctuality of public transport in one German region) and enumerates exactly what is reported: share of trips >5 min late, cancelled stops, trend, and service alerts in force. It explicitly separates itself from get_train_departures and rules out per-line figures, so an agent can distinguish it from siblings without opening the 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 an explicit positive trigger ("Use when asked whether buses and trains run normally, or a strike, storm or works disrupt them") and an explicit negative one ("Do NOT use for a station's departures or a line from a named DEPARTURE station... get_train_departures"). The German example even disambiguates a destination phrase ("nach …") from a departure station, which 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 the safe read-only/idempotent/open-world profile, so the description focuses on what the annotations can't say: the data is official DWD text returned unaltered, the road forecast applies to the nearest road-weather stations, and the caller must display an attribution line. Rich added context, though it stops short of noting any rate limits or failure modes.

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?

Heavily front-loaded: purpose, then hazard/level detail, then the road-forecast extension, then when-not, then the attribution directive. No filler sentences; each clause carries distinct information despite the density.

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 contract and does so: Warnstufe 1–4, area, validity, official unaltered text, and the road-weather forecast fields. For a read-only lookup with 100% schema coverage and full annotations, 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 schema itself documents each parameter well, so the baseline is 3. The description earns above baseline by explaining a behavioral consequence of the place-vs-coordinate choice (the road-surface forecast is added at a town or coordinate), which the schema does not state.

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 precise verb+resource (official DWD weather warnings in force for a place) and enumerates the hazard types and Warnstufe 1–4, plus the extra road-surface forecast at town/coordinate. It also names the sibling it is NOT (check_autobahn_traffic for jams), so an agent can separate it from adjacent 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 positive triggers (trip weather, safe driving, storm/snow warnings, icy roads/Glätte) and explicit exclusions (general forecast not offered; jams go to check_autobahn_traffic). It even adds a caller obligation, 'Show the attribution line', leaving little 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 cover the safety profile (readOnly, idempotent, non-destructive) but the description adds real behavioral context the agent couldn't infer: boundary behaviour near national borders is disclosed, and the licensing/attribution requirement (OSM ODbL 1.0, must show attribution line) is a genuine obligation. It also flags that Gemeinde/Kreis/Land come from the municipality's official key rather than nearest Kreis point, a subtle accuracy caveat.

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 routing, then behavioral caveats in a compact block. Slightly dense with the licensing sentence appended, but every sentence earns its place and none is redundant.

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

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

For a read-only, no-output-schema tool, it covers purpose, alternatives, output contents, boundary caveat, and attribution obligation. Nothing an agent needs to call and correctly present 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 coverage is 100% with an enum on language, so baseline would be 3; the description adds meaning beyond the schema by warning that omitting language defaults to German and yields a wrong answer for English questions, and clarifying that place names/road numbers are never translated. This is actionable semantic guidance beyond the raw enum.

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 ('turns a coordinate into words') and enumerates the exact outputs (nearest address, settlement, motorway junction with distances, Gemeinde/Kreis/Land). It explicitly differentiates from siblings find_place, find_poi, find_address by stating 'this only goes coordinate to words'.

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 ('when you already HAVE a lat/lon and need to say where that is') and when-not ('Do NOT use to look up a place or address BY NAME'), naming the three alternative lookup tools. 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 the read-only/idempotent/non-destructive profile, but the description adds substantial behavioral detail beyond them: a 5-point cap, duplicate-door folding, distance disclosure when points are far apart, ambiguity handling ('several towns are a question'), and the ODbL attribution obligation. That is exactly the kind of result-shaping and licensing context annotations 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-loaded with purpose and trigger, and every sentence carries information (limits, dedup, attribution). It is quite dense with em-dash clauses and parentheticals, which slightly taxes readability, but there is 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?

No output schema exists, yet the description explains what is returned (a coordinate reusable as lat/lon, plus the named OSM objects or an explicit none), and annotations cover the safety profile. Nothing an agent needs to call or interpret it is missing.

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

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

Schema description coverage is 100%, so the schema already documents query, limit, and language in detail, including the language default trap. The description reinforces the street+number requirement for query but adds no format or syntax detail 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 ('looks up a street address') and enumerates what it returns: the coordinate plus named OSM objects at that point. It explicitly distinguishes itself from find_place and find_poi by naming them, 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?

Gives an explicit positive trigger (a STREET AND NUMBER, with a worked example) and explicit exclusions: not for a town/district/station name alone (find_place) or a company/shop/landmark by name (find_poi). It also states the input precondition (needs both street and number), 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 already cover the safety profile (readOnly, idempotent, non-destructive), and the description goes beyond them with data-quality behaviour: availability is missing for most operators, so a missing value is 'unknown, never free' — a real trap for an agent. It also mandates showing the attribution line.

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 constraints — a sensible order with no filler sentences. It is dense and a couple of clauses (radius ≤ 25 km, ≤ 10 sites) duplicate the schema, but nothing 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 9-parameter tool with no output schema, the description compensates by naming the returned fields and the fallback behaviour when live status is absent. An agent has everything needed to select the tool, pick the right parameter mode (place vs lat+lon), and interpret gaps in the response.

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

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

Schema description coverage is 100%, so the schema already documents every parameter including the connector, min_power_kw, only_available, and radius semantics. The description only restates the radius/site caps and the unknown-availability caveat, adding little beyond what is already in 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 and resource ('Returns EV charging sites near a place or coordinate') and enumerates the returned fields (operator, connector types, max power, price per kWh, live free-point counts). It is immediately distinguishable from siblings like find_cheapest_fuel or find_hydrogen_station.

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 conditions ('Use when an EV driver asks where to charge') with sample phrasings, and explicit exclusions that route to alternatives: petrol/diesel → find_cheapest_fuel, E-Kennzeichen/Ladekarte → get_driving_rules. Operational caps (radius ≤ 25 km, ≤ 10 sites) are stated up front.

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/openWorld/non-destructive, and the description adds context beyond them: each returned line discloses the age of its price and opening-hours claim, the provider's terms cap radius and result count, and the attribution line and MTS-K note are mandatory outputs. Nothing here contradicts the safety 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 the core return description, then when-to-use, when-not, parameter routing, and output/legal constraints in that order. Despite covering a 7-parameter tool with no output schema, every clause carries distinct information and there is 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 compensates by enumerating the returned fields, the price-age and hours-age disclosures, and the required attribution/MTS-K output. Combined with the schema's 100% parameter coverage and the safety annotations, an agent has everything needed to call and interpret this 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 description coverage is 100% and the schema text already explains lat/lon vs place, the fuel enum intent, language defaulting, and the radius/limit caps. The description mostly restates the radius and limit bounds rather than adding new parameter meaning, so the baseline 3 applies.

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

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

States a specific verb+resource with a clear scope: cheapest stations for one fuel grade near a place/coordinate, plus exactly what each result carries (price per litre, brand, address, distance, open state). It explicitly distinguishes itself from find_fuel_station (brand, name, open-now, nearest-first) and from find_charging_station and check_autobahn_traffic, so an agent can route correctly 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 when-to-use ("where to fill up or what fuel costs"), explicit when-not (electric charging, price history, traffic) with the alternative tool named for each, and a routing rule to find_fuel_station for brand/name/open-now/named-time/nearest-first. Constraint envelopes (radius <= 25 km, at most 10 stations) are stated up front.

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 data provenance and freshness behavior: every result carries attribution and the MTS-K note plus the age of each price and opening-hours claim. It also clarifies that unknown hours are never treated as open, which is a real behavioral trait not present in 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?

Three sentences, capability first, exclusions second, output caveat last — well front-loaded with no filler. It is dense (long em-dash clause) but each clause carries routing or behavioral information, so nothing 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 13 optional parameters and no output schema, the description still tells the agent what determines the answer (filters + sort) and what comes back (attribution, MTS-K note, staleness). Combined with the fully documented schema, 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 coverage is 100% and the schema descriptions already carry the cross-parameter rules (fuel required for sort=price, place OR lat+lon, open_at vs open_now). The description only summarizes the filter set without adding syntax or format meaning beyond it, 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 concrete verb+resource ("Finds filling stations") and immediately narrows scope: around a place or coordinate, with the exact filter axes (grade, brand, name, open now, open at a time, 24 h) and sort orders. It explicitly names the siblings it is not (find_cheapest_fuel, find_charging_station), so an agent can route 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 a positive selection rule ("Use when the question is WHICH station") with three concrete examples, plus two explicit exclusions routing to find_cheapest_fuel and find_charging_station. When-to-use, when-not, and the alternatives are all present.

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, so the safety profile is covered. The description adds genuinely non-redundant behavior: hard caps (radius ≤ 150 km, ≤ 10 stations), the absence of live availability or pricing, that the nearest station is named even when out of radius, and that an attribution line is shown. It does not discuss error behavior or what happens on an unresolvable place, 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?

Three sentences, front-loaded with what is returned, then the trigger, then the exclusions and caps. Every clause carries information; it is dense but not padded, though the multilingual example list and operator-field enumeration make it a little long for the core signal.

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 describe the return payload — and it does, naming operator, address, pump pressures (700 bar car / 350 bar truck-bus), opening hours, record age and the attribution line. Combined with the caps and the no-live-data caveat, an agent has everything needed to call and interpret this 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 description coverage is 100% and the schema already spells out coordinate-vs-place exclusivity, enum meanings, ranges and defaults thoroughly, so the baseline is 3. The description reiterates the radius and count caps but adds no syntax or format meaning beyond what the schema supplies.

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

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

Specific verb+resource ('Returns hydrogen (H2) filling stations near a place or coordinate'), with scope stated as nearest-first and the returned fields enumerated. It explicitly names the siblings it is not (find_fuel_station for petrol/diesel/LPG, find_charging_station for EV), 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 trigger ('where to refuel a fuel-cell car, lorry or bus') with multilingual query phrasings, plus explicit when-not-to-use clauses routing to two named alternatives. 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 safety (readOnly, idempotent, non-destructive), so the description's added value is its operational limits: radius capped at 15 km, up to 3 results per category, and per-source attribution being surfaced. It doesn't discuss failure modes or behavior when a place doesn't resolve, but the disclosed caps go beyond 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?

Front-loaded with purpose, then use, then do-not-use routing, then constraints — a logical order with no filler. It is dense and long, but given six parameters and twelve sibling tools, nearly every clause earns its place.

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

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

With no output schema and zero required parameters, the description covers what an agent needs: what comes back (per-category items with distances and attribution), the radius cap, and the latitude/longitude-vs-place choice. 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 description coverage is 100% and the schema text is very rich (WGS 84 ranges, place free-text formats, language default warning), so the schema carries the burden. The description adds one genuinely new detail — the up-to-3-per-category return cap — and restates the radius bound, hence the baseline 3.

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 resource scope (fuel, charging, parking, railway station, motorway junction) and its distinguishing trait — a broad radius-based overview with distances per category. It explicitly contrasts itself with one-category-in-depth tools like find_cheapest_fuel and find_parking, so an agent can separate it from all siblings 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 a direct trigger ("what is around me", "what is near <place>") and then an explicit do-not-use list mapping each excluded intent to the right sibling (find_cheapest_fuel, find_charging_station, find_parking, find_place/find_poi/find_address, describe_location). Nothing about routing 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 the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description adds substantial non-obvious behavior: radius cap of 25 km, max 10 sites per list, up to three separate source lists (ODbL vs CC BY-SA), attribution display requirement, and the critical warning that an absent 'free now' means no published count rather than a full lot.

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 before constraints, and every sentence carries information (limits, exclusions, pricing gap, attribution). It is dense and slightly long, with a few parenthetical examples that could be trimmed, 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?

There is no output schema, so the description must carry return-shape and edge-case burden, and it does: it describes what fields come back (spaces, free spaces, reading age), how many results, the multi-source split, the no-price gap, and the empty-list widening cue. Nothing an agent needs to answer 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 adds interpretation the schema does not: "No 'free now' means no published count, not full", the ≤25 km / ≤10-per-list limits, and the note that sources split into separate lists. It does not add much on lat/lon/place/road beyond the schema, but the occupancy-semantics clarification is genuinely value-adding.

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 sentence names a specific verb-and-resource combination (parking near a place/coordinate/motorway) and enumerates exactly what is returned: lorry parks, car parks, P+R sites, total spaces and published free spaces with reading age. It is instantly separable from find_cheapest_fuel and find_charging_station, which are named directly.

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 triggers are given ('where to park or leave the car for the train') with three concrete example queries, plus explicit when-NOT-to-use routing to two named siblings for fuel and EV charging. It also states the no-price case is a no-call case, which prevents a wrong 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 declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds real behavioral context beyond that: a cap of 10 results, a 200 km radius ceiling, and a mandatory attribution line that must be shown to the user. It omits anything about ranking/ordering details beyond 'best match first', which is minor.

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 triggers, then constraint, with the key routing rule stated early. Slightly long and mildly redundant (the 'which Neustadt is which' example echoes the schema), but every sentence carries actionable content.

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

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

With no output schema, the description compensates by listing the returned fields and the attribution requirement. Combined with annotations and 100% schema coverage across 8 params, an agent has everything needed to call this correctly and route to it appropriately.

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 rich per-parameter docs (near, radius_km, language, kind) already carry the parameter semantics. The description adds only a light pointer ("Pass `near` to rank and separate same-named places"), which the schema itself states more fully. 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 (looks up) and resource (a place name), enumerates the returned fields (kind, AGS/RS key, population, English name, coordinate), and explicitly distinguishes itself from the sibling find_poi. An agent can identify it and separate it from find_address, find_poi and describe_location 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 three concrete when-to-use triggers (where somewhere is, need a coordinate for another tool, recovering from an ambiguity error) and an explicit exclusion ("Do NOT use to find a company, shop or landmark: call find_poi"). The alternative tool is named, so 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 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 already establish the safe read-only, idempotent, non-open-world profile, so the bar is lower. The description still adds real behavioral context beyond them: the 92-day window cap, the 20-site ceiling, the one-road-per-call restriction, the coverage boundaries (B/L roads outside the listed Länder and Kreisstraßen are not held; city roadworks only exist for Hamburg, within 3 km), and the standing attribution requirement.

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 and dense: purpose first, then triggers, then exclusions, then constraints. It is long and parenthetical-heavy (German sample queries, mixed English/German phrasing), but nearly every clause is actionable routing or constraint 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?

With no output schema, the description supplies the return shape (section, restriction, dates), the text-vs-structured split (the readable text prints the first 10 and reports the total count), the coverage limits, and the size bounds. An agent has everything needed to decide and call 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 parameter docs are unusually rich (date resolution rules, the 92-day cap, the road/place mutual exclusion, the language default warning), so the schema carries the load. The description's contribution is mostly restating the caps ("≤ 92 days, max 20 sites", "ONE road/place per call"), which earns the baseline 3 rather than more.

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 sentence names a specific verb ("Returns"), the exact resource (PLANNED roadworks), the coverage universe (one motorway, one B/L/S road in NI/SN/TH/BW, or Hamburg streets by place) and the return fields (section, restriction, dates). An agent can distinguish it from find_poi or check_autobahn_traffic 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 positive triggers ("Use when a date or window is named, it says geplant, or how long a site lasts") and negative ones (Do NOT use when more than one motorway is named, for the situation this minute, or for Baustellen with neither date nor geplant) and routes each exclusion to a named sibling: check_autobahn_traffic and check_road_status. This is textbook when/when-not/alternative 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, so the safety profile is covered; the description adds genuine scope context instead — data age is returned, free-floating bikes are summarised rather than listed, e-scooters are out of scope, and per-source attribution is shown. It does not state refresh cadence or failure behavior, so it falls 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?

Front-loaded with the core purpose, then usage triggers, then exclusions and limits — a sensible priority order with no filler. It is on the long side (multiple parenthetical examples and a trigger-phrase list), which slightly exceeds what an agent strictly needs, but each clause carries information.

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

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

With no output schema, the description usefully sketches the return shape — stations with distance and data age, summarised free-floating bikes, per-source attribution. Combined with explicit coverage limits and exclusions, an agent has enough to call correctly, though it omits what happens when no bikes are found in range.

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 strong (place vs lat/lon exclusivity, language defaulting caveat, only_available semantics). The description adds essentially nothing per-parameter beyond restating the radius and station caps already in 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 rentable shared bikes near a place or coordinate') and immediately scopes it: bike-sharing stations with bikes/free docks plus free-floating bikes. Names the covered providers (nextbike incl. KVB Rad, MyRadl, VAG_Rad; Donkey Republic), so an agent can distinguish it from every sibling 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?

Explicit when-to-use with trigger phrases ('Leihrad', 'Fahrradverleih', 'nächstes nextbike', 'bike share near me') and explicit when-not-to-use, naming the alternatives (find_parking, find_nearby). It also states hard limits (radius ≤ 5 km, ≤ 20 stations) and an exclusion (e-scooters not covered), 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 cover the safety profile (readOnly, idempotent, non-destructive), and the description adds substantial behavior beyond them: results carry a live delay/cancellation per row, coverage holds ≥48 h ahead and ≤3 days, 15 rows per call, an attribution line must be shown, and out-of-range requests should be declined rather than attempted.

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 constraints — a sensible order. It is dense and peppered with parenthetical German examples and quoted fragments that add length, but each clause carries routing or constraint information. Slightly more cramped than ideal.

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 return contract — and it does: per-row live delay/cancellation, a count of further departures in the window, and the attribution line to display. Combined with the window limits and candidate-list fallback for ambiguous stop names, an agent has everything needed to call 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 coverage is already 100%, so this is largely reinforcement, but the description adds real operational meaning: 'set language on every call' with the failure mode of leaving it defaulted, the advice to move `when` rather than widen `duration_min`, and how bus/tram/rail/ferry map to user phrasing ('nur Busse'). It tops up documented params rather than re-deriving them.

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 covered modes (bus, tram, U-Bahn, S-Bahn, train, ferry), so the agent immediately knows the scope. It also names the sibling it is NOT (get_train_departures), making the boundary unambiguous 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?

Explicit when-to-use triggers ("welche Bahnen" at an Hbf, another day, times over 2 h away), an explicit exclusion with the alternative named (railway station now/today → get_train_departures), a pointer to check_transit_disruption for punctuality, and a hard rule for A-to-B journeys ("say so, no call"). This is close to a routing decision table.

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 readOnlyHint/idempotentHint already covering the safety profile, the description adds real value: it warns the output is sourced and dated and that attribution must be shown, states it is not legal advice, and flags the language default trap that silently produces a German answer for an English question. It stops short of describing the response structure, 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?

The usage and exclusion guidance is front-loaded and every sentence carries routing or behavioral weight. The long topic enumeration overlaps substantially with the topic enum in the schema, which is redundant bulk, but it is not wasted prose.

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

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

For a zero-required-param, read-only lookup with no output schema, the description covers scope, triggers, exclusions, attribution and the language pitfall. Only the returned shape/form is left unaddressed, which is a minor gap given no output schema exists to describe 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 description coverage is 100%, so the schema already explains city scoping, the topic enum values and the language default in detail. The description restates the city narrowing but adds no syntax or behavior the schema lacks; 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+resource (returns German road rules) and enumerates the exact subject matter covered, from Umweltzone and Feinstaubplakette to E-Kennzeichen. An agent can distinguish it from traffic, fuel, parking and charger siblings 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 ("when someone drives through Germany or asks whether they may enter a city") and explicit exclusions naming the correct alternatives: check_autobahn_traffic for live traffic/closures and find_charging_station for charger lookups. 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/openWorld/non-destructive, but the description adds real behavioral context beyond them: hard caps (≤15 rows, ≤120 min, 'over 2 h is refused'), the ambiguity-handling behavior (a bare 'Hauptbahnhof' returns a list and asks, so don't guess), the language-default failure mode, and the requirement to show the attribution line. This is disclosure the 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?

Front-loaded with purpose and tightly packed; almost every clause carries routing or constraint information. It is dense to the point of being cryptic in spots (e.g. 'A line with no DEPARTURE station'), but the length is justified by the number of near-miss siblings and edge cases it must disambiguate.

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 tool with no output schema, the description does state the return shape (platform, delay, cancellations, ≤15 rows, attribution line) and all key limits. Minor gaps remain around the not-found/invalid-station failure path and pagination beyond the row cap, but overall it is sufficient to call 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 the baseline is 3, and much of the description's parameter text mirrors the schema (e.g. the language/default guidance). It still adds cross-parameter meaning an agent needs: 'Give either station OR eva_no, never both', 'pair [categories] with a longer duration_min', 'no destination filter', and the train-type mapping for colloquial terms.

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

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

Specific verb+resource: 'Next trains from a German railway station: platform, delay, cancellations.' It explicitly distinguishes itself from get_departures ('Do NOT use for buses, trams, a non-railway stop, another day or a time over 2 h away') and check_transit_disruption, 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 explicit when-to-use ('when a train, S-Bahn or ICE leaves a named station', lateness questions, 'heute Abend' stays here), explicit when-not (buses/trams/non-railway stops/later days/>2 h), and names the two alternative tools with the condition that selects each. 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 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?

Annotations only declare the mutation profile (readOnly=false, idempotent=false, openWorld=false, destructive=false); the description goes well beyond that by disclosing session scoping, a hard cap of 10 watches, the 24h maximum, the default watch length, and an attribution requirement. It also discloses ambiguity handling — a name fitting several places returns a which-one list and opens nothing — which is exactly the kind of behavior an agent cannot infer from the 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 the behavioral caveats, and every clause carries information (limits, attribution, ambiguity, the no-lookup shortcut). The middle is dense with stacked examples, which is slightly crowded but not redundant.

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

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

There is no output schema, and the description compensates by explaining what a watch reports per kind, how ambiguity and conditions are echoed back, session scope, and the watch cap. For a state-creating tool with a nested condition object, every fact an agent needs before calling it is present.

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 key/kind resolution, hours vs until mutual exclusivity, language, and every condition sub-key with examples. The description restates the hours cap/default and that condition narrows the watch, adding a little framing but no syntax beyond what the schema carries. Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

States a specific verb and resource — 'Opens a watch so THIS conversation is told when something changes' — and enumerates the change types (road reopening, stop late, weather warning, charger free). The closing 'Do NOT use to look up now' cleanly separates it from the large family of check_* / find_* read siblings, so an agent can route correctly 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 when-to-use with quoted user phrasings ('sag mir Bescheid, wenn die A8 wieder frei ist'), explicit when-not ('Do NOT use to look up now, nor for e-mail, SMS or any alert outside this chat'), and even instructs the agent what to tell the user in that case. It also warns 'A name is enough as the key; no lookup first', heading off the obvious wrong behavior of resolving via a read tool first.

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