TourismMCP MCP Server

Löst eine Zeit-Nennung in einen absoluten ISO-8601-Zeitpunkt auf — „morgen früh", „heute Abend um 18 Uhr", „in zwei Stunden", „um 8:30". Auch „jetzt"/„now"/„aktuell" wird aufgelöst: nutze das als kanonische Quelle für die aktuelle Zeit, statt dir selbst ein Datum auszudenken. Das Ergebnis (`candidates[].datetime_range.start`) ist der Zeitpunkt, mit dem du weiterarbeitest. Nennt der Nutzer bereits eine vollständige ISO-8601-Zeit mit Offset, ist kein Aufruf nötig. **Pflicht**: `text` — die Nennung, so wie der Nutzer sie schrieb. **Optional**: `lang` (`'de'` Default, `'en'`, `'fr'`) und `tz` (IANA-Name; ohne ihn wird die Lokalzeit als `Europe/Berlin` gelesen und als korrekter UTC-Instant zurückgegeben). **Was zurückkommt**: EIN Zeitpunkt, kein Fenster — `start` und `end` sind derselbe Instant. Eine nicht auflösbare Phrase liefert `candidates: []`; dann nachfragen, statt selbst zu rechnen. **Anleitung**: `get_usage_guide` mit `tool='link_datetime'` — insbesondere, auf welche Stunde eine vage Tageszeit fällt und was dann zu tun ist. **Anti-Fab**: Datum und Uhrzeit sind Fakten wie eine Liniennummer und stammen aus diesem Werkzeug — kein selbst-erfundenes Datum, keine eigene Datums-Arithmetik. Returns `candidates[].datetime_range:{start,end}`.

Match-Mention gegen Caller-supplied Kandidaten-Vokabular. **When to use**: Caller hat ein eigenes Vokabular (z.B. Custom-Enum, App-State, Domänen-spezifische Begriff-Liste) und will eine User-Mention darauf mappen. **When NOT to use**: Standard-Place/Stop/Time/MoT/Line-Linking → die spezialisierten `link_*`-Tools nutzen. Ohne Kandidaten ist der Linker leer. **Required args**: `text`, `candidates` (`[{name, synonyms?, coord?}, …]`) MUST be non-empty — die candidate-Liste IST das Vokabular. **Typical chain**: THIS_TOOL → (custom Caller-Logik). **Multi-call**: ein Call pro Mention/Vokabular-Set. **Anti-Fab note**: nur Kandidaten aus dem `candidates`-Arg matchen, KEIN impliziter Vokabular-Erweiterung. Returns `candidates[].candidate:<name>, score, span`.

Kuratiertes Detail zu EINEM Niedersachsen-Hub-Treffer per `id` — Beschreibung, Öffnungszeiten, ECHTER Preis, Adresse, Medien. Für „was kostet der Eintritt für X", „wann hat X geöffnet" ist dieses Werkzeug die Auskunft. **Tool-Semantik-Abgrenzung**: dieses Tool = Detail zu EINEM kuratierten NDS-Treffer (dessen `id`/`global_id`). NICHT `get_poi_details` (das ist die OSM-Detail-Bridge per OSM-ID). NICHT `search_tourism` (das ist die kuratierte Region-/Typ-SUCHE die die `id` erst liefert). **When to use**: nach `search_tourism` lieferte einen Treffer mit `id` und die Anfrage will Detail/Preis/Öffnungszeiten — DE: „was kostet der Eintritt für <Treffer>", „Öffnungszeiten von <Treffer>", „erzähl mir mehr zu <Event>". EN: „opening hours / price of <hit>". **When NOT to use**: ohne vorherigen `search_tourism`-Treffer mit `id` (KEIN raten/erfinden einer id); OSM-POI-Detail per OSM-ID → `get_poi_details`; Region-Suche → `search_tourism`. **Required args**: `id` (die `id` ODER `global_id` aus einem `search_tourism`-Treffer, z.B. "e_101102405"). Optional: `query` — ändert nichts am Inhalt, der Datensatz kommt per `id` vollständig; `date` für `shade` (unten). **Typical chain**: `search_tourism(region=<R>, type=event)` → `get_tourism_details(id=<treffer.id>)`. **Multi-call**: ein Call pro id; nach `search_tourism` mit N Treffern pro Top-Treffer parallel rufbar. **Anti-Fab note**: Name, Beschreibung, Preis, Öffnungszeiten, Adresse kommen AUSSCHLIESSLICH aus `sources[].subjects[].properties` dieses Aufrufs. `sources: []` heißt: zu diesem Treffer ist nichts abrufbar — so wiedergeben („Zu diesem Treffer konnte ich keine Detail-Informationen abrufen"). Returns {id, sources:[{source, license?, subjects:[{subject, properties:{name, type, description?, opening_hours?, price?, address?, date?, media?, coord?, url?, hub_detail_url?}}]}], facts?}. Die Felder sind die schema.org-Felder des kuratierten Datensatzes: `price` aus `priceRange`/`offers`, `opening_hours` aus `openingHoursSpecification`, `coord` aus `geo`, `url` = schema.org-Link — alle additiv, present nur wo die Quelle sie trägt. **Bei einer Tour (`t_…`) zusätzlich**: `path_on_map` — ihr Verlauf als `[{lat,lon}]`, ausgedünnt auf die Punkte, die seine Form tragen; das ist die zeichenbare Strecke in voller Form. Dazu die Achsen des Datensatzes: `length_m`, `duration_min`, `ascent_m`/`descent_m`, `round_trip`, `activities` (wörtlich, als was er die Tour führt). Alle aus `ET2014A.json`, alle nur present wo die Quelle sie führt — eine fehlende Achse ist unbekannt, keine Null. Dazu `trail_shape` — `round` (Rundweg), `line` (Strecke) oder `ascent` (Aufstieg), aus dem Verlauf gelesen und vor `round_trip` maßgeblich — und `entries`: wo man einsteigt, der empfohlene Einstieg zuerst, `[{lat,lon,reason,name?,stop?:{name,distance_m,source,license}}]`. `reason`: `nearest_to_stop` (Punkt des Wegs am nächsten an einer Haltestelle), `course_end` (das haltestellennähere Ende einer Strecke) oder `official_start` (der Startpunkt; bei einem Aufstieg immer). `stop` ist die nächste bediente Haltestelle aus OpenStreetMap, `distance_m` die Luftlinie bis dorthin — den Fußweg nennt erst die Verbindung. Die Anreise mit Bus und Bahn (Server MobilityMCP) führt zum ersten Eintrag, mit Auto oder eigenem Rad zum `official_start`. Fehlt `entries`, war die Haltestellenfrage nicht zu beantworten: dann gilt der Startpunkt (`coord`), so benannt. Dazu `shade` für `date` (YYYY-MM-DD, Vorgabe heute): `tree_share` Anteil unter Bäumen, nicht Schatten; `by_hour?` Schattenanteil je Stunde 8–19 Uhr Ortszeit (Stunden ohne Sonne fehlen) am nächsten Stichtag `day` (`MM-DD`, ausgeschrieben `day_text`); Laubzeit Mai bis einschließlich Oktober, sonst statt `tree_share` `trees_leafless: true`, Bäume ohne Laub: nur Hang- und Gebäudeschatten; `data_as_of` Jahr des ältesten Fluges; `covered_share`, `source`, `licence`, `sources`; aus LGLN-Höhenmodell und Luftbild, Gebäude aus OpenStreetMap, außerhalb Niedersachsens Meta/WRI-Baumhöhe ohne `by_hour`. Davon nur Anteile, Uhrzeiten, Datenstand wiedergeben, ohne Zusatz. Fehlt `shade`: keine Angabe, nicht schätzen. `licence`, `sources[].licence` wie `license` wiedergeben. **`facts` (additiv, top-level)**: normalisierte Öffnungszeiten + Preis mit Pro-Feld-Provenance — kuratiert hat Quellen-Priorität VOR der OSM-Bridge `get_poi_details`. `price.free=true` bei explizit kostenlos/Eintritt frei, `false` bei einem Betrag; `price.raw` trägt den kuratierten Preis-String wörtlich. Fehlen opening_hours UND price → `facts` ABWESEND (ehrlich, nie erfunden). **`hub_detail_url` (additiv, in `properties`, nur bei `source: 'niedersachsen-hub'`)**: die kanonische Entitätsseite dieses Datensatzes beim Niedersachsen-Hub, dem Nutzer nennbar — NICHT die Betreiber-Website, die daneben in `url` steht. Jeder Datensatz dieser Quelle, dessen Art beim Hub eine Eintragsseite hat, trägt sie schon im ersten Aufruf: POI (`p_…`), Tour (`t_…`), Veranstaltung (`e_…`), Unterkunft (`h_…`), Gastronomie (`g_…`), Gebiet (`r_…`). Ein Medien-Datensatz (`m_…`) hat keine solche Seite und trägt sie nicht. Fehlt sie, keine konstruieren. **`license` (additiv, NEBEN `source` im `sources[]`-Eintrag — nicht in `properties`)**: `{id?, url?, notice?, holder?}` = Lizenz-Kennung, Lizenz-Text-URL, der WÖRTLICH wiederzugebende Lizenzverweis (DZT-`copyrightNotice`, § 3 der DZT-Nutzerbedingungen) und der zu nennende Urheber (das `author`- bzw. `copyrightHolder`-Feld des Datensatzes). Gibt er nichts an, ist das Feld **abwesend** — nie eine geratene Vorgabe-Lizenz. Nennst du einen Datensatz mit `license.holder`, nenne den Urheber mit.

Kuratierte Tourismus-Suche des Niedersachsen-Hubs: redaktionell gepflegte Einträge mit Veranstaltungen samt Datum, Preisen, Beschreibungen, Medien, Öffnungszeiten und Touren. Für „welche Veranstaltungen sind in X", „was kostet der Eintritt" ist dieses Werkzeug die Auskunft — erst verorten, dann abfragen: `region`/`query` aus der Frage, `lat`/`lon` nur aus `search_place`. **Tool-Semantik-Abgrenzung**: die in OpenStreetMap erfassten Sehenswürdigkeiten eines Gebiets listet `expand_kg_pois`; für Region-Tourismus dürfen beide laufen. Umkreis um einen Punkt → `nearby`, welcher Ort gemeint ist → `search_place`. **When to use**: Events — DE: „was ist diese Woche/am Wochenende in <Region> los", „Veranstaltungen in <Ort>". EN: „events in <Region> this weekend". Unterkünfte/Gastro — DE: „Hotels in <Ort>", „Restaurants in <Ort>". EN: „hotels/restaurants in <Ort>". Touren — DE: „touristische Radrouten/Radtouren in <Region>", „Radwanderwege/Wanderwege am <Ort>" → `type=tour`; jede Tour trägt dann `length_m`, `duration_min`, `ascent_m`/`descent_m`, `round_trip` und `activities` (wörtlich, als was der Datensatz sie führt: „Fahrrad", „E-Bike", „Wandern", „Kanu") sowie `trail_shape` (`round` | `line` | `ascent`, aus dem Verlauf gelesen — gilt vor `round_trip`) — DARAN auswählen, nicht am Namen. Die ersten 5 Touren mit Verlauf tragen ihn als `path_polyline` für die Karte (Encoded Polyline, ≤ 40 Punkte) — nicht vorlesen. Bei mehreren die passendste per `get_tourism_details` zeichnen, die anderen nennen und fragen, welche noch. **When NOT to use**: alle in OpenStreetMap erfassten Sehenswürdigkeiten → `expand_kg_pois`; Detail zu EINEM Treffer → `get_tourism_details`; Routing/ Abfahrten, auch „von A nach B mit dem Rad" → der Server MobilityMCP; Wetter/Tide → `get_current_weather`/`get_tide`. **Required args**: `region` ODER `query` (eines von beiden — Freitext-Region/ Name, z.B. region="Wangerland", query="Sielhafenmuseum"). Optional: `type` (genau eines von "event" | "poi" | "accommodation" (="hotel") | "gastro" (="restaurant") | "tour" — kuratierte Rad-/Wander-Routen, auch als "radtour"/"radroute"/"radwanderweg"/"wanderweg" akzeptiert; weggelassen = alle Typen; unbekannter Wert = alle. OHNE `type=tour` sind Touren praktisch nie unter den Treffern). Im Aktivitäts-Scope (type="poi"/"attraction"/"unternehmen"/…) sind Unterkünfte AUSGESCHLOSSEN, im Region- wie im Vicinity-Modus (ein Hotel ist keine Unternehmung); für Hotels explizit type="accommodation". `timeframe` (nur für type=event: "today" | "tomorrow" | "weekend" | "this_week" | "month" | ISO "YYYY-MM-DD" | Range "YYYY-MM-DD..YYYY-MM-DD"; ohne timeframe = kommende Events ab heute), `limit`, `family_only` (bool, Default false — nur die kuratierten Family-Kategorien, je mit der belegten `suitability`-Achse), `indoor_only` (bool — nur, was der Niedersachsen-Hub als „Schlechtwetterangebot“ führt; „drinnen“ führt er nicht. Andere Quellen entfallen, `note` sagt es). `activity` (nur mit `type=tour`): wie eine Tour zurückgelegt wird — "wandern" | "fahrrad" | "kanu" + Synonyme. Filtert auf die GANZE Familie kuratierter Aktivitätswerte; weglassen oder unbekannt = alle. `shade` (nur mit `type=tour`): "schattig" (überwiegend unter Bäumen) | "vormittags" | "mittags" | "nachmittags" (9–11/12–14/14–17 Uhr überwiegend im Schatten) am `date` (YYYY-MM-DD, Vorgabe heute) — nur solche Touren, danach sortiert, Stichtag in `shade_day`. Laubzeit Mai bis einschließlich Oktober, sonst `shade_trees_leafless`: nur Hang- und Gebäudeschatten. `shade_tree_share` = Anteil der Strecke unter Bäumen, nicht Schatten je Stunde. Aus LGLN-Höhenmodell und Luftbild; davon nur Anteile und Uhrzeiten wiedergeben, ohne Zusatz; `shade_sources[].licence` wie `license` wiedergeben. Was nicht beurteilt ist, sagt `note`. **Coord-Vicinity-Modus (Umkreis, POI-Anker)**: für „<Kategorie> am/bei <POI>" den POI ZUERST über die Ortsauflösung zu einer Coord auflösen, dann `lat`+`lon` setzen (beide nötig, optional `radius_m`). `region`/`query` sind dann nur Pool-Hint; Treffer im Umkreis, nächster zuerst, je mit `distance_m`. NUR in diesem Modus kommt die OSM-Breite dazu, entdoppelt gegen die Kuration (kuratierter Treffer gewinnt): bei `type=gastro` die `amenity`-Gastronomie, im Aktivitäts-Scope (`type=poi`, „unternehmen") `tourism` ∈ attraction/museum/…, `historic` und `leisure` ∈ park/garden/… — AUSGESCHLOSSEN bleiben Unterkünfte (hotel/hostel) und Alltags-Versorgung (`shop`, Apotheke/Bank/Arzt), beides keine Ausflugsziele. **Typical chain**: `search_tourism(region=<R>, type=event)` → `get_tourism_details(id)` pro Treffer. **Multi-call**: ein Call pro Region/Typ. **Anti-Fab note**: Event-Namen, DATEN, PREISE, POI-Namen, Adressen kommen AUSSCHLIESSLICH aus `pois[]` / `events[]` dieses Aufrufs. `returned: 0` / `pois: []` / `events: []` heißt: für <Region> war nichts abrufbar — so wiedergeben. Datum eines Events ist tool-belegt (`events[].date` / `pois[].date`, ISO-8601 Europe/Berlin) ODER abwesend — NIE geschätzt. **DZT-Bündelung (zweite kuratierte Quelle, DE-weit)**: kuratierte Treffer AUSSERHALB Niedersachsens kommen aus der DZT-KG (Deutsche Zentrale für Tourismus), de-dupliziert; in Niedersachsen gewinnt der Niedersachsen-Hub-Eintrag. Bei `type=tour` bleibt sie AUSSEN VOR — sie führt keinen Touren-Inhaltstyp; kuratierte Touren gibt es nur für Niedersachsen, außerhalb ehrlich "keine Tour abrufbar". Returns {place, source:'niedersachsen-hub', type, returned, mode?, center?, radius_m?, shade_day?, shade_day_text?, shade_trees_leafless?, shade_sources?, pois:[{name,type,description?,address?,uri?,date?,price?,media?, coord?,opening_hours?,id?,distance_m?,source?,license?,hub_detail_url?, length_m?,duration_min?,ascent_m?,descent_m?,round_trip?,trail_shape?,activities?, shade_tree_share?,path_polyline?}], events:[{name,date,location,source?,license?}]}. Die Herkunft eines Treffers sagt sein `source` ('osm' | 'niedersachsen-hub' | 'dzt'). `id` ist der Schlüssel für `get_tourism_details`; die Felder folgen schema.org. **`license` (additiv, PRO Treffer)**: die Lizenz, die der Datensatz selbst angibt — `{id?, url?, notice?, holder?}`: `id` = Lizenz-Kennung (z.B. 'CC-BY-SA-4.0', 'CC0-1.0', 'ODbL-1.0'), `url` = Lizenz-Text/Deed, `notice` = der WÖRTLICH wiederzugebende Lizenzverweis (DZT-`copyrightNotice`, § 3 der DZT-Nutzerbedingungen; bei OSM-Treffern die ODbL-Namensnennung), `holder` = der zu nennende Urheber (das `author`- bzw. `copyrightHolder`-Feld des Datensatzes). Gibt er nichts an, ist das Feld **abwesend** — nie eine geratene Vorgabe-Lizenz. Nennst du einen Treffer mit `license.holder`, nenne den Urheber mit. **`hub_detail_url` (additiv, PRO Treffer, nur bei `source: 'niedersachsen-hub'`)**: die Entitätsseite dieses Treffers beim Niedersachsen-Hub, dem Nutzer nennbar — NICHT die Betreiber-Website (`uri`). Jeder Treffer, dessen Art beim Hub eine Eintragsseite hat, trägt sie: POI (`p_…`), Tour (`t_…`), Veranstaltung (`e_…`), Unterkunft (`h_…`), Gastronomie (`g_…`), Gebiet (`r_…`). Ein Medien-Datensatz (`m_…`) hat keine und trägt keine; fehlt sie, keine konstruieren. Mit `family_only` trägt jeder Treffer zusätzlich `family`, `suitability` ({family, age_bands, pushchair, seal (Kinderferienland-Siegel), indoor_bad_weather}) und, wo die Quelle sie führt, `price_child`/`price_family` — alle feature-belegt: „kinderfreundlich" ist belegt, nicht geraten.

Aktuelles Wetter zu Koordinaten. Für „wie ist das Wetter in X" ist dieses Werkzeug die Auskunft — erst verorten, dann abfragen: `lat`/`lon` kommen aus `search_place`, nie aus eigener Schätzung. **When to use**: aktuelle Wetterfrage zu einem Ort — DE: „wie ist das Wetter in <ORT>", „regnet es gerade in <ORT>". EN: „what's the weather like in <CITY> right now". Auch als Teil des Wetter-POI-Pfads („was kann ich bei dem Wetter unternehmen"). **When NOT to use**: Vorhersage > 1 Stunde voraus → `get_weather_forecast`; Gezeiten → `get_tide`. **Required args**: `lat`, `lon`. Optional: `units` ('metric' (°C, default), 'imperial' (°F), 'standard' (K)), `lang` ('en' default, 'de'). **Typical chain**: `search_place`(city) → THIS_TOOL(lat, lon) → (optional `nearby`/`resolve_location` für POI-Match). **Multi-call**: ein Call pro Ort. Für Multi-Tag-Anfragen `get_weather_forecast` bevorzugen. **Anti-Fab note**: Temperatur, Bedingungen, Wind, Feuchte kommen NUR aus dem Tool-Output dieses Aufrufs — KEINE Schätz-Werte. **`attribution` (additiv, top-level)**: die von der GeoNutzV verlangte Quellenangabe der Wetterdaten — `{id:'GeoNutzV', notice:'Quelle: Deutscher Wetterdienst', url:…}`. Nennst du Wetter-Werte, nenne den **Deutscher Wetterdienst** als Quelle; die Auflage reist mit dem Tool-Output, nicht mit dem Prompt.

Attraktionen / Tourismus-POIs FÜR einen Place aus dem OSM-Knowledge-Graph (Ausdehnung einer Stadt-/Region-OSM-ID auf die POIs darin). Für „was kann ich in X unternehmen" ist dieses Werkzeug die Auskunft — erst verorten, dann abfragen: die `osm_id` der Region stammt aus `search_place`. **Tool-Semantik-Abgrenzung**: dieses Tool = „WELCHE Attraktionen gibt es IN diesem Place" (KG-basiert). NICHT `nearby` (das ist Vicinity — „Dinge im Radius um EINEN Punkt"). NICHT `search_place` (das ist Place- Disambiguierung — „WELCHER Ort ist gemeint"). NICHT `resolve_location` (Transit-Halte). **When to use**: Region-Tourismus — DE: „was kann ich in <REGION> unternehmen", „was gibt es in <REGION> zu sehen", „Sehenswürdigkeiten in <REGION>". EN: „what can I do in <REGION>", „attractions in <REGION>". Nach `search_place(<REGION>)` mit der zurückgegebenen osmRel-ID aufrufen. **When NOT to use**: Vicinity-zu-Punkt (Radius um Koordinaten) → `nearby`; Detail-Info zu EINEM bereits gefundenen POI → `get_poi_details`; Place- Auflösung Name→ID → `search_place`; Wetter/Tide → `get_current_weather`/`get_tide`. **Required args**: `osm_id` (i64 — die osmRel-ID der Stadt/Region aus einem `search_place`/`places`-Treffer, z.B. 1187768 für Wangerland; osmNode als Fallback). Optional: `limit` (Default 8, clamped 1..=20), `types` (Stichwörter gegen die Werte der OSM-Tags `tourism`, `historic`, `leisure`, `natural`, `sport` und `amenity`, Teilstring, case-insensitive, z.B. ["museum"], ["castle"]; leer = alle Aktivitäts-/Tourismus-Klassen), `include_address` (bool, Default true — die Postadresse aus den `addr:*`-Tags), `family_only` (bool, Default false — nur family-taugliche POIs, je mit den tag-belegten Feldern `family`/`indoor`/`family_categories`) und, nur zusammen damit, `indoor_only` (bool — davon nur die Indoor-/Schlechtwetter-tauglichen). **Unterkünfte ausgeschlossen**: dieses Tool ist der Aktivitäts-/„unternehmen"- Pfad — Unterkünfte (`tourism`=hotel/hostel/guest_house/motel/apartment/… ) werden backend-seitig AUSGESCHLOSSEN (ein Hotel ist keine Unternehmung); auch ein Hotel-`types`-Filter liefert hier nichts. Für Hotels/Pensionen → `search_tourism(type=accommodation)` (kuratierte Unterkünfte). **Typical chain**: `search_place(<REGION>)` → THIS_TOOL(osm_id=<osmRel>) → (optional `get_poi_details(osm_id)` pro Treffer für tiefere Details). **Multi-call**: ein Call pro Region/Typ-Filter; Bursting nicht nötig (das Tool fan-out't intern über alle containedInPlace-Entities). **Anti-Fab note**: POI-Name, `type`, Beschreibung, Adresse kommen AUSSCHLIESSLICH aus `pois[]` dieses Aufrufs. `returned: 0` / `pois: []` heißt: für dieses Gebiet ist nichts abrufbar — so wiedergeben („Ich konnte für <REGION> aktuell keine Attraktionen abrufen"). OSM-KG-Coverage: deutschlandweit; Tag-Dichte variiert je Region wie in OSM üblich. Returns {place_osm_id, total_contained, tourism_candidates, returned, pois:[{name, type, types, description?, address?, uri, coord?, opening_hours?, fee?, source:'osm'}], attribution?}. Die optionalen Felder je POI sind tag-belegt oder abwesend, nie geraten. **`attribution` (additiv, top-level)**: die ODbL-Namensnennung der gelieferten OSM-Daten (ODbL) — `{id:'ODbL-1.0', notice:'© OpenStreetMap contributors', url:'https://www.openstreetmap.org/copyright'}`. EINMAL pro Antwort (nicht pro POI) und nur wenn `pois` nicht leer ist. Nennst du diese POIs, nenne „OpenStreetMap" als Quelle. „Kinderfreundlich" ist ein Daten-Fakt (Kategorie/Tag-belegt), kein Modell-Raten.

Findet Haltestellen, POIs und Adressen im Radius um eine KOORDINATE (Schwerpunkt Hannover/Niedersachsen) — „was ist in der Nähe von <lat,lon>", „welche Haltestellen liegen um diesen Punkt". Liegt nur ein Name vor, kommt erst eine Auflösung: `search_place` für eine Stadt oder Region, sonst die Ortsauflösung. **Pflicht**: `latitude`, `longitude`, `radius_m`. **Optional**: `limit` (Default 10); `node_types` — EIN String, mehrere Arten mit Komma: `'stop'`, `'address'`, `'poi'`, die Sharing-Angebote `'bike_rental'`, `'scooter_rental'`, `'car_sharing'`, `'taxi_stand'`, die Abstellanlagen `'park_and_ride'`, `'bike_and_ride'`, in Südtirol Ladesäulen `'charging_station'` und fahrende Taxis `'taxi'`, oder `'any'` (`'stop,bike_rental'`); `include_mots` (legt die bedienenden Linien über die Haltestellen-Treffer); `only_available` (nur Sharing-Treffer, Ladesäulen und Taxis, die gerade als frei gemeldet sind — UNBEKANNTE Verfügbarkeit gilt nicht als frei). **Format**: kompakter Einrück-Text (TOON), kein JSON. **Anleitung**: `get_usage_guide` mit `tool='nearby'` — die Werte im Einzelnen, was `'any'` nicht abdeckt, und was ein Treffer trägt (`category`, `modality`, `parking`, `charging`, `taxi`, `contactInfo`). **Anti-Fab**: nur die zurückgegebenen Namen, Typen, Distanzen und Verfügbarkeiten nennen; fehlt ein Feld, war es in der Quelle nicht getaggt — Öffnungszeiten und Preise stehen hier NICHT.

Löst den NAMEN einer Stadt, Region oder eines Bezirks in Koordinaten und OSM-Ids auf — der erste Schritt, wenn ein GEBIET verortet werden muss („was kann ich in <REGION> unternehmen", „wie ist das Wetter in <CITY>"). **Für eine HALTESTELLE ist dieses Werkzeug fast immer falsch**: es kennt Gebiete, keine Bahnsteige — auf einen Bahnhofs-Namen antwortet es mit keinem Ort, und die Id, die es liefert, ist eine OSM-Id und keine fahrbare Halte-Id. **Trägt die Anfrage `Bahnhof`, `Hauptbahnhof`, `Hbf` oder `Bf`, gehört sie an die Ortsauflösung** — „Köln Hauptbahnhof" und „Hannover Bahnhof" also dorthin: hier antworten beide mit einer leeren Liste. Dasselbe für Adresse und POI — alles, was Start, Ziel oder Abfahrtsort einer Fahrt sein kann; eine Stadt als Fahrt-Endpunkt („von Hannover nach Celle") ebenfalls. Von einer Koordinate zurück zum Namen geht `reverse_geocode`, die Umgebung einer Koordinate listet `nearby`. **Pflicht**: `name`. **Optional**: `lang` (derzeit ohne Wirkung). **`score`**: 1 = derselbe Name, ab 0,5 als ganzes Wort; liegt der erste Treffer darunter, trägt er den Namen nicht (Namensvetter, oder der Ort unter eigenem Namen: „Luxemburg" → `Luxembourg`) — Koordinate prüfen, sonst Ortsauflösung. **Anleitung**: `get_usage_guide` mit `tool='search_place'` — Abgrenzung, Ketten, `score`, mehrdeutige Namen. **Anti-Fab**: nur die zurückgegebenen Namen und Ids nutzen, keine Bauch-Geographie.

POI-Detail-Lookup per OSM-ID (Daten aus OpenStreetMap). Für „Öffnungszeiten von X", „erzähl mir was über X" ist dieses Werkzeug die Auskunft — erst verorten, dann abfragen: die `osm_id` stammt aus `nearby`/`resolve_location`/`search_place`. **When to use**: nach `nearby` / `resolve_location` / `search_place` lieferte einen POI mit `osm_id` und die Anfrage will Detail-Info — DE: „erzähl mir was über <POI>", „was kostet der Eintritt", „Öffnungszeiten von <POI>", „bei dem Wetter in <REGION> unternehmen". EN: „tell me about <POI>", „opening hours of <POI>", „what can I do in <REGION> given the weather". **When NOT to use**: für Stadt-/Region-IDs (nutze `search_place`); ohne vorherigen Tool-Call mit OSM-ID-Output (KEIN raten); wenn die Anfrage Routing/Abfahrten will (dafür der Server MobilityMCP). **Required args**: `osm_id` — bare numeric string (pattern `^\d+$`, z.B. "296222553"), kein `node:`/`way:`-Prefix (der wurde beim emittierenden Tool bereits gestrippt). **Typical chain**: TWO distinct chains feed this tool — (1) WETTER-CONTEXT: `get_current_weather` + `nearby`(node_types='poi') → THIS_TOOL ×3-5 (Trigger: „bei dem Wetter", „given the weather"). (2) REGION-TOURISM: `search_place` + `resolve_location`(node_types='poi') → THIS_TOOL ×3-5 (Trigger: „was kann ich in <REGION> unternehmen" ohne Wetter-Bezug — dichtere OSM-Coverage über `resolve_location`). **Multi-call**: JA. Nach `resolve_location`/`nearby` mit N POI-Treffern: THIS_TOOL pro Top-3 bis Top-5 OSM-IDs PARALLEL aufrufen — jeder Call ist unabhängig, ein Burst ist erlaubt. NIE nur 1× rufen wenn N>1 POIs zurückkommen. **Anti-Fab note**: POI-Name, Operator, Öffnungszeiten, Adresse, Tags kommen AUSSCHLIESSLICH aus `sources[].subjects[].properties` dieses Aufrufs. `sources: []` heißt: zu diesem Ort ist nichts abrufbar — so wiedergeben („Zu diesem Ort konnte ich aktuell keine Detail-Informationen abrufen"). OSM-Coverage: deutschlandweit; Tag-Dichte variiert je Region wie in OSM üblich. **Shape**: `{osm_id, sources:[{source:'openstreetmap', subjects:[{subject, properties:{…raw OSM tags: name, tourism/historic/leisure, opening_hours, fee, website, wheelchair, addr:*…}, coord?:{lat,lon}}]}], facts?:{opening_hours?:{value,source}, price?:{free?,raw,source}}}`. Die rohen Tags tragen Typ/Adresse/Öffnungszeiten/Preis/Beschreibung bereits; `coord` (Geometrie-Center, additiv) liegt je Subject NEBEN `properties` und speist die Karte — present nur wenn das Element Geometrie hat. **`facts` (additiv, top-level)**: normalisierte Öffnungszeiten + Preis mit Pro-Feld-Provenance (`source:'openstreetmap'`) aus den `opening_hours`/`fee`-Tags — EINE stabile Stelle statt Roh-Tags durchwühlen. `price.free=true` bei `fee=no` (explizit „kostenlos"/Eintritt frei), `false` bei `fee=yes`/Betrag; `price.raw` trägt den Roh-Tag verbatim. Fehlt opening_hours UND fee → `facts` ABWESEND (honest, nie erfunden — Quellen-Priorität: kuratiert via `get_tourism_details` VOR diesem OSM-Bridge). **`attribution` (additiv, top-level)**: die ODbL-Namensnennung der gelieferten OSM-Daten (ODbL) — `{id:'ODbL-1.0', notice:'© OpenStreetMap contributors', url:'https://www.openstreetmap.org/copyright'}`. EINMAL pro Antwort (nicht pro Treffer) und nur wenn `sources` nicht leer ist. Nennst du OSM-Daten in der Antwort, nenne die Quelle „OpenStreetMap" — die Lizenz-Auflage reist mit dem Tool-Output, nicht mit dem Prompt.

Löst Freitext in die Id auf, mit der gefahren wird — die Haltestelle, die Adresse oder den POI hinter „von <X> nach <Y>", „erzähl mir was über <POI>". Wo Routing, Abfahrtstafel oder POI-Steckbrief eine Id brauchen, steht es davor — auch wenn der Nutzer die Stadt dazu nennt („Hauptbahnhof Hannover"). Ein GEBIET (Stadt/Region) verortet `search_place`. **Pflicht**: `query` — nur der Name: `'Kelsterbach Bahnhof'`, NICHT `'für Kelsterbach Bahnhof'`. Wegzulassen sind `für`, `vom`, `von`, `nach`, `bis`; ein führendes `am`/`an`/`in`/`zur`/`auf` bleibt stehen — so heißen echte Halte („Am Wehrhahn"). **Optional**: `lat`/`lon` (Ranking-Bias), `limit`, `node_types` (`'stop'`/`'address'`/`'poi'`/`'any'`, mehrere mit Komma in EINEM String; eine andere Art ist ein Argument-Fehler), `city_station` (Query = ganze Stadt → deren (Haupt-)Bahnhof). **Art-Wort in `node_types`, nicht in den Namen**: „Haltestelle X" → `'stop'`, „Adresse X" → `'address'`, „POI X"/„Sehenswürdigkeit X" → `'poi'`, `query` je ohne das Wort. **A→B: zweimal rufen** — Start, Ziel. Jeder Treffer trägt `type` und `location`; NUR ein `stop` hat eine fahrbare DH-Id, nie eine erfinden. Ein `stop` nennt in `modes`, was dort hält (`['tram','bus']`) — so ist „die Stadtbahn-Haltestelle" unter Namensvettern zu erkennen. Nennt `name` den Ort in der Sprache der Frage, steht der Name vor Ort in `localName`. **Anleitung**: `get_usage_guide` — Abgrenzung, Argumente, Rangfolge. **Anti-Fab**: nur die Treffer aus dem Output dieses Aufrufs verwenden.

Benennt, was an einer KOORDINATE liegt — die Orte, in denen sie liegt („was liegt bei <lat,lon>"), mit `level` eine bestimmte Ebene davon, mit `level='street'` die nächste Adresse oder Straße (der Lookup für eine GPS-Startposition). **Abgrenzung**: den Weg zurück (Name → Koordinate und OSM-Ids) geht `search_place`, die fahrbare Halte-Id liefert die Ortsauflösung, und `nearby` listet auf, was UM eine Koordinate liegt, statt den Punkt selbst zu benennen. **Pflicht**: `lat` und `lon` — geschrieben auch `latitude`/`longitude`, so wie `nearby` die Koordinate nimmt; je Aufruf nur eine der beiden Schreibweisen. **Optional**: `radius_m` (Reichweite der nächsten Adresse in METERN, Default 500, höchstens 5000; ein Ort, IN dem die Koordinate liegt, hat Abstand 0 und ist immer dabei), `limit` (Höchstzahl Treffer, Default 10, Maximum 50) und `level` — `'place'` (Default: alle Orte an der Koordinate, kleinster zuerst), `'city'` (die Stadt/Gemeinde), `'suburb'` (der Stadt- oder Ortsteil) oder `'street'`. Kennt die Karte die gewünschte Ebene hier nicht, antwortet die nächst-gröbere, erkennbar am `place_type`; ein unbekannter Wert wirkt wie `'place'`. **Anleitung**: `get_usage_guide` mit `tool='reverse_geocode'`. **Anti-Fab**: nur die zurückgegebenen Orts- und Straßen-Namen verwenden, einschließlich der Hausnummer aus der Karte — nie eine erfinden.

Hoch- und Niedrigwasser der nächsten Tage für einen Küstenort, amtlich vom BSH, mit Windstau-Vorhersage. Für „wann ist Ebbe in X", „Gezeiten bei Y" ist dieses Werkzeug die Auskunft — erst verorten, dann abfragen: `city` aus der Frage oder `lat`/`lon` aus `search_place`. **When to use**: Gezeiten-/Ebbe-/Niedrigwasser-/Hochwasser-Frage, auch für einen kommenden Tag — „wann ist morgen Niedrigwasser in Schillig", „low tide in Cuxhaven tomorrow". **When NOT to use**: normales Wetter → `get_current_weather`; Routing → der Server MobilityMCP; Haltestellen → `resolve_location`; Binnen-Orte ohne Küstenbezug (Hannover, Hildesheim, Braunschweig). **Required args**: entweder `city` ODER (`lat`+`lon`). `city` trifft zuerst den Pegelnamen, sonst wird der Ort verortet und der Pegel nach Abstand und Revier gewählt (`matched_by`, `query_location`, `distance_km`); weiter als 30 km vom nächsten Pegel ist kein Küstenort. Optional: `station_limit` (Default 3, 1–10), `date_start`, `date_end` (YYYY-MM-DD; ohne beide heute und die zwei Tage danach). Die Vorhersage reicht etwa 6 Tage, Späteres liegt nicht vor (`prediction_note`). Zeiten in Ortszeit; `forecast_cm`/`forecast_deviation` = Windstau; `attribution` nennt BSH, CC BY 4.0. **Typical chain**: (optional `search_place`(city)) → THIS_TOOL. **Multi-call**: ein Call pro Ort/Tag-Range. **Anti-Fab note**: Tide-Zeiten kommen NUR aus dem Tool-Output dieses Aufrufs; eine Zeit, die die Antwort nicht enthält, ist unbekannt.

Die ausführliche Anleitung zu den Werkzeugen dieses Katalogs: wofür ein Werkzeug da ist, wogegen es abzugrenzen ist, was seine Argumente bewirken, was zurückkommt und was daraus zitiert werden darf. Die `description` eines Werkzeugs ist die Kurzform, dieser Text die vollständige. **Optional** `tool` — der Name genau eines Werkzeugs, dessen Abschnitt du lesen willst; weggelassen kommt die ganze Anleitung. Lies den Abschnitt eines Werkzeugs, bevor du dessen Filter setzt oder ein leeres Ergebnis als Antwort weitergibst. **Der Abruf ohne `tool` ist teuer**: er bringt die Abschnitte ALLER Werkzeuge dieses Katalogs auf einmal, ein Vielfaches eines einzelnen. Setze `tool`, sobald feststeht, um welches Werkzeug es geht; ohne Argument nur für den Überblick über den ganzen Katalog.

Wetter-Vorhersage zu Koordinaten. Für „wie wird das Wetter morgen in X" ist dieses Werkzeug die Auskunft — erst verorten, dann abfragen: `lat`/`lon` kommen aus `search_place`, nie aus eigener Schätzung. **When to use**: zukünftige Wetterfrage — DE: „wie wird das Wetter morgen / heute Abend / am Samstag in <ORT>", „regnet es morgen". EN: „forecast for <CITY> tomorrow / this weekend". Auch für Halbtages-Touren-Planung („wenn das Wetter mitspielt"). **When NOT to use**: jetziger Zustand → `get_current_weather`; Tide → `get_tide`. **Required args**: `lat`, `lon`. Optional: `units` ('metric' default, 'imperial', 'standard'), `lang` ('en' default, 'de'), `limit` (Anzahl Forecast-Slots). **Typical chain**: `search_place`(city) → THIS_TOOL(lat, lon, limit=N) → (optional `resolve_location(node_types='poi')` + `get_poi_details` für POI-Auswahl je nach Wetter-Branche). **Multi-call**: ein Call pro Ort. Multi-Day-Queries decken sich über `limit`. **Anti-Fab note**: Vorhersage-Werte kommen NUR aus dem Tool-Output dieses Aufrufs; ein Tag, den die Antwort nicht enthält, hat keinen Wert. **`attribution` (additiv, top-level)**: die von der GeoNutzV verlangte Quellenangabe — `{id:'GeoNutzV', notice:'Quelle: Deutscher Wetterdienst', url:…}`. Nennst du Vorhersage-Werte, nenne den **Deutscher Wetterdienst** als Quelle.